Date: Mon, 15 Nov 2004 12:29:51 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Harti Brandt <harti@freebsd.org>, knu@freebsd.org Cc: current@freebsd.org Subject: Re: [TEST] make -j patch [take 2] Message-ID: <1100518191.4198932fc1dd4@netchild.homeip.net> In-Reply-To: <20041115091059.L51863@beagle.kn.op.dlr.de> References: <6857.1100271323@critter.freebsd.dk> <20041112160137.X42945@beagle.kn.op.dlr.de> <1100274897.4194dcd1d67d6@netchild.homeip.net> <20041112171024.P42945@beagle.kn.op.dlr.de> <20041113092215.7a40f133@Magellan.Leidinger.net> <20041115091059.L51863@beagle.kn.op.dlr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Zitat von Harti Brandt <harti@freebsd.org>:
[knu CCed because he should know how portupgrade operates :-)]
> 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.
I don't know how ruby handles exec()ing of external programs, but unless
it inherits the environment by default, portupgrade doesn't seems to
inherit MAKEFLAGS ("grep MAKEFLAGS /usr/local/lib/ruby/site_ruby/1.8/*
/usr/local/sbin/port*" shows no hits).
So if portupgrade inherits MAKEFLAGS somehow, phk's patch shouldn't
cause unexpected harm in this szenario, if portupgrade doesn't inherit
MAKEFLAGS, his patch violates POLA in this case.
Bye,
Alexander.
--
http://www.Leidinger.net/ Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org/ netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1100518191.4198932fc1dd4>