Re: [bug #13952] Remaking included makefile fails under Linux RedHat 7.3 while working under Solaris 2.6

[Paul D. Smith]

%% Thibaud Gaillard <address@hidden> writes:

  tg> This is especially difficult in this case since "remaking"
  tg> makefiles is somewhat a hidden process in GNU make and very
  tg> difficult to catch.

It's not hidden at all; if you remove the "@" then you'll see the
commands as they're executed, just as with rebuilding any other target.
The only part that isn't immediately obvious is when make re-execs
itself.  But, it's easy enough to see this, too, if you enable debugging
(-d option).

  >> In this case I believe there is not a bug here.  It _seems_ that
  >> you're rebuilding the same included file (Makefile.dep) multiple
  >> times with multiple re-execs in between.  However, note that make's
  >> out-of-date algorithm does not consider a target to have actually
  >> been updated unless its timestamp has CHANGED.  If make runs a
  >> command and after the command the timestamp on the target is the
  >> same as it was before the command, then make doesn't think the
  >> target changed.  If make doesn't think that the Makefile.dep file
  >> changed, it won't re-exec.  In the case of the Linux systems, the
  >> re-exec and update of the file happens within a second, so if
  >> you're using a filesystem that doesn't support sub-second
  >> timestamps make won't realize the target was updated.

  tg> Yes, you are right: the same included file (Makefile.dep) is
  tg> rebuilt many time thanks to GNU make's "remake" feature. In this
  tg> case, 3 re-exec are needed to complete Makefile.dep (complete
  tg> means that this file will not change its timestamp when two
  tg> consecutive generations yield the same file, with respect to
  tg> diff).

  tg> Makefile.dep *changes* thanks to the
  tg> '$(update-target-from-tmp-if-different-only)' macro, and this is
  tg> confirmed under Linux when running make a second time on the
  tg> test-case, as it will finalize Makefile.dep. Why was not that done
  tg> during the first make run, then?

Because the first time, the timestamp DOES change.  Before, the file
doesn't exist.  After, it does exist.

  tg> I agree the problem may be in the filesystem (ext3 on my machine,
  tg> I guess it supports sub-second timestamps) in case it cannot track
  tg> time differences as small as two consecutive make re-exec, but in
  tg> that case, what can I do?

You have two choices that I can see: first, you can "sleep 1" before
updating the file so that it will always have a newer timestamp.

Or, you could use 3 different files instead of updating the same file 3
times.

  tg> This code was working on a (slower) Sparc Solaris 2.6, does it
  tg> mean that GNU make will stop working on much faster machines
  tg> because the filesystem resolution does not follow with higher
  tg> precision?

Assuming I'm right about what's happening, then yes, that's what it
means.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist