rdh@sun.UUCP (03/04/87)
In article <1938@utah-gr.UUCP> thomas%spline.UUCP@utah-gr.UUCP (Spencer W. Thomas) writes: >In article <688@rtech.UUCP> daveb@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.