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.
|
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.
|
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
|
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.
|
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.
|
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.
|
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
|
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.
|
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.
|