I have committed all but one of the necessary bits to activate the new
toolchain on platforms where it is working.  My i386 is currently running a
"make build" to test the new setup.  Sometime near 02:00 UTC (10PM USA EDT,
7PM PDT, ...) I plan to flip the switch in <bsd.own.mk> that will make
USE_NEW_TOOLCHAIN the default on i386 and sparc64.

I've been awake for 26 hours running, so I'll be napping shortly, but below
is a brief documentation of what's coming up.  So, if you currently have
USE_NEW_TOOLCHAIN in /etc/mk.conf (against my prior advice), or you're doing
regular "make build"s, READ THE FOLLOWING.

(Note that the new build structure doesn't work as committed just yet;
there's a pending issue with inheriting variables in make's environment that
I have to tackle after I get some sleep.  I'll post again when this is
fixed.)

===

Quick Summary of New Toolchain Bootstrap

The new toolchain alters the way "make build" works at the top level, by
creating an external cross-compile toolchain for all builds.  When you run a
"make build", src/Makefile pulls in src/tools/Makefile.tools, which
overrides the valuses for CC, LD, etc., pointing instead to an external
toolchain located at ${TOOLDIR}.  Which means that:

*** You must now set TOOLDIR in /etc/mk.conf or the environment, or else
*** "make build" will break.

TOOLDIR should be a directory that is not mounted noexec (since the
toolchain will be running from here), and will hold the *host tools* for a
given MACHINE_ARCH -- which means that you will be able to cross-compile
shortly, right from the top level.  (It *may* work already; I only haven't
tested it, and need to finish the rest of the cross-tools just to make
sure.)

Even on `native' compiles, a cross toolchain will be used.  This eliminates
the problem of version skew that we've had in the past, resulting in such
inelegant hacks as the HAVE_GCC28!= stuff and funky ordering of
compiler/library builds.  Additionally, `double builds' (rebuilding the
world twice to ensure the compiler is up to date) will no longer be
necessary.

You may build the tools yourself, manually, at any time (good for diddling
inside the tree) by going to src/tools and running "make build".  The tools
will be built and installed according to your setting of MKTOOLS, below.

Finally, there's another option you can set in mk.conf to fine-tune how the
bootstrap cross toolchain works:

    MKTOOLS=no         (DEFAULT) Will break the build if a tool is
                       in need of updating (prevents accidental
                       overwriting of ${TOOLDIR})

    MKTOOLS=yes        Will build and install tools in ${TOOLDIR}
                       automatically, only as needed, based on source file
                       and/or ChangeLog file timestamps

    MKTOOLS=always     Will build and install the toolchain from scratch
                       on every `make build' (good for extra reliability on
                       fast machines)

===

Known issues:

* bmake isn't part of the cross tools yet.  I am working on a vendor-make
  bootstrap that will compile Berkeley make, followed by running "make
  build".  Not relevant to NetBSD-hosted builds.

* groff isn't part of the cross tools yet, but the build will default to
  using your installed groff (which should not be a problem).

* The crypto tools (mk_cmds, compile_et) aren't part of the cross tools yet.
  (Though they do compile in-tree, they don't have any compatibility
  fallback for systems that lack such things as setprogname().  Thus I had
  to set MKCRYPTO in my build, which is compiling -current from 1.5.1.)

* BFD is not unified (to support manipulation/disassembly of all NetBSD
  platforms on all NetBSD hosts) yet.

* There's something odd about lint, but I'll have to get to this after my
  nap.  I've set MKLINT=no on my test build in the interim until I can
  address this.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5 now available on CD-ROM  --  http://www.wasabisystems.com/