(moved to tech-toolchain)


On Sun, Oct 28, 2001 at 12:22:27PM -0500, Perry E. Metzger wrote:
> 
> Chuck Silvers <chuq@chuq.com> writes:
> > it seems like a very good idea to me.  before this change, if I would
> > check out a fresh source tree, cd to .../bin/ls, and type "make",
> > it would always give an error.
> 
> 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?  what's wrong with
the having the build default to using the in-system tools when those
are the only tools available?


> > after this change, the same commands
> > will build "ls".  this seems like a vast improvement to me.
> 
> 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.


> > what policy would you prefer?   why do you assume that without setting
> > TOOLDIR that the new toolchain won't be used?
> 
> 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.  but why make life
more difficult for those people who don't want to use it by default?

now another, more valid effect that the current USETOOLS default has is
that it ensures that people are using the new toolchain on platforms where
that is the default now.  if this is desired, then we could enhance the
check to be

	if "in a full source tree" and USE_NEW_TOOLCHAIN=yes
		if installed compiler is gcc 2.95.3
			USETOOLS?=no
		else
			USETOOLS?=yes
	USETOOLS?=no

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?

-Chuck