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

i'm sure he won't.
   
   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.

actually, i'd prefer that all installed header files, except those
associated with the kernel, be kept in src/include.  files like
<curses.h> should be moved in to here, so they are updated when the
rest of the includes are.

   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.

ick.  this would (seem to) spread all the include files in to the
various parts of the tree that need them.  that's horrible.  i'd
really just like what i suggested 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?'.

but what *other* problems crop up?  your suggestion seems to be
ripe for those bugs to infest.  it seems too complicated for the
desired result.  a little user education is what is really needed.
i can't feel sorry for people compiling the full netbsd tree who
aren't at least aware of the issues involved -- it is just too
big.

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

no, it's not.  that's why people *must* be aware of the issues
involved with building something as large as the full netbsd tree,
else they will just lose one day (hell, even if you do know what
you're doing, you'll lose one day  :-)

i must admit that i had the same reaction to your original proposal
as chris did.

.mrg.