Hello Paul, Thanks for your answer.
> > It's extremely difficult to understand the test case you've provided: it's > good that you put effort into it but please keep the test cases as small and > simple as possible, removing all non-essential stuff, and please describe > precisely how the test case works in detail, and which part of the test > doesn't behave as you'd expect. > Sorry for the unintended complexity, i'll improve (simplify) in the future. I thought using macros would help understand the behavior when reading the code. This is especially difficult in this case since "remaking" makefiles is somewhat a hidden process in GNU make and very difficult to catch. > 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. > > If I'm incorrect about what the makefile is actually doing please let me > know. > Yes, you are right: the same included file (Makefile.dep) is rebuilt many time thanks to GNU make's "remake" feature. In this case, 3 re-exec are needed to complete Makefile.dep (complete means that this file will not change its timestamp when two consecutive generations yield the same file, with respect to diff). Makefile.dep *changes* thanks to the '$(update-target-from-tmp-if-different-only)' macro, and this is confirmed under Linux when running make a second time on the test-case, as it will finalize Makefile.dep. Why was not that done during the first make run, then? I agree the problem may be in the filesystem (ext3 on my machine, I guess it supports sub-second timestamps) in case it cannot track time differences as small as two consecutive make re-exec, but in that case, what can I do? This code was working on a (slower) Sparc Solaris 2.6, does it mean that GNU make will stop working on much faster machines because the filesystem resolution does not follow with higher precision? Thibaud _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
