[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #13952] Remaking included makefile fails under Linux RedHat 7.3
From: |
Thibaud Gaillard |
Subject: |
Re: [bug #13952] Remaking included makefile fails under Linux RedHat 7.3 while working under Solaris 2.6 |
Date: |
Fri, 29 Jul 2005 19:42:09 +0200 |
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
- Re: [bug #13952] Remaking included makefile fails under Linux RedHat 7.3 while working under Solaris 2.6,
Thibaud Gaillard <=