>
>On Tue, 23 Oct 2001, James Chacon wrote:
>
>: That completely defeats the current ability to do
>:
>: cd usr.bin/vi
>: make
>:
>: and have it DTRT...Having to remember to set X number of new vars just to
>: get a build working is fairly silly and prone to failure.
>
>Yes, now I remember, that's the reason I did it this way!  8-)
>
>So, to make this work Right, I'll go with the original suggestion of
>sprinkling Makefile.inc's where needed.  This is the best solution to me;
>you really need Makefile.inc's throughout the tree to get everything "glued
>together" right anyhow (to pick up the proper BINDIR and LDSTATIC defaults
>for src/"foo", etc.).
>
>This will be implemented tomorrow.

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. The whole point of the source tree is that it shouldn't evolve into
"a maze of twisty little passages all alike" which is where it's headed with
assumptions upon assumptions upon variables like it is now.

That also with Simon's thoughts on this needs real extensive testing since
there are Makefile.inc's out there (and Makefile's) which will break in
places if they aren't double checked first. i.e. even if this is the right
route, I doubt just checking in a mass change tommorrow will get things...

Instead I think I have the simplest one so far that doesn't change much and
makes it work as we'd want in both the main source tree and outside it.

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.

James