Date: Mon, 15 Nov 2004 14:10:42 +0100 (CET) From: Harti Brandt <harti@freebsd.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: current@freebsd.org Subject: Re: [TEST] make -j patch [take 2] Message-ID: <20041115140821.A51863@beagle.kn.op.dlr.de> In-Reply-To: <1100518191.4198932fc1dd4@netchild.homeip.net> References: <6857.1100271323@critter.freebsd.dk> <20041112160137.X42945@beagle.kn.op.dlr.de> <20041112171024.P42945@beagle.kn.op.dlr.de> <20041115091059.L51863@beagle.kn.op.dlr.de> <1100518191.4198932fc1dd4@netchild.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Nov 2004, Alexander Leidinger wrote:
AL>Zitat von Harti Brandt <harti@freebsd.org>:
AL>
AL>[knu CCed because he should know how portupgrade operates :-)]
AL>
AL>> Unless you reset MAKEFLAGS along the call path to the portupgrade's make
AL>> they'll see the -j, because the top-level make will stuff the -j into
AL>> MAKEFLAGS and that is probably inherited through portupgrade.
AL>
AL>I don't know how ruby handles exec()ing of external programs, but unless
AL>it inherits the environment by default, portupgrade doesn't seems to
AL>inherit MAKEFLAGS ("grep MAKEFLAGS /usr/local/lib/ruby/site_ruby/1.8/*
AL>/usr/local/sbin/port*" shows no hits).
AL>
AL>So if portupgrade inherits MAKEFLAGS somehow, phk's patch shouldn't
AL>cause unexpected harm in this szenario, if portupgrade doesn't inherit
AL>MAKEFLAGS, his patch violates POLA in this case.
At least portinstall doesn't touch MAKEFLAGS: insert something like
FOO!=echo -- ${MAKEFLAGS} >/tmp/A
into a port's makefile and call portinstall for than port:
MAKEFLAGS=-j2 portinstall ...
Would be strange if portupgrade would be different from portinstall. So
nothing is broken that wasn't already.
harti
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041115140821.A51863>