>
>>1. Put a complete set of Makefile.inc's in place in the tree that eventually
>>all recurse back to /usr/src/Makefile.inc. Put all the USE_NEW_TOOLCHAIN and
>>USETOOLS checks in there.
>
>I was in favour of this a while back.  An alternative is to have a reliable
>means of knowing where the top of the src tree is.  Which btw a top-level
>Makefile.inc gives you:  SRCTOP=${.PARSEDIR}.
>
>Now, I use a wrapper script for make that searches up the src tree until it
>find a .sandbox-env file, and the directory where it find that is set as SB.
>The SRCTOP is typically $SB/src - unless .sandbox-env says different.
>With that availble it becomes pretty easy to set a whole raft of variables
>that give you absolute and relative paths to top of src tree, top of obj tree
>etc.  Including ${SRCTOP}/Makefile.inc also becomes pretty simple and cheap
>to.  The wrapper is only involved in the kicking off of the build, so the
>overhead is not too great - and of course you get the right result regardless
>of where within the tree you start.

The only real concern I have there is teaching people to type something
different than "make" when they cd into part of the srcdir and work on it.
It quite honestly is pretty hardwired into most developer types by this 
point. Unless you wanna wrapper the main make binary to check this...(ok thats
getting sick)

>
>But if you don't want to go that route, then the Makefile.inc's is the
>best bet.  Note that you need to watchout for existing places in the tree
>that have .include "../../Makefile.inc" as the addition of new Makefile.inc's
>can change what gets .included (a bitch to debug btw).

The only problem I'm still having here is maintaince. Say you add a new 
program to usr.bin that's structured like xlint:

xlint/
xlint/Makefile
xlint/lint1
xlint/lint2
xlint/xlint

Up until 2 days ago it didn't have a Makefile.inc (needed it for different
reasons). With the Makefile.inc thing anyone importing new code will have
to remember to sprinkle them across new tree's or they won't get the right
toolchains when they build. One could make a foo2netbsd that did this, but
is really feels like a hack in a lot of ways.

I'm thinking my last idea might be the best. Have bsd.own.mk use a != rule
to recurse back and set a var based on whether it finds a top level 
Makefile.foo. The biggest concern there would be overhead but the maintaince
nightmares go away.

James