Subject: Re: Problem in new toolchain builds (need comments)
To: Todd Vierling <>
From: James Chacon <>
List: tech-toolchain
Date: 10/25/2001 01:08:46
>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 <> 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
>: 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, 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

I was planning on it. Like I said I wasn't wedded to the structure I proposed
so much as I wanted discussion on possibilities.

>: 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
>: ( and tools subdir).
>Look for "tools/", then.  That should be pretty definitive, and
>does the check for the existence of "tools" that I desire.

Either way works in the end for me (I did some testing and I agree with
the changes as well)

>: >:
>: >: .if defined(USE_NEW_TOOLCHAIN)
>: >: .endif
>: >
>: >Don't move this to <>.  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.

I realized that after I sent this :-)