>
>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.

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
>: (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.

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

>
>: >: 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.
>

I realized that after I sent this :-)

James