Subject: Re: build.sh parameter confusion
To: Steven M. Bellovin <smb@research.att.com>
From: Luke Mewburn <lukem@netbsd.org>
List: current-users
Date: 06/19/2003 09:08:36
On Tue, Jun 17, 2003 at 11:53:31PM -0400, Steven M. Bellovin wrote:
  | We then get all the options to build.sh, but no examples.

The tail end of /usr/src/BUILDING has 4 very simple (and working)
examples.  They used to be a lot more complicated, but I've since
simplified these down to the bare minimum, in the hope that they'll be
easier to understand AND document.


  | 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.

The "auto selection of TOOLDIR" is one area I'm still not satisfied
with; I explicitly set TOOLDIR but I know that many people don't.
I need to think about the ramifications of changing the method that
TOOLDIR is determined to be similar to how the defaults for DESTDIR
and RELEASEDIR are determined.



(IMHO, there's also a bunch of "flexibility" in the build system that
predates build.sh and arguably could be removed where it simplifies
the maintenance of the build system and there's a "better" way to
solve that problem, but I fear the howls of protest will be loud
and never ending.)