Subject: Re: obj.${MACHINE_ARCH} etc
To: Ben Harris <bjh21@netbsd.org>
From: Chris G. Demetriou <cgd@sibyte.com>
List: tech-userlevel
Date: 04/18/2001 10:02:19
Ben Harris <bjh21@netbsd.org> writes:
> Yeah, but we're a long way from there at the moment.

yeah, well.  I'm an eternal optimist.


> > 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.

Note that for many values of 'foo.h', the $(MACHINE_ARCH) one _is_ the
one that should be used, and a lot of the $(MACHINE) wrappers of
$(MACHINE_ARCH) headers should go away.

I suppose it ends up being a fairly big task.  *sigh*


> > Actually, the more that I think about it, the more
> > /usr/include/machine/$(MACHINE) makes sense to me, rather than totally
> > littering /usr/include with $(MACHINE)-named subdirs...
> 
> Heh.  I was looking at the ARMLinux Web pages today.  They have the
> equivalent of 67 different MACHINEs.

Indeed.  There's probably some unnecessary splitting there, but that
wouldn't change that number by _too_ much.  The order of magnitude (in
some base, i'd even venture a commonly used one 8-) would still be the
same...

by the time we get to that point, I think we'll have _had_ to fix this
issue once and for all, with userland sets complete shared by
$(MACHINE_ARCH), our we'll simply be crushed by the weight of the
stacks of disks necessary to hold our binary distributions.  8-)

we're starting to see more of a proliferation of e.g. eval boards,
etc., for various ports... it's starting to become a significant
problem now (and i'm sure many will say it's been one for a while).


cgd