>> Wouldn't it be a good idea to have each makefile check that the includes
>> *are* up-to-date? This would save:
>
>I suppose that that begs the question:
>
>How, exactly, would one do that?!

I bet you're not going to like this (8-)>) ...

One of the things about NetBSD that was not obvious to me was how the
include files were managed. I can see that you like to keep the include files
in the branches of the source tree where they sort of belong. What confused
me was that the 'make install' of the include directory would go and suck
include files out of the src directories, rather than the makefile in the
relevant source directory controlling the release of the include files for use
by others.

For the purposes of this discussion, let's say that /usr/include is not used
at all during the compile of the kernel, libraries or any of the utilities;
leave it as the place where the include files end up in the final release.
Let's say that we use /usr/src/include as the directory where include files are 
released during the build process. If we start a clean build, /usr/src/include
is empty. When we build /usr/src/lib, we compile against just those include
files that belong to /usr/src/lib. At the end of /usr/src/lib, we release 
the include files and the libraries at the same time so that they match.  Now,
if there are system include files that /usr/src/lib needs, then there needs to
be a directory built before /usr/src/lib that releases these files and this
directory is brought up-to-date first by the makefile in the directory
above.

This style of building relies on having makefiles that allow the include
files to be managed without a '${MAKE} cleandir' between them and the lib,
gnu/lib, bin etc branches of the tree. If we set up makefiles that are
routinely used to build from the top down, with each directory being built
once (and only once) and with files being released as required, then we never
run into the problem of 'have you done a make install in /usr/sys/include?'.

Building software is a religious issue to me. Configuration management is
no trivial issue.

Another $0.02 worth.

>
>
>
>chris


John Birrell.