Subject: Re: Problem in new toolchain builds (need comments)
To: Simon J. Gerraty <>
From: James Chacon <>
List: tech-toolchain
Date: 10/25/2001 01:29:03
1. Where is all this distinction documented? I can't fathom any of this from
the man page. (nor the source especially from a cursory glance)

2. It doesn't work as one would expect. If you add the vars to any of either
MAKEFLAGS, .MAKEFLAGS, .MAKEOVERRIDES, etc they all get passed to the followon
makes. But they don't seem to get parsed apart again into var=value in the

Here's the current patch which makes all this work. I left a debug echo
in there so you could see this in action.

cd bin/cat
make -m ../../share/mk cleandir
make -m ../../share/mk dependall

If you set the 


line to




(or any other combination), it's very obvious that the rule runs on every
exection of each make which is what I'm trying to avoid.

(Beyond that the rest is as people have sent comments on so barring some
explanation on how all these "magic variables" work I plan on commiting this
after a few tests in the morning)


--- share/mk/ 2001/10/23 22:55:30     1.193
+++ share/mk/ 2001/10/25 05:27:55
@@ -19,10 +19,21 @@
-.if defined(BSD_PKG_MK) || !defined(USE_NEW_TOOLCHAIN)
-USETOOLS:=     no
+.if !defined(_SRC_TOP_)
+# Find the top of the source tree if we're inside of $BSDSRCDIR
+_SRC_TOP_!= cd ${.CURDIR}; while :; do \
+               here=`pwd`; echo "$$here" >&2; \
+               [ -f  ] && [ -d tools ] && { echo $$here; break; }; \
+               case $$here in /) break;; esac; \
+               cd ..; done 
-USETOOLS?=     yes
+.if (${_SRC_TOP_} != "") && defined(USE_NEW_TOOLCHAIN)
+USETOOLS?=      yes
+USETOOLS?=      no
 .if ${MACHINE_ARCH} == "mips" || ${MACHINE_ARCH} == "sh3"

>>>>+MAKE+= _SRC_TOP_=${_SRC_TOP_:Q}
>>>Also I'm not at all keen on appending to MAKE.
>>>Use .MAKEFLAGS or 
>>Doesn't work. MAKEFLAGS gets passed in, but doesn't get evaluated so it's
>The MAKEFLAGS #define in the source is ".MAKEFLAGS" btw.
>When you update .MAKEFLAGS it is processed as though it came 
>from the command line.
>>pointless. Check the source, only $MAKE gets re-evaluated on a new make.
>Not so.
>>>will do the trick.
>>Didn't try that. $MAKE works and reading the source MAKEOVERRIDES doesn't
>>get evaluated either.
>Again, .MAKEOVERIDES is not the same as MAKEOVERRIDES.
>.MAKEOVERRIDES is used to control how command line var assignments get
>propagated to sub-makes.  I know - I implemented it :-)