On 18 Apr 2001, Chris G. Demetriou wrote:

> > > Given that arm32 is currently being split up, perhaps it makes sense
> > > to make it the first guinea pig for:
> > >
> > > 	* install $(MACHINE_ARCH) includes as /usr/include/machine
> > > 	* install all of the $(MACHINE) variants in /usr/include
> > > 	* for user programs which have /usr/include/$(MACHINE)
> > > 	  dependencies, make them code for that explicitly.
> >
> > I'd have no objection to that.  How would this work for kernel compiles,
> > though?  Would they stay the same as they are now (so <machine/foo.h>
> > would get <${MACHINE}/foo.h> in the kernel and <${MACHINE_ARCH}/foo.h> in
> > userland)?
>
> Unfortunately, kernel and userland include the same files.  which
> means that it'd either have to be done the same way in each, or some
> (hopefully temporary) #ifdefs would have to be included.

Hmm.  Actually, I don't think my suggestion's entirely silly.  For
instance, for <machine/param.h>, you'd have:

---- sys/arch/arm/include/param.h: ----
#define MACHINE_ARCH "arm"
---- sys/arch/acorn32/include/param.h: ----
#define MACHINE "acorn32"
#include <arch/arm/include/param.h>
--------

These would be installed in (respectively) /usr/include/arm/param.h and
/usr/include/acorn32/param.h, with /usr/include/machine being a symlink to
"arm".

Thus, kernel files could include <machine/param.h> and get the
MACHINE-specific definitions, while user programs would just get the user
definitions (but could include <acorn32/param.h> if they really wanted).
sys header files would automatically get the right one for their
environment.

The main problem with this would be that we'd still have the slew of
${MACHINE} wrappers, but at least they wouldn't have to be installed.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>