[ On , September 25, 2003 at 15:58:33 (-0400), Greg Troxel wrote: ]
> Subject: Re: build.sh '-u' behavior problematic with new installs
>
> The problem is failing to install include files that are not built -
> the actual 'make' part of the build works fine.

I'm wondering if maybe the way you are updating your source tree might
be causing source files to retain a last modified time equal to their
last change time instead of equal to the update time.  As you may know,
CVS, for example, ensures that files modified by "cvs update" have their
last modified time set to the time "cvs update" modifies the local copy
so that regardless of when the change was made any changed files can
never appear to be older than the last local build time.  If you're
using "rsync -t" or "sup -u" or similar then your sources could easily
end up being older than the time you last ran "build.sh" and thus a
changed include file may still appear to be older than the installed
copy of it.


On the other hand this may just be an instance of a class of problems
endemic to the traditional unix build process (and many other packages
using recursive-make build systems, though primarily it affects only
"development" systems, and especially self-hosted development systems).

In make-based build systems where timestamps on product files are used
to determine what to install, source files should never be installed
directly (i.e. source files should never be treated as product files) --
only derived files should ever be installed, even if the derivation
procedure is effectively "cat" or "cp" and neither the syntactic nor the
semantic meaning of the content is changed by the procedure.  Without
using a build system that can detect actual changes in source files
(i.e. when relying on source file timestamps to determine when product
files are out-of-date instead of asking the revision tracking system if
a change was made since a target was rebuilt), and when using a
recursive make procedure, and especially when other product files might
depend on already installed product files (as almost all NetBSD programs
depend on $DESTDIR/usr/include files), this is the only way one can
safely separate the construction phase from the install phase and ensure
that everything that needs to be installed as an intermediate product is
first built and then installed.

Now of course it helps to avoid unnecessary rebuilding of other products
that depend on such intermediate products if one uses "cmp" in addition
to timestamps when determining whether to install any intermediate
product file (i.e. any installed file that is also a dependency in some
other part of the build), at least where "cmp" is sufficient to check
whether a file has actually been changed (i.e. where rebuilding the
target doesn't change some meaningless internal timestamp or comment).

This extra rebuild work could also be avoided by never using any
installed file in any other part of the build, but that of course
requires that one always have a full source tree, and that one always
build all intermediate products, even if one only wishes to re-compile
one small program.  "build.sh" does effectively mandate this now, but it
also still allows the makefiles to be amenable to traditional
self-hosted rebuilds of individual programs using tools and intermediate
products that are part of the base-OS "development system" (comp.tgz :-).


-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>