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:

NetBSD Home
NetBSD PR Database Search

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