On 28 Oct 2001, Perry E. Metzger wrote:

: > that doesn't sound like the right behaviour to me at all.
: > why should people have to specify USETOOLS=no in contexts where USETOOLS=yes
: > cannot possibly work, ie. if TOOLDIR is not set?
:
: Because no one will set up their TOOLDIR variable properly the first
: time if they aren't forced to. This is the same reason we set the
: sources on the FTP site and the sup sets to the branch during release
: cycles -- to make people exercise stuff we need exercised.

There have been requests to add a default for TOOLDIR, and I have had some
reservations about this.  However, I do plan to add such a default, set to a
subdirectory of the top-level objdir (src/Makefile will include <bsd.obj.mk>
and create an objdir like everyone else, too).  This will make the defaults
buildable without forcing anything to be set.

: I think it is fine for consenting adults to explicitly set USETOOLS=no
: if they want to, but what you're arguing is that the default should be
: to let people to do things the unsupported way. Well, that's not right.

Right.  Also note that (as documented in the new BUILDING) the USETOOLS
variable will be tri-state, to emphasize the very different nature of
building without TOOLDIR.

"yes" = same as "yes" today.
"no" = don't use TOOLDIR, but *fail* if an attempt is made to compile a
       version-specific toolchain component (such as support libs)
"never" = don't use TOOLDIR, and blindly compile all the bundled toolchain
          components (the "traditional way to build")

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