Subject: Re: build.sh parameter confusion
To: Steven M. Bellovin <smb@research.att.com>
From: Greywolf <greywolf@starwolf.com>
List: current-users
Date: 06/17/2003 22:19:10
Thus spake Steven M. Bellovin ("SMB> ") sometime Today...

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

Hi, Steve,

Firstly, what you probably want to do is not name your toolsdir to include
the version of NetBSD that's running, since that changes more often than
the phase of the moon and the mood of the cook; in my experience, seeing
as the toolchain gets rebuilt every time, I just call it /usr/src/tools/
tools-${ARCH} to avoid having to constantly clean up after obsolete runs.  I
note that having the tools present and declared as TOOLDIR=... when
build.sh is run does not seem to help this at all.

Secondly, you will want a way to put /usr/src/tools/tools-$ARCH into your
path, even momentarily (I have a helper script I use if anyone wants it),
so that you can run the effective equivalent of:

	ARCH=whatever
	${TOOLDIR}/bin/nbmake-${ARCH}

[or nbconfig, or whatever you need to build your kernel.]

build.sh to build the kernel has proven quite cumbersome to me as it
wants to build *all* of them, so I use the old method, but using
the newly built nbmake and nbconfig to do so.

Lastly, if you want to put it into /etc/mk.conf, just put it in as
such:

.ifndef BSD_PKG_MK
DESTDIR=?	....
.endif

That way, it ought not to interfere with pkg building.  Let me know
if I'm wrong, because I need to find the *right* way to do it myself! :)

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

I'll second that -- being able to build the worlds for sparc, i386 and
macppc in under 3 hours is a boon.

				--*greywolf;
--
NetBSD: I Wanna Be Sedated!