[gnu.utils.bug] Exporting Makefile variables into the environment can surprise

cks@WHITE.TORONTO.EDU (Chris Siebenmann) (06/01/89)

 Under Ultrix at least, you have a total limit for command arguments
plus passed-down environment variables; exceeding this limit causes
execve(2) to fail with E2BIG, usually reported by perror(3) as
	Arg list too long
which is of course accurate if slightly misleading for people who
aren't Unix wizards (execve(2)'s "arg list" includes the environment
as well as the conventional command arguments, although it took me
about an hour to notice this when I was tracking down the problem).

 The problem comes if you have a LOT of makefile variables, as one of
my makefiles does. GNU Make goes and puts these variables into the
environment, and commands with long command lines (~210 arguments
totalling more than 2000 bytes in my case) can start mysteriously
failing. It is annoying to track down, because standard Ultrix Make
doesn't export environment variables, and the same makefile will thus
work with Ultrix Make but not GNU Make.

 While I don't imagine many people will trip across this problem and
I've fixed it for the moment, it would be useful to have a 'noexport'
directive for makefile variables you KNOW are never going to be needed
in subcommands (I would actually prefer a 'export' directive instead,
on the principle of least surprise and backwards compatability, but
people may have started relying on GNU Make's behavior). This would
let me add object and source files to the makefile without worrying
whether this one will put me over the limit again.

[The problem is worse if you use ':=' a lot, since ':=' eats up more
 environment space than '='.]
---
	"I shall clasp my hands together and bow to the corners of the world."
			Number Ten Ox, "Bridge of Birds"
Chris Siebenmann		...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks
cks@white.toronto.edu	     or ...!utgpu!{,csri!}cks