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