NetBSD Problem Report #15264
Received: (qmail 4416 invoked from network); 16 Jan 2002 14:59:27 -0000
Message-Id: <200201161458.g0GEwuV26399@sam.few.eur.nl>
Date: Wed, 16 Jan 2002 15:58:56 +0100 (MET)
From: Paul Kranenburg <pk@cs.few.eur.nl>
Reply-To: pk@cs.few.eur.nl
To: gnats-bugs@gnats.netbsd.org
Subject: make(1): inconsistencies involving MAKEFLAGS inheritence.
X-Send-Pr-Version: 3.95
>Number: 15264
>Category: toolchain
>Synopsis: make(1): inconsistencies involving MAKEFLAGS inheritence.
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: toolchain-manager
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Wed Jan 16 15:00:00 +0000 2002
>Closed-Date:
>Last-Modified: Tue Feb 12 08:59:07 +0000 2002
>Originator: Paul Kranenburg
>Release: NetBSD-current, january 2002
>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.
From: Todd Vierling <tv@wasabisystems.com>
To: Paul Kranenburg <pk@cs.few.eur.nl>
Cc: netbsd-bugs@netbsd.org, <gnats-bugs@netbsd.org>
Subject: Re: toolchain/15264: make(1): inconsistencies involving MAKEFLAGS
inheritence.
Date: Mon, 21 Jan 2002 10:38:46 -0500 (Eastern Standard Time)
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/
From: Paul Kranenburg <pk@cs.few.eur.nl>
To: Todd Vierling <tv@wasabisystems.com>
Cc: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: toolchain/15264: make(1): inconsistencies involving MAKEFLAGS inheritence.
Date: Tue, 22 Jan 2002 16:55:55 +0100 (MET)
> I presume by "top-level" you are referring to the NetBSD "src" tree.
No. This applies to any circumstance in which you want to specify an
alternative system make file directory by using `-m'.
> 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.
Well, it isn't the case. The MAKEFLAGS variable is not exported to child
processes until after makefile parsing has completed. So POSIX specifies
that all options except -f (and -p, which we don't have) should be exported
to all child processes.
But this does not make sense for all options currently accepted by our make(1).
I already made the case for -m and -r, and there are probably a lot more
which can be passed on without incident. But consider the effects of
propagating -n, -N, -q and -V, especially on `!=' invocations. In all
likelihood, this will not DTRT.
Responsible-Changed-From-To: bin-bug-people->toolchain-manager
Responsible-Changed-By: gnats
Responsible-Changed-When: Tue Feb 12 00:59:03 PST 2002
Responsible-Changed-Why:
There is now a "toolchain-manager" which is the proper default role
account for handling problem reports in the toolchain category.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.