Subject: Re: fixing the mismatched headers problem
To: None <>
From: Chris G Demetriou <Chris_G_Demetriou@UX2.SP.CS.CMU.EDU>
List: tech-userlevel
Date: 03/26/1996 22:29:09
> I'd like to solve this problem before 1.2, so I'm soliciting ideas.
> Two approaches I've thought of are:
>	[ ... ]
> 	* Add a general "install-headers" support to the bsd.*.mk files
> 	  so that "make install-headers" would descend the source dirs
> 	  and install headers in each header that has a install-header
>           target. 
> 	  A drawback of this approach is that builds will take longer due
>           to the additional source tree traversal.

I think that this is a step in the right direction, but the 'right
place' is a long way off.

In the long term, i think it'd be best to:

	(0) build the _whole_ NetBSD distribution (i.e. not just
	    includes) into a shadow tree, i.e. _require_ an obj-like

	(1) always link against objects in the shadow tree, if they're

	(2) build it in multiple passes, e.g.


	    then install it in multiple passes, e.g.:


	    and have 'build' and 'install' targets in makefiles at
	    every level that "do the right thing."

	    I'm probably missing at least a few targets.  8-)

These, taken together, would allow several serious advantages:

	(0) fixes the need to install stuff into /usr/{include,lib}
	    to build the system, without resorting to nasty trickery
	    with DESTDIR.

	(1) most of the hair involving building 'special'
	    sources could go away, at least partially.

	(2) the need for special goop to determine the location
	    of built programs & headers could go away.

	(3) it'd be possible to build and install only the pieces
	    that you want/need, easily, (e.g. i might want to update
	    all of my libs, and all of my includes, regardless of
	    where they are in the tree).  This would allow lots of
	    hair (e.g. the hunting down of 'special' subdirs in
	    'make build,' etc., to go away), and would generally
	    make life easier when doing this kind of stuff.

	(4) if properly implemented, could fix some of the kernel
	    library build nastiness, and could solve the "kernel
	    builds must write to the source tree" problem without
	    resorting to hacks like the union file system, which
	    are not practical for all situations.

Now, it's not clear to me that this is a 'simple' problem to solve, at
least in its entirety, and maybe couldn't be done 'right' for 1.2...

however, i think build-includes and install-includes targets, which
build into a shadow tree, should be doable without too much
difficulty, and are at worst a step in a direction that's
perpendicular to the one in which we should be going.  8-)