On Sep 24, 2005, at 2:22 PM, Russ Allbery wrote:
Nicholas Clark <[EMAIL PROTECTED]> writes:
The distribution contains a shell script mv-if-diff, which does what
it
says. The Makefile uses it to avoid touching the timestamps on
automatically generated files, if they've not actually changed. For
example, lib/Config.pm
I notice that on my local checkout of maint, when I do a clean
rebuild,
lib/unicore/mktables is being run 7 times.
I also observe that sometimes when I edit files and rebuild, later
files
needlessly get rebuilt, probably because make thinks something is out
of
date, something that never gets updated, probably because it's not
being
"touch"ed, due to mv-if-diff, and there are non-file targets in the
dependency tree.
Parallel makes are also broken.
I wonder if all this is related.
It sounds like the problem isn't the existence of mv-if-diff, but
rather a
lack of capabilities in it. Shouldn't it touch the files that it
doesn't
need to replace? Then it would touch lib/Config.pm and all the right
things would happen.
The root cause is attempting to manage two pieces of information (the
date a file was changed, and the date it was confirmed up-to-date) with
one storage slot. Recognizing that a file may be current even though
it hasn't changed since its prerequisites have is an optimization,
which in traditional make usage is ignored -- being current is equated
with having been modified, so there's only one date to store.
If I were designing a Mac-specific implementation I might use the file
backup date (which is stored with other file metadata) as an up-to-date
stamp, but unless I'm mistaken a portable solution would require an
external data store.
Or you can just drop the broken optimization and always touch
up-to-date files, which is fully portable and guaranteed to work. :-)
Josh
