>There are also problems with the script itself.  I'd have used 
>make-like semantics for -i, for example.  Have the build process create 

Note I'm totally pleased that I can use my i386 to build kernels etc
for my sparc's, the new toolchain is a big step forward...  I guess
I should actually buy a fast i386 now ;-)

The basic problem is that build.sh does too much too many different
ways.  Yet 99% of people will want to do it the same way (their 
preferred way) everytime.

Your usage looks pretty straight forward but for many what is needed
is a wrapper script for build.sh to pass all the options
one always wants - so they don't have to be entered every time ;-)
I'm still working out just what to put in my wrapper script 
just as I'm still working out how to drive build.sh

So far I can use (x-sh is a lousy name ;-):

x-sh -m sparc -o -t

to build a toolset for this host (and for the current branch).
(-o is a catchall for passing random rarely used args)

x-sh -m sparc -U 

to build a release - using destdir, releasedir etc

x-sh -m sparc -k TOO.MP

to build a kernel, which would actually run:

TOOLDIR=/NetBSD/tools/current/NetBSD-1.6_STABLE-i386
./build.sh -m sparc -M /var/obj/NetBSD/current/sparc/obj -D /var/obj/NetBSD/current/sparc/destdir -R /var/obj/NetBSD/current/sparc/release -k TOO.MP

whereas if I cd to 1.6.X/src... the same command would run:

TOOLDIR=/NetBSD/tools/1.6.X/NetBSD-1.6_STABLE-i386
./build.sh -m sparc -M /var/obj/NetBSD/1.6.X/sparc/obj -D /var/obj/NetBSD/1.6.X/sparc/destdir -R /var/obj/NetBSD/1.6.X/sparc/release -k TOO.MP

FWIW I usually install by unpacking the .tgz's

Another thing that anoys me is that if checkflist fails (common problem
when distrib/sets/lists are committed independently of the rest of a change)
even with

BUILD_DONE=yes UPDATE=yes etc, we still re-compile all the kernels.
That gets old real quick.

Note I've only recently started using build.sh - for ages I just used 
'mk'[1] with a .sandbox-env that sets MAKESYSPATH, MAKEOBJDIRPREFIX and 
USETOOLS=no ;-)  It "just worked" - but not for cross building
for that I use build.sh, though I probably only really need build.sh -t
to setup a toolchain.

--sjg

[1]. 'mk' is a make wrapper.  I use it for all sorts of things (we use
it for our builds at work too).  It simply searches up the tree 
until it finds .sandbox-env which it sources - after setting SB to the
directory where .sandbox-env was found.  It then exec's ${REAL_MAKE:-make} 

This simple mechanism provides mega flexibility for conditioning the 
environment - important for repeatable build results.  A comantion 
script 'mksb' can be used to configure a sandbox ($SB/.sandbox-env) 
and even cvs checkout whatever is appropriate, but I often 
create .sandbox-env manually.  'mk' is especially handy from within 
Emacs (M-x compile) particularly when working on multiple branches.