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

 
 

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

Submitter:  Matt McCutchen <hashproduct>
Submitted:  Tue 17 Jul 2007 03:58:25 AM UTC
Votes: 85
 
Severity:  3 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  None Operating System:  Any
Fixed Release:  4.0 Triage Status:  Verified
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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

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>
Group administrator
  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.
#
.SUFFIXES:

ifeq ($(filter -r,$(MAKEFLAGS)),)
MAKEFLAGS += -r
endif

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

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

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

http://lists.gnu.org/archive/html/bug-make/2008-01/msg00020.html
http://lists.gnu.org/archive/html/bug-make/2008-01/msg00021.html

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.

http://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html#Options_002fRecursion

    cheers,
      DaveK

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:

-----
MAKEFLAGS += -rR

all:
-----

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
.web.p:
.l.r:
.F.o:
.y.ln:
.def.sym:
.p.o:
.txinfo.dvi:
.l.ln:
.w.c:
.texi.dvi:
.cc.o:
.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
.c.o:
.r.o:
.l.c:
.r.f:
.texinfo.info:
.w.tex:
.c.ln:
.s.o:
.texinfo.dvi:
.y.c:
.web.tex:
.texi.info:
.tex.dvi:
.cpp.o:
.C.o:
.txinfo.info:
.S.s:
.mod.o:
.F.f:
.S.o:
.f.o:
$ 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 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)
  • -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)
  •  

    There are 85 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 8 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
    2011-12-20 psmith Triage StatusNone Verified
    2011-12-20 psmith Operating SystemPOSIX-Based Any
    2009-11-28 hashproduct Carbon-Copy- Added hashproduct
    2008-01-23 brownhamer Carbon-Copy- Added brownhamer

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code