Subject: make(1): inconsistencies involving MAKEFLAGS inheritence.
To: None <netbsd-bugs@netbsd.org>
From: Paul Kranenburg <pk@cs.few.eur.nl>
List: netbsd-bugs
Date: 01/16/2002 16:59:37
>Number: 15264
>Category: toolchain
>Synopsis: make(1): inconsistencies involving MAKEFLAGS inheritence.
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Jan 16 07:00:00 PST 2002
>Closed-Date:
>Last-Modified: Wed Jan 16 07:49:30 PST 2002
>Release: NetBSD-current, january 2002
>Originator: Paul Kranenburg
>Organization:
>Environment:
>Description:
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.
This means that all invocations of make during makefile parsing
do not inherit the command-line options through the MAKEFLAGS
environment variable. This is a problem if the (top-level) make
command is invoked with the `-r' and/or `-m' options. In this case,
any subsidiary invocations of make will revert to the installed
system makefile and the default system include directory, thus
making it impossible to use a self-contained alternative set
of system make files by using the -m command line switch.
I note that one can work-around this issue by setting the MAKEFLAGS
environment variable with the appropriate switches when starting
the top-level make. But it would be so much nicer and less confusing
if both methods of passing these switches were completely equivalent.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->bin-bug-people
Responsible-Changed-By: pk
Responsible-Changed-When: Wed Jan 16 07:48:28 PST 2002
Responsible-Changed-Why:
Fix up category field.
>Unformatted: