%% Thibaud Gaillard <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make