[ On Thu, June 29, 1995 at 00:02:22 (+1000), matthew green wrote: ]
   > Subject: Re: Compile of routed in -current ? .... 
   >
   > 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.
   
   On the contrary.  Not the parts that 'need' them, but rather it places
   include files in the area where responsibility resides for the
   interfaces and data structures defined by those files.
   
   I.e. <curses.h> belongs in the src/lib/libcurses directory.
   
ok.  what goes where ?  where do you put, say, unistd.h ?
src/lib/libc ?  yeah, why not.  but now if i want to just
build, say, src/lib/libkvm, i have to build libc first, so
that the heads get "built" in to the place where i can use
them from ?  with the current system, at least all (most) of
the headers live in the same place and it is easy to have
them all installed.
   
   This has already been done for man pages and other documentation.  Why
   not for headers?

because documentation is not required as part of the build
process.  i only unset my NOMAN variable every 3 or 4 months,
except if i see a change i want (or see a bug and check that
i have the most recent, etc..).

   > 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.
   
   Excuse me?  I see clarification, not complication.

i don't.  i see massive hacks required to get this to work.
   
   > 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.
   
   That's why encoding as much of the configuration management and
   inter-sub-system dependencies as possible into the makefiles is
   essential.  You should be able to type "make DESTDIR=/testroot install"
   from any point in the tree and re-install everything under that point
   without concern for what is already installed either in the current
   system, or under /testroot (so long as you don't assume the installed
   products are going to be run if they have some runtime dependency).

i agree fully with this.  infact, i believe it works right now,
except s/install/build/ for the make command.
   
   As I understand the proposal, or at least how I would expect things to
   work is that nothing in /usr/src should ever use /usr/include except the
   final step of copying the accumulated headers in /usr/src/include to
   /usr/include.  The only drawback is that we then must always assume the
   full tree is in one place, or provide hooks so the user can choose to
   use the installed defaults (i.e. /usr/include).

"only" ?
   
   The same technique should apply for the /usr/src/share/mk files.

the mk files need to be installed early in the build process,
and i believe this is missing right now.
   
   BTW, this is the first part of what is required in order to support full
   cross-compliation environments.

i don't see why.  the only parts that you have discussed here
that aren't already handled are the mk files, and these aren't
machine dependant anyway.

.mrg.