bugmake - Bugs: bug #2216, MAKEFLAGS not updated when it...

 
 

bug #2216: MAKEFLAGS not updated when it already exists

Submitter:  Alexandre Duret-Lutz <adl>
Submitted:  Tue 14 Jan 2003 10:17:47 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  3.80 Operating System:  Any
Fixed Release:  4.0 Triage Status:  Verified
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 13 May 2013 06:49:07 AM UTC, comment #3: 

Fix pushed.

Paul D. Smith <psmith>
Group administrator
Mon 13 May 2013 06:01:12 AM UTC, comment #2: 

I checked this.  The problem only occurs with the -e flag, because by specifying -e you're explicitly saying that the value from the environment variable should supersede any value set in the makefile.  GNU make is treating this as true for the MAKEFLAGS value obtained from the environment as well: if -e is on the command line and MAKEFLAGS is set in the environment it takes precedence over the value set in the makefile, or by make.

For other flags I've tried, such as -k etc., this behavior is not seen (the flags are passed down to sub-makes and not lost).

The standard does not address this directly but I expect it intends for the override of the MAKEFLAGS environment variable using -e to not take effect (that is, GNU make's behavior here is wrong).

Paul D. Smith <psmith>
Group administrator
Sat 03 Oct 2009 08:09:16 PM UTC, comment #1: 

Added a test for this to the regression suite.

Paul D. Smith <psmith>
Group administrator
Tue 14 Jan 2003 10:17:47 PM UTC, original submission:  

From: Alexandre Duret-Lutz <duret_g@lrde.epita.fr>
Subject: MAKEFLAGS not updated when it already exists?
To: -email is unavailable-
Date: Tue, 14 Jan 2003 22:27:13 +0100

Hi Paul,

POSIX documents MAKEFLAGS thusly:

     Before the makefile(s) are read, all of the make utility command line
     options (except -f and -p) and make utility command line macro
     definitions (except any for the MAKEFLAGS macro), not already included
     in the MAKEFLAGS macro, shall be added to the MAKEFLAGS macro, quoted in
     an implementation-defined manner such that when MAKEFLAGS is read by
     another instance of the make command, the original macro's value is
     recovered. Other implementation-defined options and macros may also be
     added to the MAKEFLAGS macro. If this modifies the value of the
     MAKEFLAGS macro, or, if the MAKEFLAGS macro is modified at any
     subsequent time, the MAKEFLAGS environment variable shall be modified to
     match the new value of the MAKEFLAGS macro. The result of setting
     MAKEFLAGS in the Makefile is unspecified.

As far as I understand the beginning, it means that when running
Make recursively, flags passed at each step should accumulate in
MAKEFLAGS.  (The comment about "such that ... the original
macro's value is recovered" is a bit confusing, I think they are
talking about the original command line macro definitions, not
the original MAKEFLAGS value itself.)

All Make implementations I've tried indeed accumulate flags in
MAKEFLAGS... expect GNU Make.  My impression is that GNU Make
will not modify MAKEFLAGS if it already exists.  (Except maybe
for the -w option?)

Here is a short test case:


MSG = 'Fails'

all:
@echo 'all:   MAKEFLAGS=$(MAKEFLAGS)'
MSG='Works.' $(MAKE) -e jump

jump:
@echo 'jump:  MAKEFLAGS=$(MAKEFLAGS)'
$(MAKE) print

print:
@echo 'print: MAKEFLAGS=$(MAKEFLAGS)'
echo $(MSG)

.PHONY: all jump print


Because `all' runs `$(MAKE) -e' I'd expect $(MAKEFLAGS) to
contains `e' at the time `jump' and `print' are executed.  So
`print' ought to display the MSG value from the environment, not
from the Makefile.

Compare GNU make to BSD make:

% make-3.80
all:   MAKEFLAGS=
MSG='Works.' make-3.80 -e jump
make-3.80[1]: Entering directory `/home/adl/tmp'
jump:  MAKEFLAGS=
make-3.80 print
make-3.80[2]: Entering directory `/home/adl/tmp'
print: MAKEFLAGS=w
echo 'Fails'
Fails
make-3.80[2]: Leaving directory `/home/adl/tmp'
make-3.80[1]: Leaving directory `/home/adl/tmp'
% pmake
all:   MAKEFLAGS=
MSG='Works.' pmake -e jump
jump:  MAKEFLAGS= -e
pmake print
print: MAKEFLAGS= -e
echo Works.
Works.

Solaris Make and Tru64 Make both show results similar to BSD
make.
--
Alexandre Duret-Lutz

Date: Tue, 14 Jan 2003 16:46:55 -0500
To: Alexandre Duret-Lutz <duret_g@lrde.epita.fr>
Cc: -email is unavailable-
Subject: Re: MAKEFLAGS not updated when it already exists?
From: "Paul D. Smith" <psmith@gnu.org>

I would agree that GNU make's behavior here is not according to the
standard... it looks like you're right: the flags that are in MAKEFLAGS
as a consequence of the initial invocation of make take precedence and
no extra flags that are added to a "sub-make" will be added to
MAKEFLAGS.

I tested back as far as GNU make 3.75 and this has always been the case.

I'll look into it.  Please submit a bug against GNU make in Savannah on
this, thanks!

  https://savannah.gnu.org/projects/make/

--
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

Alexandre Duret-Lutz <adl>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-05-13 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.0
    2009-10-03 psmith Triage StatusNone Verified

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code