Date: Wed, 5 Mar 2008 20:11:05 +0000 (UTC) From: Yar Tikhiy <yar@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/usr.bin/make main.c make.1 Message-ID: <200803052011.m25KB5kB088258@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
yar 2008-03-05 20:11:05 UTC
FreeBSD src repository
Modified files:
usr.bin/make main.c make.1
Log:
Don't forget to set MAKEFLAGS in the childs' environment
from the .MAKEFLAGS global variable even if it's empty or
unset. This means setting MAKEFLAGS to just an empty string
in the latter case.
If not doing so, make(1) behaved inconsistently WRT MAKEFLAGS.
In particular, it would let a `-f foo' option down to sub-makes
if .MAKEFLAGS was unset. E.g.,
env MAKEFLAGS="-f mymakefile" make
would pass `-f mymakefile' down to sub-makes via their environment
(unless mymakefile added something to .MAKEFLAGS).
But any additional options appearing would change this behaviour to
not passing `-f mymakefile' to sub-makes, as in:
env MAKEFLAGS="-f mymakefile" make -D DUMMY
or
env MAKEFLAGS="-f mymakefile -D DUMMY" make
(unless mymakefile cleared .MAKEFLAGS).
Also make(1) would leave MAKEFLAGS at its initial value if the
makefile set .MAKEFLAGS to an empty value. I.e., it was impossible
to override MAKEFLAGS with an empty value. (Note well that makefiles
are not to touch MAKEFLAGS directly, they alter .MAKEFLAGS instead.
So make(1) can filter out things such as -f when copying MAKEFLAGS
to .MAKEFLAGS at startup. Direct modifications to MAKEFLAGS just go
nowhere.)
While the original intentions of the BSD make authors are somewhat
unclear here, the bug proves that NOT passing -f options down is
the settled behaviour because the opposite behaviour is totally
unreliable in the presence of any other options. In addition, not
passing down -f's found in the environment is consistent with doing
so WRT the command line.
Update the manpage accordingly and make the whole description of
MAKEFLAGS and .MAKEFLAGS more consistent as this change indeed
brings more consistency into the reliable behaviour of make(1).
Submitted by: ru (main.c)
Tested with: make world
Revision Changes Path
1.166 +2 -0 src/usr.bin/make/main.c
1.108 +33 -31 src/usr.bin/make/make.1
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803052011.m25KB5kB088258>