Subject: Re: CVS commit: sharesrc/share/mk
To: Perry E. Metzger <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
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 <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 <email@example.com> * Wasabi NetBSD: Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/