[ On Thursday, December 30, 1999 at 08:28:22 (-0800), Todd Whitesel wrote: ]
> Subject: Re: cross compiling -cuurent on 1.4/alpha
>
> >  The only major failing of the FreeBSD
> > build scheme that I'm aware of is that it doesn't work as a cross-build
> > system and as such does require that you be running a "current" kernel.
> 
> Those are in fact the hard parts.

Indeed!  :-)

I've often wondered at the relative merits of claiming success when you
can get an OS to re-build itself from it own sources.  In fact I've
often wondered if people don't just make a big deal about this to hide
the fact that it's often fundamentally easier to do than to do full
cross-builds from arbitrary host environments.  It's one thing to make a
compiler bootstrap, especially when you write it in the language it
implements, but quite a different thing to make a whole OS bootstrap
from sources.  It would seem to me that the latter only makes sense when
being done on a target platform that is indeed suitable for the task,
and though this has traditionally been true for most of the early
evolution of Unix on general purpose computing machines, it's no longer
*really* the case for many of the platforms NetBSD targets (due to
changing expectations, of course, not that any of those platforms are
actually getting slower!  :-).

Clearly a cross-build system can bootstrap itself too, but that's not
the point -- it's just an optimisation if the target hardware happens to
be powerful enough to consider as a development platform too.

Once upon a time long ago I used to build MS-DOS applications on a SCO
Xenix/286 system.  Some of my colleagues at the time (who stuck to doing
their work on MS-DOS) thought I was totally nuts and others thought I
was doing something devious and underhanded.  However I simply found it
nicer to be using "jove" and "sccs" and a slightly more current version
of the compiler and such, not to mention slightly longer case-sensitive
filenames, and other superior tools such as a version of "make" that
really worked.  I even had multiple console screens!  The only thing
subversive I was doing was also using my development machine as an
e-mail server, something the pure MS-DOS users obviously couldn't do,
especially since we didn't have a LAN either!  :-) I've even heard
rumours (directly from someone who visited and saw it for real) that
even Microsoft developed DOS, early versions of Windows and some
applications on Xenix systems for quite a long time (at least up to 1986
I think).  What's good for the gander is sometimes too good for the
goose, if you would believe them!

I've also had some experience, albiet relatively minor, working with
cross-compilation tools for embedded systems (primarily for the AT&T
DMD-5620 terminal, and I'll note that an older incarnation of the AT&T C
compiler is freely available in source form for that target environment,
and it is supposedly now capable of being hosted on a differently
endianed machine too! ;-).

Now of course cross-compiling to a single target is a heck of a lot
easier than cross-compiling to almost two dozen targets!  :-)

The really hard parts though, given that we use GCC which has almost
always been at least capable of cross-compilation, are the install
tools.  These tasks are messy, but in the end they're just bit-fiddling
and "simply" a matter of manipulating machine-dependent data structures
in a machine-independent way.  Even the metric for success is obvious.

If we ignore those bits for the moment though I think the biggest hurdle
is to teach the build system how to optionally use a specific set of
tools so that one can bootstrap hosted versions of the build tools that
will then be used to cross-compile the tree for the intended target.
People are apparently already working on getting cross-compilation to
work, so perhaps this one is almost cleared.

> Lately I've been hammering on 'make snapshot' so it is usable on sparc and
> sun3, results to be uploaded soon (sparc's happy, sun3 is on the final run).

That's cool!

But....  I'm not so interested in these "snapshot" things though.  I
personally think they're a distraction from the real job of producing
the products that go into a real release.  They might be "easier" to
build automatically, but if you spend all your time making their builds
work perfectly then who's going to work on making the release builds
work perfectly and automatically and who's going to use which format on
a regular basis?

As you say yourself, on of the major advantages of the FreeBSD scheme is
that it's in the tree and lots of people beat on it every day.  Even as
far back as FreeBSD-2.1.x it was relatively easy to do a full build
right to CD-ROM images (and of course you don't need to re-boot a new
kernel in the middle of the process if you're already running a
compatible one!).

> Even a 20 mhz sun3 can produce a snapshot all by itself every two weeks,
> if most of the process is automated.

I should try my 3/280 w/128MB and -pipe someday.  I don't know if I can
afford to run it full time even during the winter though, at least not
with all the other gear I'm running (I don't think the added power cost
offsets the gas savings!)....  and I really need a proper fan tray for
it before I even consider dragging it out of the garage, hoisting it
into the rack, and powering it up again! :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>