Subject: Problem in new toolchain builds (need comments)
To: None <tech-toolchain@netbsd.org>
From: James Chacon <jchacon@genuity.net>
List: tech-toolchain
Date: 10/23/2001 13:36:51
Here's the problem:

When USETOOLS's gets set in bsd.own.mk (basically via USE_NEW_TOOLCHAIN right
now but eventually as the default on all platforms) it overrides all the
toolchain vars to reference the ones in $TOOLDIR.

i.e. 

CC=             ${TOOLDIR}/bin/${MACHINE_GNU_PLATFORM}-gcc

etc

It specifically doesn't set TOOLDIR if BSD_PKG_MK is set. However, that doesn't
work....

What about source that uses the system .mk files (say bsd.prog.mk) to build
themselves. With the new setup they've now all been broken unless before 
building their Makefile sets either:

USETOOLS=no

or

USE_NEW_TOOLCHAIN=no

(It currently breaks digest in pkgsrc which makes pkgsrc unable to bulk build
on anything using USE_NEW_TOOLCHAIN currently).

In my opinion this is pretty damn silly. The check should be the reverse
logically "don't turn this on *unless* we're building the source tree".

There are a number of ways to deal with this I've come up with so far and
each has issues which is why I want some discussion first:

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.

Pros:

Can go to anywhere in the tree and just like today/pre-new toolchain type
"make" and it DTRT.

Makes external source built against bsd.*.mk work as they always have without
worrying about setting new vars.

Cons:

Lots of extra cruft in the tree to make sure the recursion always takes place.
Otherwise new code added will start building with the native toolchain in
some places and the TOOLDIR/* ones in others.

Probably some slowdown in the build as this would happen on every make invoked.
(granted with good vnode cache sizes this won't really impact much).

2. Use a different bsd.own.mk to build the src tree with vs the one installed
for end users.

Pros:

Makes external source built against bsd.*.mk work as they always have without
worrying about setting new vars.

Cons:

Makes one have to remember to use the src/share/mk files when trying to build
a subdir in the tree:

ala making /bin/sh would now be:

cd bin/sh
make -m /usr/src/share/mk dependall

vs

cd bin/sh
make dependall

from today.

(the overall build wouldn't change because -m share/mk gets put into MAKEFLAGS
in the top level Makefile).

3. Document that any source using bsd.*.mk outside the source tree has to
set USETOOLS=no or USE_NEW_TOOLCHAIN=no (preferably the former).

Pros:

No changes needed to the .mk files/source tree/one-off build processes

Cons:

Lots...This is delibertly breaking behavior on anything except the main source
tree build for no real gain to an end user.

I'm sure there are other solutions here but the rest in my mind get even
more disgusting and maintaince nightmare driven.

I'm personally leaning towards #1 since it has the least impact on folks
building in-tree or their own source trees. The only real caveat will be
making sure any multi-dir hierarchies on imports get Makefile.inc's 
splattered out everywhere correctly. (I could probably write an audit script
to run against the source tree which made sure these all looked right as well).

Anyways, I'm open to thoughts here as this needs to be fixed. (and ASAP as I'd
like bulk pkgsrc builds to work for me again without having to hand craft it).

(Hmm...one I just thought of would be a top level Makefile.bsd-src or equiv
and have bsd.own.mk recurse looking for that until it finds it or hits /.
Gets rid of the real con on #1 in maintaince then..)

James