--pgp-sign-Multipart_Tue_Mar_20_22:35:18_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Tue, 20 Mar 2007 22:49:54 +0100,
Thierry Lacoste wrote:
>=20
> That is clear for "build.sh distribution" but I realize that
> I don't understand why the build tools are needed at all for
> "build.sh install" as I just saw it as essentially a mere copy
> of files from obj to their respective final location (pretty much
> like when I install from sets).

When "build.sh" is using the tools in $TOOLDIR it _always_ uses the
tools in $TOOLDIR.  Look in $TOOLDIR/bin and see what's there.
Everything there is used for every phase and step driven by "build.sh",
and all of that stuff is set up to run _only_ on the build host itself.

$TOOLDIR is not a copy of the files from $OBJDIR -- it is a complete set
of compiler and build tools specific to the source tree being built that
was compiled to be run on the build host so that it can build that
source tree for any kind of target platform.  (the build of $TOOLDIR
using the build host's native toolchain happens to also use $OBJDIR, but
that's just a convenience)

$TOOLDIR is also, potentially, a full cross-build toolchain.  I.e. the
build host can be a zippy new Intel Xeon multi-CPU host and the target
sets can be compiled to run on a dingy old sparcstation (or whatever).

In theory one could even package up a pre-built binary $TOOLDIR for
various platforms and then be able to use it build netbsd complete from
source without even having a native toolchain installed on the build
host.

Even if the target host _is_ the build host it still makes more sense to
build the sets archives and then upack them than it does to try to do a
full live install with DESTDIR=3D/.  That just invites all kinds of
troubles that you don't want to even think about.


If you really want to avoid using a separate toolchain to build NetBSD
and instead to use the build host's own native toolchain exclusively
then don't use build.sh at all and make sure you set "USETOOLS=3Dnever" in
/etc/mk.conf and just build with "make" like you would have before there
was a "build.sh", and either build sets or, if you're very brave, set
DESTDIR=3D/ and install to your live system.  Then IFF that works and if
you're lucky enough to be able to keep your build host and your target
hosts in full synchronization, and they're all the same kind of
platform, then you can probably mount your source and object directories
on the target host and do a "make install" on the targets too.  I
wouldn't recommend doing anything in this paragraph though.


For me the benefits of using a full toolchain associated with the source
tree I'm trying to build are so vastly enormous I'll never try to go
back to native builds for anything but emergency fixes of individual
programs (or maybe the kernel).  For example, I'm right now finally
getting a build of netbsd-1-6 to run on a netbsd-4 host.  I could
equally well have run it on a FreeBSD or Linux or any other kind of
compatible build host.  I can now build all the many netbsd releases I
have to support (with at least three separate target architectures at
the moment) on my very fastest server.  If only I could use $TOOLDIR as
the tools to build pkgsrc too!

In theory one can also share $TOOLDIR between identical kinds of build
hosts in a cluster too, provided all the other *DIR settings can be kept
consistent across all the hosts in the build cluster, and presumably so
long as each build host does _not_ actually share their other *DIR
settings.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Tue_Mar_20_22:35:18_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: lvDL6LlpyqhWsRiMLOhhVf8JMwrKDhMU

iQA/AwUBRgCZ6GZ9cbd4v/R/EQIY3wCeLbenobiEeKtGXTLhtZW+BRtkgaoAoJtj
YAwSV6bLl/0D4cCA7OEwZC8m
=qkR5
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Tue_Mar_20_22:35:18_2007-1--