Subject: Re: Problem in new toolchain builds (need comments)
To: James Chacon <jchacon@genuity.net>
From: Todd Vierling <tv@wasabisystems.com>
List: tech-toolchain
Date: 10/24/2001 12:00:08
On Wed, 24 Oct 2001, James Chacon wrote:

: >This looks good, except that I'd prefer not to add a new file at the top
: >level and pull stuff away from <bsd.*.mk>.  All the USETOOLS logic was put
: >in <bsd.own.mk> specifically so it could be turned on (with proper
: >determination of whether a platform should be using the new toolchain by
: >default), even for a separately checked out subtree.  The definitions of
: >USE_NEW_TOOLCHAIN and USETOOLS need to stay where they are.
:
: Actually USETOOLS and the checks for it, etc are still in bsd.own.mk.
:
: What I pulled out were just the top level checks for when to turn it on.
: Keeping these in bsd.*.mk is actually the problem...Those are never needed
: except when building the source tree

You didn't read what I said.  "even for a separately checked out subtree".
Your changes move the USE_NEW_TOOLCHAIN default out of bsd.own.mk, and you
are going to hose things by doing that.

Please apply the changes I sent you and do not add a new file to the top
level.

: In any case it could be changed to a file test only, but I still prefer a known
: unique file at the top level rather then depending on current layout
: (build.sh and tools subdir).

Look for "tools/Makefile.host", then.  That should be pretty definitive, and
does the check for the existence of "tools" that I desire.

: >: MAKE+=  USETOOLS=${USETOOLS:Q}
: >:
: >: .if defined(USE_NEW_TOOLCHAIN)
: >: MAKE+=  USE_NEW_TOOLCHAIN=${USE_NEW_TOOLCHAIN:Q}
: >: .endif
: >
: >Don't move this to <bsd.own.mk>.  Let these be set by normal variable means.
: >
: >With these changes, this looks acceptable to me.
:
: These need to be added to $MAKE or they don't propogate to sub-makes. No other
: way around it.

You don't have to propagate it; that's the point.  If someone sets it in the
environment or mk.conf, it will get set each time; if it's auto-deduced from
the value of _SRC_TOP_, then that will set it.  (How do you think we work
with user-set changes to CWARNFLAGS, for instance?)  You only need to
propagate _SRC_TOP_, to avoid running the shellcode on every invocation.

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