Subject: Re: CVS commit: sharesrc/share/mk
To: Perry E. Metzger <email@example.com>
From: James Chacon <firstname.lastname@example.org>
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 email@example.com
>NetBSD Development, Support & CDs. http://www.wasabisystems.com/