> This is expected behavior, and I dare you to find a vendor make that does
> this differently.  8-)  I've never seen a make(1) that propagates this way;

I don't actually have access to any commercial *nix right now but
gmake (if that counts as a "make") does this and their doco claims
that its required behaviour for posix.2,  normally gmake allows you to
disable this behaviour by putting:

MAKEOVERRIDES=

in the makefile, but if you also put .POSIX: in the makefile, the
MAKEOVERRIDES= does _not_ disable propagation of command line vars via
MAKEFLAGS.

$ gmake -f tmf MAKEFILE=tmf rec VAR=override
env | grep MAKE
MAKEFLAGS=VAR=override MAKEFILE=tmf
MAKEFILE=tmf
MAKELEVEL=1
gmake -f tmf all
gmake[1]: Entering directory `/u0/share/arch/NetBSD/i386/src/sjg/bin/bmake'
VAR=override

As to -e, that's a bit of a sledge hammer.  If I put CC=/new/cc on
make's command line, and have to use -e to have it propagate, I aslo
get everything else in my environment overriding the makefiles rather
than just the one var.

Does anyone have access to the posix spec's and can verify whether the
GNU folk are correct?

> (A sidenote on the topic of make(1):  It seems <bsd.pkg.mk> uses
> "${MAKE} ${MAKEFLAGS}" to recurse.  That sound redundant to you?  Might
> explain why recursive pkgsrc makes end up with a bazillion duplicate
> flags in ps listings.)

Indeed.  Sounds like a bug.

--sjg