[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU make 3.81beta4 released

From: Markus Mauhart
Subject: Re: GNU make 3.81beta4 released
Date: Tue, 17 Jan 2006 22:57:59 +0100

"Eli Zaretskii" <address@hidden> wrote ...
>> From: "Markus Mauhart" <address@hidden>
>> Date: Mon, 16 Jan 2006 23:03:07 +0100
>> >> 2) inside cmd.exe, using  my trivial or your current patch:
>> >> "make -f Mymakefile -j 2or3orMore" ... executes like no "-j" had been 
>> >> used.
>> >
>> > Is your Makefile recursive?
>> No
>> (it once restarts $(MAKE) with the same Mymakefile but an added include path,
> Well, that's recursion in my book: it runs sub-Make's.  Thus, what I
> found, i.e. that sub-Make's by default run with -j1, is what I'd
> expect to happen for you.

Ok, this phenomen is now solved, it's like you and Paul say.

Hence, as a temporary workaround, I replace "$(MAKE)" with "$(MAKE) $(gmake-j)",
and then do ...
   set gmake-j=-j 2
... immediately before making -> buildtime drops to allmost 50% :-)

But this was definitely enough success for today:

Next I reproduce the "hanging situation" ("-j noNumber" "mode 1"), but now
let it "hang" inside the MSVS IDE debugger - turns out that it loops the
"while (goals != 0)", remake.c, update_goal_chain(), line 112, forever.
To verify this outside the debugger I insert ...
                printf ("\r%u    " ,++printfCounter);
... rebuild and run the release version again w/o debugger: as usually it
"hangs" before reaching any compilation, there are about 170 batch files,
I then stop it using CTRL-C once the printfCounter reached ~200K.

Next I repeat the previous (dbg-less) procedure but with "mode 2"
... now it "hangs" again, BUT CPU = 0%, and printfCounter from above
is invisible ?! (btw, having 350 new batch files)

Repeat it, but now inside the debugger:
Here I catch an exception in sub_proc.c, process_register(),
proc_index is shown as allmost 33M  ?! (btw, having 261 new batch files)
(coming from process_easy() from start_job_command())

261 ? proc_index is allmost 33M ? !


static sub_process *proc_array[256];
static int proc_index = 0;

proc_array[proc_index++] = (sub_process *) proc;

... looks like we just left the bounds of our static array :-)

Much left to do ...

Best Regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]