> > Okay, so how do I build a sun3 kernel+userland on a next68k box?
> > Is that a native build??
> 
> Right now, in theory (i.e. not having looked into it) if you have to
> do more than set MACHINE in the environment, there are bugs.  That's
> how it should work.

... and set DESTDIR so you don't accidentally screw over your own installed
stuff. This starts to grate against the school of thought that says DESTDIR
should only be used to produce a clean tree for the creation of tarballs. I
suppose that as long as the host system has already done a non-DESTDIR build
of its own stuff beforehand, everything should be fine. (Other cross-build
efforts implicitly require this sort of thing already.)

> The Right Thing, of course, is to have the user-land programs
> completely common, i.e. there's no difference at all between a sun3
> userland and a next68k userland.

Agreed, but doesn't this beg the question: what's the point of having two
different ports, if everything outside of sys/ is the same for both of them?

I guess what I'm really railing against is the fact that we can't build a
"m68k userland" -- we can only build "sun3 userland" or "mac68k userland".
Because of this, the build system always has enough information to hack in
small differences. Proper construction of a sharable userland build demands
that we elminate port-selection information as an input, and only provide
the CPU architecture.

How hard would it be to support MACHINE==m68k ? That would be like having a
dummy m68k port. Mmmm, port-m68k.

> And what in the build system knows about the machine type, other than
> by the setting of MACHINE?  (Certainly, things could depend on the
> includes installed because of MACHINE, etc., but those are fixed by
> setting MACHINE properly and e.g. doing a DESTDIR-set build, no?)

Heck, I dunno, how can we be sure the build system doesn't have crap
in it that calls 'uname' instead of using MACHINE? It's a good thing
we don't call GNU config.guess anywhere, because that's what it does.

The people attempting cross-builds are eventually going to run into these,
if they exist.

> Also, actually having too many things shared is just broken.  how many
> optimization opportunities are missed because of the 'one code fits
> all' policy there?

Watch out; that line of reasoning ultimately calls for splitting up Alpha
so that you can have BWX capable machines versus the older ones.

> what's the right binary -- you can pick only one -- to install in a
> NetBSD/arm32 kernel distribution set?

I already answered this; my answer was "why not drop the requirement for
a single kern.tgz instead?"  I note that mac68k is a weird case, they have
kern.tgz and kern_sbc.tgz because unfortunately both kernels are needed
due to really nasty SCSI problems.

At the risk of revealing my ignorance about the sys/ tree, I don't see
how splitting it up is the only way to clean it up. How many radically
different vax systems are represented in its GENERIC kernel? What about
nubus vs. PCI powermacs, or PCI vs. TurboChannel Alphas? What are they
doing right that arm32 _can't_ _possibly_ also do right?

Isn't the real problem with arm32 that nobody has figured out how to make
a GENERIC that really works -- or is it that such a GENERIC would be so
large that no one wants to run it?

> well, more like mipsel, but direction agrees with what I consider
> 'right': MACHINE_ARCH common with binaries that interoperate, but
> different MACHINEs for different system families and non-interoperable
> kernels.

But! They're missing out on optimization opportunities, and on hpcmips
this was explicitly discussed. Ultimately they decided that interoperability
was more important, because overall, -msoftfloat was not important enough.

Hum. I guess the whole issue isn't as cut & dry as we'd like it to be...

Todd Whitesel
toddpw @ best.com