Re: [TEST] make -j patch [take 2]

On Sat, 13 Nov 2004, Alexander Leidinger wrote:

AL>On Fri, 12 Nov 2004 17:11:37 +0100 (CET)
AL>Harti Brandt <harti_at_freebsd.org> wrote:
AL>
AL>> On Fri, 12 Nov 2004 Alexander_at_Leidinger.net wrote:
AL>> 
AL>> > Zitat von Harti Brandt <harti_at_freebsd.org>:
AL>> >
AL>> >> PK>>If yes: we have some ports which aren't -j safe, so this would violate
AL>> >> PK>>POLA.
AL>> >> PK>
AL>> >> PK>That is what "make -B" is for.
AL>> >>
AL>> >> Or .NOTPARALLEL
AL>> >
AL>> > I'm not talking about /usr/ports/category/port/Makefile, I'm talking about
AL>> > /usr/ports/category/port/work/tarball_dir/**/Makefile. We don't have
AL>> > control about those Makefiles.
AL>> >
AL>> > As much as I like a flag in the Makefile of a port which indicates
AL>> > that a port can't be build with -j, we don't have this and the last time
AL>> > this topic was discussed there was a strong objection to something like
AL>> > this.
AL>> >
AL>> > So this change may break procedures which worked so far.
AL>> 
AL>> How? If you specify -j on the port's make the -j gets passed down to all 
AL>> sub-makes via MAKEFLAGS and they use it. The difference is just that the 
AL>> overall number of jobs started is now limited by the original -j.
AL>
AL>In my first mail I made an example where a portupgrade is in between two
AL>make processes. make runs several portupgrade processes in parallel and
AL>portupgrade calls make. AFAIK this doesn't result in in an invocation of
AL>portupgrades child-make with -j. With phk's changes the child-make of
AL>portupgrade uses the FIFO (at least this is what I read implicitly in
AL>phk's response above).

Unless you reset MAKEFLAGS along the call path to the portupgrade's make 
they'll see the -j, because the top-level make will stuff the -j into 
MAKEFLAGS and that is probably inherited through portupgrade.

harti