Subject: Re: toolchain/15264: make(1): inconsistencies involving MAKEFLAGS
To: Paul Kranenburg <pk@cs.few.eur.nl>
From: Todd Vierling <tv@wasabisystems.com>
List: netbsd-bugs
Date: 01/21/2002 10:38:46
On Wed, 16 Jan 2002, Paul Kranenburg wrote:

: 	make's manual page states that "the MAKEFLAGS variable is
: 	entered into the environment for all program which make
: 	executes". This is not the case (and nor should it be), since
: 	this environment variable is not made available until rules
: 	processing begins.

The above paragraph doesn't readily brain-parse, so I'm not exactly sure
what you are describing as a problem here.

SUSv2 (& POSIX) demands that command line options be put into MAKEFLAGS,
contrary to your "nor should it be" above:

  When the command-line options -f or -p are used, they will take effect
  regardless of whether they also appear in MAKEFLAGS. If they otherwise
  appear in MAKEFLAGS, the result is undefined. The MAKEFLAGS variable will
  be accessed from the environment before the makefile is read. At that
  time, all of the options (except -f and -p) and command-line macros not
  already included in MAKEFLAGS are added to the MAKEFLAGS macro. The
  MAKEFLAGS macro will be passed into the environment as an environment
  variable for all child processes. If the MAKEFLAGS macro is subsequently
  set by the makefile, it replaces the MAKEFLAGS variable currently found in
  the environment.

: 	This means that all invocations of make during makefile parsing
: 	do not inherit the command-line options through the MAKEFLAGS
: 	environment variable.

Like ${PRINTOBJDIR} et al?

As per POSIX, I believe these options should be made available bin MAKEFLAGS
efore Makefile parsing begins, and thus available to != invocations.  If
this isn't the case, it's a bug.

: This is a problem if the (top-level) make
: 	command is invoked with the `-r' and/or `-m' options.

I presume by "top-level" you are referring to the NetBSD "src" tree.
The top-level Makefile has:

    .MAKEFLAGS: -m ${.CURDIR}/share/mk

This is very deliberate, to make sure that a src tree build pulls in the
correct share/mk files.  No other -m path should be used with src, period.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/