On Tue, 23 Oct 2001, James Chacon wrote:

: I'm not trying to just argue here, but read back on my thoughts here on
: maintaince. This will bite people unless this gets ingrained that they
: have to get out the "Makefile.inc wand" and sprinkle it across any new
: imports.

This will be documented.  I've been writing a pretty involved paper
describing all of these types of intricacies.  But anyway, I'll pull away
from this issue for a moment to address the following:

: Add a new Makefile at the top-level called Makefile.build. Put the bsd.own.mk
: rules in which check/set USE_NEW_TOOLCHAIN and then turn on USETOOLS.
: i.e. the top 20 lines or so before it starts setting toolchain vars.
:
: Then to access it all bsd.own.mk needs is something that can recurse back
: till it finds a Makefile.build and pulls it in, or reaches /. A != rule can
: accomplish this easily enough (I roughed it out in sh already and other than
: some tuning works fine.

Well, this is possible, provided that the shell rule is executed exactly
*once* by propagating the value to sub-makes.  There's a way to do this;
something like the following should work (untested):

.ifndef SRCTOP
SRCTOP!=	[shellcode here]
MAKEFLAGS+=	SRCTOP=${SRCTOP:Q}
.endif

As an aside, you'd automagically also get the location of the top of the
source tree, if you add a `pwd` resolver into the end of the script.  It
could even be used to set BSDSRCDIR implicitly, come to think of it....

Feel free to try implementing this and let me know what you come up with.  A
check that looks for a file named "build.sh" and a directory named "tools"
in the same dir should give you a usable result.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/