Subject: Re: CVS commit: sharesrc/share/mk
To: Chuck Silvers <chuq@chuq.com>
From: Perry E. Metzger <perry@wasabisystems.com>
List: tech-toolchain
Date: 10/28/2001 12:55:26
Chuck Silvers <chuq@chuq.com> writes:
> > And that's probably the right behavior. If you want it to work with
> > the in-system tools, just say make USETOOLS=no and all is well. What's
> > wrong with that?
> 
> 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.

> what's wrong with the having the build default to using the
> in-system tools when those are the only tools available?

Plenty. First of all, people will bitch that stuff is broken when it
isn't. "Why is it that building the world with USETOOLS=no doesn't
work?" "Because we don't support that -- you're now supposed to use
the tools so that we don't have to worry about tools getting out of
sync."

Second, if most people aren't using the tools, we won't get the system
properly exercised.

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.

> > But it isn't, because it means people will do full builds with
> > USETOOLS set to no.
> 
> does this mean that you aren't opposed to people building individual
> commands with USETOOLS=no, but only to people doing full builds with
> USETOOLS=no?  if so, that's not what the current bsd.own.mk code does.

I'm in favor of people generally using the tools. If they want to set
USETOOLS to no, they're a consenting adult and they know what they're
doing.

> > The question is one of the mechanism -- we want people exercising the
> > full "cross build even on the same architecture" way of doing
> > things. In addition, the change wasn't discussed on tech-toolchain,
> > and there was a good reason to have it the other way.
> 
> the whole cross-build thing is very cool, and many people will exercise it
> regardless of what happens when TOOLDIR is not set.

I doubt that. If nothing tells them to set USETOOLS and TOOLDIR they
won't.

> but why make life more difficult for those people who don't want to
> use it by default?

We no longer support doing it the other way. Remember how ever couple
of weeks current-users used to get flooded with "the build is broken!"
to which the response was "read UPDATING". Well, now we don't have to
do that any more -- with the cross mechanism, that's done with.

If people are consenting adults and want to set USETOOLS to no, that's
their business, but that's not the supported mechanism.

> the error message for USETOOLS=yes && !defined(TOOLDIR) could say that
> the new compiler is required and that the recommended way to get the
> new compiler is to set TOOLDIR and do the cross thing.
> would that be more acceptable?

It isn't the compiler. I'll say that over and over. It is the whole
mechanism. The way we do builds now means that if we change make and
the makefiles to have a new feature, or any other build tool things
still work. You're suggesting we re-break that by default.

--
Perry E. Metzger		perry@wasabisystems.com
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/