%% Henning Makholm <[EMAIL PROTECTED]> writes: hm> OK, it turned out to be a case of my worldview needing adjustment. hm> Somehow I've managed to go through life thinking that make works in hm> three separate phases: hm> 1. Read in the Makefile, expanding variables etc as you go hm> 2. Compute which commands needs to be run, comparing timestamps hm> etc. (As in make -n) hm> 3. Execute the predecided command sequence blindly, except if one hm> of them fails.
Nope. Two steps. hm> By the way, it is not *every* make that behaves this way. At least hm> /usr/ccs/bin/make on SunOS 5.7 doesn't. Yes it does. $ cat Makefile a: b ; @echo cp $< $@ b: c ; @echo "should change b--but don't" $ touch a b && sleep 1 && touch c $ gnumake should change b--but don't Notice, we don't run the "cp b a" rule. $ uname -a SunOS llama 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-5_10 $ /usr/ccs/bin/make should change b--but don't `a' is up to date. Again, it doesn't run the "cp b a" rule. hm> When I try it, I find that it is not quite sufficient. `make -t` hm> behaves weirdly, and now that I try it out, `make -n` behaves almost hm> as wierdly in a way I've never noticed before. Behold: hm> galar:~/foo$ make --version hm> GNU Make version 3.77, by Richard Stallman and Roland McGrath. I'm not sure about -t, but -n definitely had some very long-standing bugs that were finally noticed and fixed. Try a newer version of GNU make (the latest is 3.79.1). If you can repeat the unusual behaviors of either -t or -n with 3.79.1, let me know. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
