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

[Thibaud Gaillard]

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