[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: |
Paul D. Smith |
Subject: |
Re: [bug #13952] Remaking included makefile fails under Linux RedHat 7.3 while working under Solaris 2.6 |
Date: |
Sat, 30 Jul 2005 23:21:30 -0400 |
%% 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