bugmake - Bugs: bug #20501, "MAKEFLAGS += -rR"...


bug #20501: "MAKEFLAGS += -rR" doesn't turn off default suffix rules, variables

Submitted by:  Matt McCutchen <hashproduct>
Submitted on:  Tue 17 Jul 2007 03:58:25 AM UTC  
Votes:  85  
Severity: 3 - NormalItem Group: Bug
Status: FixedPrivacy: Public
Assigned to: Paul D. Smith <psmith>Open/Closed: Closed
Component Version: NoneOperating System: Any
Fixed Release: 4.0Triage Status: Verified

Add a New Comment(Rich Markup)

You are not logged in

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


(Jump to the original submission Jump to the original submission)

Tue 20 Dec 2011 11:40:37 PM UTC, comment #8:

It's not completely true that -p shows "the rules as if they were there". Recall that there are two types of implicit rules in GNU make: suffix rules and pattern rules.

If you use MAKEFLAGS+=-r then the pattern rules will not be present in the -p output.

However, MAKEFLAGS+=-r is not the same as "make -r" because the latter ALSO prevents suffix rules from being defined, while the former does not. The former only applies to pattern rules.

That's why in the makefile you need BOTH the .SUFFIXES: special target AND the MAKEFLAGS+=-r. Having the .SUFFIXES: special target set to empty ensures that no suffix rules are searched but it does NOT remove all the suffix rules from the database. So they still show up with -p, but they don't have any impact on the algorithms make uses to build targets.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
 Spam posted by sevanath
Thu 24 Jan 2008 12:23:58 PM UTC, comment #7:

Does it matter that the built-in variables get set before reading makefiles? I hope not.
I think the people involved in this project are clever enough to unset a 'default' variable if the make flag -R is encountered.

I mean, the 'origin' function in makefiles can determine just that, if its value is default or not, so there must be some functionality in the sources to determine so. I guess there's also some sort of functionality to loop through all the defined variables.

Combine the two and what do you get?
Exactly what it should do... well, at least what I suggested :)

The documentation should then be updated to state that -r should come before any rule, and -R before any inbuilt variable gets a conditional assignment (the ?= assignment).

As for -r working properly, that's great, but then -p should be fixed.

p.s. The 'ifeq ($(filter -r,$(MAKEFLAGS)),)' isn't really needed, -r won't get added twice.

Hendrik de Goede <brownhamer>
Thu 24 Jan 2008 07:12:57 AM UTC, comment #6:

Actually adding -r to MAKEFLAGS does work. It just that -p still prints the rules as if they were there. I use the following makefile fragment in our build system to get rid of all built-in (suffix and pattern) rules:

# Remove all built-in rules.

ifeq ($(filter -r,$(MAKEFLAGS)),)

There was a thread on one of the GNU make mailing lists about this interesting behavior some time ago.

As for adding -R, I think it is quite obvious why it does not work: make sets built-in variables before it starts reading makefiles.


Boris Kolpackov <bosk>
Project Member
Thu 24 Jan 2008 04:41:35 AM UTC, comment #5:

Note the following comments emailed to the bug-make list:


Philip, you are right that there is no clean, general way to implement setting -r and -R via the MAKEFLAGS variable. Still, if I have a makefile that breaks if the suffix rules/variables are present, it would be nice to have a better solution than either making the users remember to pass -rR or putting magic in the makefile to reexecute make with those options. And certainly the behavior should be documented.

Matt McCutchen <hashproduct>
Wed 23 Jan 2008 11:51:36 AM UTC, comment #4:

I'm sorry, I missed that! I think you're right; it is a bug.

Dave Korn <davek>
Wed 23 Jan 2008 11:33:39 AM UTC, comment #3:

I think it is a bug.

To quote the make 3.81 documentation 'You can also set MAKEFLAGS in a makefile, to specify additional flags that should also be in effect for that makefile', in the same chapter you specified.

p.s. Indeed, I meant the recursive submake invocation.

Hendrik de Goede <brownhamer>
Wed 23 Jan 2008 11:07:13 AM UTC, comment #2:

As far as I can see this is not a bug, this is make performing exactly as described in the manual. MAKEFLAGS is not a live way of controlling a running make's behaviour, it is used solely for the purpose of passing down to a recursive invocation of make; that is why you find they work when you run a "subsequent call from the makefile", by which I think you mean a recursive submake invocation.

Please review the make documentation, "5.7.3 Communicating Options to a Sub-`make'", and verify whether you really have a bug here or not.



Dave Korn <davek>
Wed 23 Jan 2008 10:58:41 AM UTC, comment #1:

I'm using GNU make 3.81 through cygwin on Windows XP.

The -rR flags are not the only ones not working as expected (expected by me at least), the option -S doesn't work as well.
However, when running a subsequent call from the Makefile, they all work just fine.
The flags '--no-print-directory', '-s' and '--warn-undefined-variables' function properly immediately.

The main problem I'm having with this is that we use various .mk files which can be included from the Makefile. I want to set defaults for the programs, flags and such (like CC ?= gcc) in those .mk files. But this 'bug' prevents me from doing so, as CC already gets a default value.

Hendrik de Goede <brownhamer>
Tue 17 Jul 2007 03:58:25 AM UTC, original submission:

I'm using GNU make 3.81 on Fedora Core 7 Linux.

I put "MAKEFLAGS += -rR" at the top of my makefile and expected this to disable all default rules and variables. However, "make -p" shows that the default suffix rules and variables are still present.

My makefile, "makeflags.mk" is the following:



This illustrates that the options in the makefile do not turn off suffix rules:

$ make -f makeflags.mk -p | grep '^\..\..'
.LIBPATTERNS = lib%.so lib%.a
.SUFFIXES: .out .a .ln .o .c .cc .C .cpp .p .f .F .r .y .l .s .S .mod .sym .def .h .info .dvi .tex .texinfo .texi .txinfo .w .ch .web .sh .elc .el
$ make -f makeflags.mk -p -rR | grep '^\..\..'
(No output)

This happens because default suffix rules and variables are loaded too soon to be governed by the second call to decode_env_switches that picks up the MAKEFLAGS set by the makefile.

Matt McCutchen <hashproduct>


(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
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by sevanath (Posted a comment)
  • -email is unavailable- added by hashproduct (Voted in favor of this item)
  • -email is unavailable- added by bosk (Posted a comment)
  • -email is unavailable- added by davek (Posted a comment)
  • -email is unavailable- added by brownhamer (Posted a comment)
  • -email is unavailable- added by brownhamer (Voted in favor of this item)
  • -email is unavailable- added by hashproduct (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 85 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 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 13 May 2013 08:31:55 AM UTCpsmithStatusNone=>Fixed
      Assigned toNone=>psmith
      Fixed ReleaseNone=>4.0
    Tue 20 Dec 2011 11:41:05 PM UTCpsmithTriage StatusNone=>Verified
    Tue 20 Dec 2011 11:40:49 PM UTCpsmithOperating SystemPOSIX-Based=>Any
    Sat 28 Nov 2009 03:49:43 AM UTChashproductCarbon-Copy-=>Added hashproduct
    Wed 23 Jan 2008 09:18:02 AM UTCbrownhamerCarbon-Copy-=>Added brownhamer

    Back to the top

    Powered by Savane 3.1-cleanup1