Re: GNU make suggestion: did the dependency really change?

[Paul D. Smith]

%% Henning Makholm <address@hidden> 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 <address@hidden>          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