On Thu, 29 Nov 2001, Frederick Bruckman wrote:

: No. I don't mean to install the (renamed) "tools", into /usr, I mean to
: do another pass -- that is, to update and install the in-tree compiler,
: make, etc., then fork off another "make" and build with that. If you're
: not using "DESTDIR", you're going to update all that stuff anyway, so
: why not use it?

Because then you end up with a nonuniform build system for the tree.  The
idea is to choose *one* method that solves many common consistency problems
as a standard default, and provide configurable switches to let users pick
and choose nonstandard build methods.

: There's never a need for the user to monkey with the USETOOLS setting.

I think you may underestimate the diversity of the methods that NetBSD users
use to build the system.  8-)  The tri-state nature of USETOOLS exists
precisely because we're allowing users to pick and choose their build
methods, rather than forcing it down their throats.

We've only changed the default to be more reasonable with a full system
build; all other situations still have their old default (use the installed
toolchain).  And, no matter what the default is, it's configurable by the
user in every situation.

: > DESTDIR isn't *really* relevant.  The default of USETOOLS=yes for full
: > source trees exists because full source trees imply updating the system
: > incrementally from some base point (whether a release branch or -current).
:
: But "make release" or "make build", would always get the full treatment.
: I suggest that if someone types "make includes dependall install" in
: "sendmail", they never, ever really want to rebuild the full toolchain.
: If they want/need to build a new toolchain, they'll take it from the top.

If you only build a subtree, nothing's going to build a whole toolchain.
Building src/tools only happens when you build src/tools.

It's *use* of the external $TOOLDIR-based toolchain that is triggered by the
presence of a full source tree.  And if you really don't want to use the
external toolchain, you can force it off with USETOOLS.

People playing with full source trees *should* be using the external
toolchain for consistency, so that's the default.  Partial trees don't get
that default handling.

: The thing about using DESTDIR as the hook is: the arguments for never
: overwriting anything in the base system break down completely when you
: fail to have DESTDIR set.

I don't see how this is relevant to src/tools.  The point of the separate
toolchain is to have a consistent system build/update method, not to prevent
overwriting things in /.

: Acknowledged. Here's the point: I say if one pass is good, TWO IS
: BETTER. The benefit is, after the "tools" are built, and the "toolchain"
: is built, it looks and acts much like the old system.

Users can do two-pass builds easily themselves; it's made configurable by
USETOOLS.  First build the default way, then build with USETOOLS=no.

However, we won't be providing a way to do this kind of two-pass (actually,
three-pass, where the toolchain is concerned) build by some kind of funky
logic in src/Makefile.  It's too complex to ensure reliability.  "Keep it
simple...."

: No argument there. I wouldn't like to see work-arounds for pkgsrc
: problems in "bsd.own.mk", not at all. My concern is that some portable
: software, somewhere, will actually meet the apparent requirements for
: being in the NetBSD source tree ("build.sh" is not an unusual name).

I plan on making this check quite a bit more robust with its detection.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/