greywolf@starwolf.com (Greywolf) writes:
> "Historic precedent indicates it."  BSD's include tree has always included
> an overlay of /sys/*/*.h.

And we should follow that, I assum you're saying?  Well, too bad
inflexibly sticking to bogus tradition has kept us from installing any
of the machine-dependent header files.  8-P

More seriously, NetBSD broke from this tradition almost 3 years ago,
with the set of commits like:

> revision 1.29
> date: 1998/06/12 23:22:30;  author: cgd;  state: Exp;  lines: +4 -93
> Rework the way kernel include files are installed.  In the new method,
> as with user-land programs, include files are installed by each directory
> in the tree that has includes to install.  (This allows more flexibility
> as to what gets installed, makes 'partial installs' easier, and gives us
> more options as to which machines' includes get installed at any given
> time.)  The old SYS_INCLUDES={symlinks,copies} behaviours are _both_
> still supported, though at least one bug in the 'symlinks' case is
> fixed by this change.  Include files can't be build before installation,
> so directories that have includes as targets (e.g. dev/pci) have to move
> those targets into a different Makefile.

The intent here was twofold:

(1) make it possible to trim the set of includes, so that random cruft
which isn't needed by userland doesn't have to be installed.  Yes,
this is important.  There are _megabytes_ of kernel headers which are
never needed in userland.

(2) to allow an eventual transition so that $(MACHINE_ARCH)'s headers
are what you get when you #include <machine/foo.h>, i.e. so that code
which depends on specific $(MACHINE)-dependent features/headers _must_
specially include that $(MACHINE)'s headers.  This would greatly help
binary compatibility, but it first requires setting up and sticking to
some $(MACHINE_ARCH) / $(MACHINE) distinctions.


re: (1): Certainly, I and others did some header pruning at the time,
and there's been some header pruning done sense.  But it's never been
done on a large scale... and it should be.

re: (2): Maybe the ARM ports, currently being split, would be a good
first test case for this...





> Whether this is symlinks or copies is implementation-dependent, however.
> We had it as copies ages ago because not everyone was allowed source
> access.

This is a nice thought, but as far as I can tell historically
incorrect, at least as far as sources/Makefiles that came out of
Berkeley.

CSRG, in Net-2 (iirc) and 4.4-Lite and -Lite2 (i just checked) shiped
source trees which defaulted to installing symlinks.  Presumably, the
supposition was, if you had the source to build from, you'd install it
in one place, oh and by the way you'd have it around.


> With the advent of opensource, this becomes moot.

You'd think that, but NetBSD switched to installing copies despite the
fact that it's always been open source.  Why, a couple of reasons:

(1) OK, just because you _can_ have the source tree, or even the sys
tree, installed, does that mean you should _have_ to to build programs
on the system?  I think the obvious answer is 'no', especially when the
source tree has grown as large as ours.  (no value judgement there.)

(2) Say you want the source tree.  What are the odds that you want it
in /usr/src?  Certainly, some people do this.  I have N source trees,
though, on M machines, and approximately none are in /usr/src.  Also,
who's to say that those source trees contain files which can be
resonably _used_ for /usr/include?

(3) Our /usr/include/* hiearchy does _not_ match our src/sys
hierarchy.



cgd