I pretty much buy cgd's argument. It does mean we have to change how
we do business, though:

1.  Some subset of the tree has to be coded `portably enough' that
    it will compile painlesly on non-NetBSD systems: FreBSD, LInux,
    Solaris, what-have-you.

2.  We need to figure out exactly what that toolset *is*.
    The NetBSD-to-NetBSD cross-compile work has found a chunk of it,
    but there's all the usual suspects -- byacc, lex/flex, compiler chain --
    in addition to the program-building tools inside monop, fortune,
    tn3270, and what-have-you.

3.  We need to make sure those tools build portably on non-netbsd
    systems.

4.  We need a concise and complete list of what a cross-developer
    has to build and install *before* she can start using bmake
    to chew through a cross-build.

If I've read Chris right, this has to tackle all the same as getting
from version N to version N+1 via source builds, *plus* doing that on
non-NetBSD hosts.  That means changing our goals somewhat, and
chagning coding style to match: e.g., Simon's toolsneed their own copy
of the relevant macros for a NetBSD off_t -- which, probably, has to
be done without assuming `long long' support or other 64-bit ints:
with structs.

An autoconfig phase to figureout the host environment might
help.  And we should put enough of the GNU tree back into gnu/dist
to let cross-builders do a normal GNU config for their target.

A Makefile to build the neceessary bootstrap tools would be great,
too.