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