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


bug #2216: MAKEFLAGS not updated when it already exists

Submitted by:  Alexandre Duret-Lutz <adl>
Submitted on:  Tue Jan 14 22:17:47 2003  
Severity: 3 - NormalItem Group: Bug
Status: FixedPrivacy: Public
Assigned to: Paul D. Smith <psmith>Open/Closed: Closed
Component Version: 3.80Operating System: Any
Fixed Release: 4.0Triage Status: Verified

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


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

Fix pushed.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Mon May 13 06:01:12 2013, 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>
Project AdministratorIn charge of this item.
Sat Oct 3 20:09:16 2009, comment #1:

Added a test for this to the regression suite.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Tue Jan 14 22:17:47 2003, original submission:

From: Alexandre Duret-Lutz <duret_g@lrde.epita.fr>
Subject: MAKEFLAGS not updated when it already exists?
To: -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'

MSG='Works.' $(MAKE) -e jump

@echo 'jump: MAKEFLAGS=$(MAKEFLAGS)'
$(MAKE) 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
MSG='Works.' make-3.80 -e jump
make-3.80[1]: Entering directory `/home/adl/tmp'
make-3.80 print
make-3.80[2]: Entering directory `/home/adl/tmp'
print: MAKEFLAGS=w
echo 'Fails'
make-3.80[2]: Leaving directory `/home/adl/tmp'
make-3.80[1]: Leaving directory `/home/adl/tmp'
% pmake
MSG='Works.' pmake -e jump
jump: MAKEFLAGS= -e
pmake print
print: MAKEFLAGS= -e
echo Works.

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

Date: Tue, 14 Jan 2003 16:46:55 -0500
To: Alexandre Duret-Lutz <duret_g@lrde.epita.fr>
Cc: -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

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!


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 File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon May 13 06:49:07 2013psmithStatusNone=>Fixed
      Assigned toNone=>psmith
      Fixed ReleaseNone=>4.0
    Sat Oct 3 20:09:16 2009psmithTriage StatusNone=>Verified

    Back to the top

    Powered by Savane 3.1-cleanup