Subject: Re: build.sh '-u' behavior problematic with new installs
To: Greg Troxel <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 09/25/2003 14:01:40
[ On , September 25, 2003 at 10:54:03 (-0400), Greg Troxel wrote: ]
> Subject: Re: build.sh '-u' behavior problematic with new installs
> Reflecting on all the comments, I favor changing the conditional
> install to install if timestamps differ or if content differs.
> But, it isn't clear that this is worth the effort.
Let's think for a moment about why timestamps are used by "make" in the
first place (i.e. instead of content comparisons of some sort (hashes)).
If I understand correctly it's because even in the days of the PDP-11
there was more CPU power available than disk bandwidth, given the
relative ratios of the CPU cycles required by compilers and other
similar tools, and this condition seems to have held true across the
Now from a software hygiene point of view the only "Right Thing(tm)" to
so is to _always_ install everything you build and to ignore timestamps.
All that remains is to decide what to build. IFF your build system can
identify all the interdependencies between source files and their
product object files, and IFF your build system can positively and
securely identify which source files have been changed since the last
build (e.g. by way of looking at revision numbers in the change tracking
system), then, and only then, can you avoid (re)building everything
Unfortunately with a recursive make system it is impossible to meet even
the first of those requirements without using timestamps to identify
out-of-date object and library files (since there are so many
dependencies between different parts of the source tree).
So long as we continue to use a recursive make system to manage builds,
and so long as one doesn't have either enough horsepower or patience to
rebuild everything every time and re-install everything every time, then
we're left with the compromise of using timestamps for at least part of
the build system and thus it doesn't seem to be worthwhile trying to
avoid use of timestamps on the final "install" part of a build.
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <email@example.com>
Planix, Inc. <firstname.lastname@example.org> Secrets of the Weird <email@example.com>