Subject: Re: CVS commit: sharesrc/share/mk
To: Perry E. Metzger <>
From: James Chacon <>
List: tech-toolchain
Date: 10/28/2001 18:00:29
I agree completely. If the default is yes, the check for $TOOLDIR should
be inside the usage of USETOOLS and shouldn't be the determining factor in
turning on USETOOLS.

I've had builds act "weird" just in forgetting to set my $DESTDIR sometimess.

The last thing I'd want is to not have $TOOLDIR set and get 
possible compiler/assembler/lint/make/etc (just to make 4 tools that have
changed and required UPDATING notes) errors to debug. By silently turning
off USETOOLS if $TOOLDIR is unset this is exactly what you'd get. Behaviors
should be explicit here, not implicit.


>I want to be clear on one thing on the USETOOLS situation.
>Todd wanted the build to break if USETOOLS was set to no. I disagree
>with that. If you want to set USETOOLS to no in, say, /etc/mk.conf so
>you never have to worry about it, you're free to. You can set the
>default for your own system any way you like. The question has been
>whether the overall default should be USETOOLS=yes, and that's
>certainly the case. That's the supported way to build the tree, or any
>of the items inside it.
>Again, though, if you don't like USETOOLS=yes, nothing stops you from
>setting it to NO for yourself. It is ten seconds of work. I cannot see
>why we would want to change the policy to save someone ten seconds of
>Perry E. Metzger
>NetBSD Development, Support & CDs.