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: