> Um, MAKEFLAGS should always be exported, according to POSIX; it's a
> particularly special case.  If it needs to be in a "special variable"
> because you're disabling the rest, fine.

Sorry, just to clarify.  Yes, MAKEFLAGS is always exported.
I now put the command line var settings in .MAKEOVERRIDES which is
exported as part of MAKEFLAGS in the environment.  Thus
.MAKEOVERRIDES=
effectively dissables the propagation of command line var settings via
MAKEFLAGS without impacting -k etc.

> The problem people had been seeing is that, say, a "-k" or "-m" was
> multiplying rapidly in sub-make recursion because they are also part of
> ${MAKE}.  "ps" lists were getting *huge*.

Umm, none of our make, freebsd's make, bmake, gmake put anything in
MAKE other than the name of the binary.  Note that if you don't have
POSIX defined (we do), it uses MAKE instead of MAKEFLAGS, but I can't
see that being useful.

All the above put things like -k -m etc in MAKEFLAGS and MFLAGS.
gmake, our make and bmake also put the command line vars in MAKEFLAGS
only.

So I think the current behaviour of our make (with the proposed patch)
is ok.  Note that gmake handles VAR="two words" by exporting it as 
VAR=two\ words
But using :Q to get that when expanding .MAKEOVERRIDES mucked up
duplicate suppression - which is probably worth having - esp in
pkgsrc.  So I use explicit quoting as in VAR='two words'.

--sjg