On Sat, 2 Jun 2001, Simon J. Gerraty wrote:

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

This is news to me, but then, I haven't put up the near US$1k for a full
POSIX copy.  The IEEE is frigging insane when it comes to their "open"
standards pricing.

As to XCU5, it's not entirely clear whether the "options" placed in
MAKEFLAGS from the initial command line (if MAKEFLAGS is unset in the
initial envornment) include macro definitions.

Now, if it's something that a standard mandates, then i understand the
rationale, but I don't know if it should be done for our make(1) without
.POSIX: being set in the appropriate Makefile.

: As to -e, that's a bit of a sledge hammer.

My tongue was firmly planted in my cheek when I mentioned -e.  :)

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

That's what I thought.  From my checking, ${MAKE} even includes the options
normally passed down to sub-makes as it is.  If this were really need, I
think it'd be better as ${.MAKE} ${MAKEFLAGS}, but that's just unnecessary.
Perhaps I'll fix bsd.pkg.mk one of these days, and finally unrecurse the
damned thing while I'm at it.  8-)

(XCU5 says that MAKEFLAGS should be automatically incorporated into make's
option list if set in the environment, as well.  So if implemented properly,
${MAKE} doesn't even need to propagate options.)

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5 now available on CD-ROM  --  http://www.wasabisystems.com/