On Fri, Sep 23, 2016 at 11:23 AM, Paul Smith <psm...@gnu.org> wrote: > On Fri, 2016-09-23 at 05:52 -0700, David Boyce wrote: >> I still think that's a good plan, except that now I find out it ends >> up exporting anyway. I'm sure it's too late to change now but is >> there a reason for this (unfortunate IMHO) behavior? > > I can't tell you: this behavior has existed since the very first import > of GNU make code into source code control, back in 1991.
...and in System III in 1980: http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/make Looks like BSD picked it up in 4.4 around 1993 with the switch to pmake: http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/usr.bin/make POSIX specifies this behavior in the "Macros" subsection of the EXTENDED DESCRIPTION section for 'make'. About a page and half in is this paragraph: Before the makefile(s) are read, all of the make utility command line macro definitions (except the MAKEFLAGS macro or the SHELL macro) shall be added to the environment of make. Other + implementation-defined variables may also be added to the environment of make. Macros + defined by the MAKEFLAGS environment variable and macros defined in the makefile(s) shall + not be added to the environment of make if they are not already in its environment. With the + exception of SHELL (see below), it is unspecified whether macros defined in these ways update the value of an environment variable that already exists in the environment of make. (That's from the 2013 draft update; the '+' lines were modified from the original 2008 version of the standard, but that doesn't affect the first sentence.) Philip Guenther _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
