Re: CVS commit: sharesrc/share/mk

[Chuck Silvers <chuq%chuq.com@localhost>]

hi,

On Sun, Oct 28, 2001 at 02:31:48AM -0500, Perry E. Metzger wrote:
> 
> Chuck Silvers <chs%netbsd.org@localhost> writes:
> > Module Name:        sharesrc
> > Committed By:       chs
> > Date:               Sun Oct 28 00:52:42 UTC 2001
> > 
> > Modified Files:
> >     sharesrc/share/mk: bsd.own.mk
> > 
> > Log Message:
> > if TOOLDIR is not defined, USETOOLS should default to "no",
> > since defaulting to "yes" will just give an error every time.
> 
> I'm not sure that's a good idea at all. In fact, it seems like the
> wrong policy, since it means that most people will not know to set
> TOOLDIR and won't use the new toolchain as intended. I'd suggest
> putting it back.

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.  after this change, the same commands
will build "ls".  this seems like a vast improvement to me.
what policy would you prefer?   why do you assume that without setting
TOOLDIR that the new toolchain won't be used?  I have the new toolchain
installed on my machine, which is why I didn't specify a TOOLDIR.
it isn't needed.


James' checkin which undid mine said:
> already gets checked and prints out an error if it's used without
> being set. You want to use it if USE_NEW_TOOLCHAIN is set and you're in
> the source tree by default.

printing an error doesn't seem like a very good response to someone
running "make", it seems to me that people would prefer that the compiler,
etc, be invoked.  no, I do not want to use the tools in TOOLDIR when I
did not set TOOLDIR, because that's impossible.  if I had wanted to use
the tools in TOOLDIR, I would have set TOOLDIR.


James' reply to Perry's message said:
> There's already a check for $TOOLDIR being set that will error out with a
> reasonable error message if it's not. I took this out as it was redudant
> (and less clear since your build could possibly do the wrong things then)

the error message is very nice as error messages go, but an error message
is not nearly as good as the correct result.  if my change were "redundant",
that would mean that the same result would occur with or without it.
since the result with my change is actually very different than the result
without it, I suggest that the change is not redundant.  without my change,
my build very definitely does the wrong thing, so I don't really see
how that's an improvement.


-Chuck