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.

James

>
>
>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
>work.
>
>Perry
>--
>Perry E. Metzger		perry@wasabisystems.com
>--
>NetBSD Development, Support & CDs. http://www.wasabisystems.com/
>
>
>
>