[ On Friday, August 1, 2003 at 10:29:06 (-0700), Simon J. Gerraty wrote: ]
> Subject: Re: make should unset $ENV 
>
> My point is that no build should rely on $ENV causing a
> shell to do anything.

Strictly speaking I think most people with at least some SCM experience
will agree that no proper build system should ever rely on any
user-supplied environment variables -- i.e. that the user's environment
should always be sanitized, or at least sanity-checked.  Given the way
NetBSD's make is currently implemented this pretty much means using a
wrapper script

I.e. maybe the right fix is to wrap "make" with "env -i".   0.25 :-)

Certainly "build.sh" should (and does) fully sanitize and sanity-check
the environment, but that's somewhat different since the build.sh
maintainer(s) _should_ know all about all of the environment variables
that are used throughout the whole NetBSD build.

However I don't like the idea of "make" itself trying to be smarter
about one or a few odd little things like this.  Such a feature only
leads to a false sense of security (whenever it doesn't add to the
confusion), at least when you're dealing with third party makefiles and
scripts and what have you.

It probably would be useful to have a command-line flag for "make" that
does the equivalent of "env -i" except for the variables "make" itself
uses.  Special-casing for just ENV would be, well, not very smart, and
would be doubly bad if it's a silent and non-optional unset of ENV.

Note that I've been successfully using ENV="env -i" in my pkgsrc builds
for quite some time now.  Pkgsrc is easily capable of correctly setting
the environment for the builds it wraps and using "env -i" makes 100%
certain that no other environment variables not accounted for by the
pkgsrc maintainer are guaranteed unable to affect the way a package
builds.

Just to be clear about the other end of things:  I think it's entirely
proper for programs called on by the build system to use whatever
environment the build system supplies them.  I.e. "make" should not ever
silently clobber $ENV just before invoking the shell.  I can't think of
an obvious reason for "make" to supply the shell with a valid $ENV
setting in particular (except perhaps on systems which severely limit
the amount of environment variable space -- i.e. where using a file to
pass environment variables to the script is the only safe way), but that
in no way makes it valid for "make" to clobber an ENV setting that the
makefile itself may be providing by way of an exported macro of the same
name.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>