In message <3EEFD0F8.882D10D5@greendragon.com>, William Allen Simpson writes:

>===
>
>What I'd really like is just visually consistent default behaviour.  
>
>If I'm in /usr/src and run ./build.sh build, it would be nice to have the 
>defaults just be /usr/obj and /usr/obj/tools and /usr/obj/release.  Is 
>this what happens?
>
>Likewise, if I'm in /home/NetBSD-current and run ./build.sh build, it 
>would be nice to have the defaults just be /home/NetBSD-current/obj and 
>/home/NetBSD-current/obj/tools and /home/NetBSD-current/obj/release.  
>AFAIK, this isn't what happens.  Is that -M?
>
>Examples would make the documentation a lot easier to understand....
>

Strong second.  The documentation for build.sh is truly dreadful.  It 
starts with a tree description, which is suboptimal but not awful.  It 
goes on to discuss environment variables which (a) are rarely needed by 
mortals, and (b) are redundant in part with command options (I think).

Next it describes the 'make' variables.  Since 'make' is the deprecated 
way to build systems, why is this next?  The 'make' targets are next -- 
but they come after the standard command line options, which are in the 
'make' man page.

We then get all the options to build.sh, but no examples.

What I want to do is (a) build userland; (b) build a kernel (and skip a 
redundant build of the toolchain), and (c) do an installation after 
booting the new kernel.  That latter seems to fail every time the build 
letter changes, because the toolchain under the new kernel isn't the 
same as the toolchain used to build the stuff.  (We'll leave out other 
infelicities such as why I have to set DESTDIR manually via -D every 
time, since when I put it in mk.conf it confuses my pkgsrc builds...)

It's good to have lots of flexibility, and I don't think I could design 
a better build process that could do cross-builds from any 
POSIX-compliant system.  But minor tweaks to the defaults and a few 
examples in the documentation would make a *very* big difference.


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)