>
>
>   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.
>
>
>
>actually, the above is an argument against the change you made to
>the kernel makefile's, ie USETOOLS?=no.  the i386 assembler changes
>needed a new gas installed for kernel compiles.  bzzt.

I actaully had this argument with Todd in private last week as well. I'm
actually more convinced on this (the overall source tree requiring this) now
than before. Just too many places to get bitten otherwise.

People actually do treat syssrc as standalone from the rest of the source
tree (and it is self contained). So requiring that to use USETOOLS always
was wrong which is why I made the change there. In general folks will compile
kernels with their installed make/toolchain bits which will work as-is
except in very rare casses as you've just mentioned. That can't be said for
the mainline tree as much just from evidence and reading UPDATING.

For those times people have a complete /usr/src checked out and want to
build without setting up $TOOLDIR just do 

make USETOOLS=no 

just like you'd do

make MKSHARE=no MKLINT=no

or any other combination of flags one might use today to change the behavior
from the default that a complete make build would be using.


James