"make" SHELL variable, OH NOOOOO!

[rdh at sun.UUCP]

In article <1938 at utah-gr.UUCP> thomas%spline.UUCP at utah-gr.UUCP (Spencer W. Thomas) writes:
>In article <688 at rtech.UUCP> daveb at rtech.UUCP writes:
>>
>>	Command line > environment > Makefile > default
>>
>	Command line > Makefile > environment > default
>

Well gang, its even worse than that.  You've left out the confusing 
effects of -e and the complication of nested make commands:

Topmost make:

(without -e)
>	Command line > Makefile > environment > default
(with -e)
>>	Command line > environment > Makefile > default

Nested makes:

(without -e)
	Command line > Makefile > environment > default > parent command line
(with -e)
	Command line > parent command line > environment > Makefile > default 

And of course, MAKEFLAGS takes the union of the value inherited (strictly from
the environment) with the flags from the current command line.  It exports the
combined value.  Since the fundamental behavior of nested make commands depends
on this warty exception, there's room for another special case: importing (or
exporting) SHELL seems like a bad idea to me.  A makefile with a non-sh shell
should say so, by specifying the shell to use in a definiton for SHELL.

Maybe it would have been better if -e took the name of an environment variable
to import as an argument.   This business of switching modes really gets 
wierd.  My rule of thumb is to clear the environment of any problem vars.,
and run make with -e and command line defs.

Maybe I'm overly cautious, but there's nothing quite like setting up a bunch
of environment vars. for a special build (typically small), forgetting to unset
them afterward, and making something big and important the wrong way later on!

-bob.