Subject: Re: build.sh '-u' behavior problematic with new installs
To: Greg Troxel <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 09/27/2003 03:25:27
[ On Friday, September 26, 2003 at 19:23:10 (-0400), Greg Troxel wrote: ]
> Subject: Re: build.sh '-u' behavior problematic with new installs
> I'm aware of that make-coddling behavior :-), but this is with a fresh
> checkout and hence last-checkin mtimes. I am installing onto a fresh
> 1.6.1 install. The problem is that the mod time of e.g. files in
> /usr/include/net in the filesystem from the install is the date that
> the release was made, not the date that the file was last modified.
> Regardless of correctness issues, I actually like it that the files in
> /usr/incldue have an mtime of their last actual change in the sources.
Well, like it or not, that (having timestamps on include files match
their source files) is the ultimate cause of all your problems.
I was trying to figure out how you could get include files that were
newer than source files, and I'm still not 100% certain I understand,
but since you mention using /usr/include with build.sh you must be
trying to avoid use of a separate $DESTDIR and to always install
immediately into DESTDIR=/.
In any case this is why in recursive-make build systems where timestamps
are used to identify out of date products, _all_ product files which are
intermediate dependencies of other products _must_ have a last modified
time set to their build/install time, _not_ the last-modified time of
their source files. This is why it really is important to never install
source files directly but rather to always derive product files from
them and then only install those product files, even if the derivation
procedure is just "cp" or "cat".
It just so happens that the use of a separate $DESTDIR with build.sh
does effectively meet this requirement. It's not clean or perfect
(since the timestamps can still be foiled -- the installed files are not
dated at their install time), but it does happen to work more or less by
accident (because the includes are copied from your new source, not from
the base OS) and it's one of the reasons why Luke and other developers
harp on the fact that it's the only supported way of using build.sh.
(I really don't understand why anyone would ever want timestamps on
product files to ever match their source file timestamps -- that has
always caused a great deal of confusion for me directly, never mind
being a major problem for intermediate files in any recursive make
system! Perhaps the problem is that you think of them as source files
insead of thinking of them as the intermediate product files they really
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>