Subject: Re: CVS commit: sharesrc/share/mk
To: Perry E. Metzger <>
From: Todd Vierling <>
List: tech-toolchain
Date: 10/29/2001 15:24:29
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 <>
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 <>  *  Wasabi NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support --