Re: MAKEFLAGS=-r

On Wed, 2023-07-19 at 16:35 -0400, Jeffrey Walton wrote: > SUFFIXES does not seem to work too well. 'make -d' still shows all > the extra noise. For example, I added to the top of my GNUmakefile: > >    .SUFFIXES: .h .c .cpp .S .o It works fine; you just didn't do what I said :). I wrote: >

Re: MAKEFLAGS=-r

On Wed, Jul 19, 2023 at 4:36 PM Jeffrey Walton wrote: > SUFFIXES does not seem to work too well. 'make -d' still shows all the > extra noise. For example, I added to the top of my GNUmakefile: > >.SUFFIXES: .h .c .cpp .S .o > > I still see: > > $ make -d -f GNUmakefile ... > Trying implicit

Re: MAKEFLAGS=-r

On Mon, Jul 17, 2023 at 11:47 AM Paul Smith wrote: > > On Mon, 2023-07-17 at 11:45 +0200, Bruno Haible wrote: > > Dmitry Goncharov wrote: > > > Once the makefile author knows the makefile does not need built-in > > > rules, they should add MAKEFLAGS=-r in the m

Re: MAKEFLAGS=-r

Dmitry Goncharov wrote: > On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible wrote: > > And finally, MAKEFLAGS is not even mentioned in the main index of the GNU > > Make > > documentation [5], and only regarding "recursion" in the Variables index > > [6]. > > 5.7.3 contains

Re: MAKEFLAGS=-r

Dmitry Goncharov wrote: > > If a Makefile uses MAKEFLAGS=-r and > > the Makefile in a subdirectory needs built-in rules, will the MAKEFLAGS=-r > > setting propagate to the subdirectory? > > It will. Ouch. This is usually undesired, since a developer works on one Makef

Re: MAKEFLAGS=-r

On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible wrote: > And finally, MAKEFLAGS is not even mentioned in the main index of the GNU Make > documentation [5], and only regarding "recursion" in the Variables index [6]. 5.7.3 contains "The MAKEFLAGS variable can also be useful if you want to have

Re: MAKEFLAGS=-r

On Mon, Jul 17, 2023 at 10:47 AM David Boyce wrote: > > Everything else aside, there's a profound difference between MAKEFLAGS=-r and > MAKEFLAGS+=-r. The latter is far less destabilizing. In a relatively fresh make (make-4.0 or later) setting MAKEFLAGS=-r in the makefile takes effect

Re: MAKEFLAGS=-r

t; and this in Oracle's documentation [4]: > > "Do not define MAKEFLAGS in your makefiles." i only mean this for gnu make. If you need your makefiles to be suitable to other makes, then you'll need to check what other makes do. > Also, what the example did not tell me: If a Ma

Re: MAKEFLAGS=-r

David Boyce wrote: > You say GNUMAKEFLAGS+=-r is "invalid syntax" but I don't know quite how to > read that. It's not invalid in the sense of causing an error, it's just > that it would be invisible to any non-GNU make program Indeed, sorry. You're right. I confused it with the := assignment

Re: MAKEFLAGS=-r

On Mon, 2023-07-17 at 11:45 +0200, Bruno Haible wrote: > Dmitry Goncharov wrote: > > Once the makefile author knows the makefile does not need built-in > > rules, they should add MAKEFLAGS=-r in the makefile and > > this will do a good service to all their users. I'm n

Re: MAKEFLAGS=-r

erything else aside, there's a profound difference between MAKEFLAGS=-r > > and MAKEFLAGS+=-r. The latter is far less destabilizing. > > At least the '-n' option does not get lost by MAKEFLAGS=-r. That is, > setting MAKEFLAGS=-r and running 'make -n' does not cause the actions > t

Re: MAKEFLAGS=-r

David Boyce wrote: > Everything else aside, there's a profound difference between MAKEFLAGS=-r > and MAKEFLAGS+=-r. The latter is far less destabilizing. At least the '-n' option does not get lost by MAKEFLAGS=-r. That is, setting MAKEFLAGS=-r and running 'make -n' does not cause the a

Re: MAKEFLAGS=-r

Everything else aside, there's a profound difference between MAKEFLAGS=-r and MAKEFLAGS+=-r. The latter is far less destabilizing. And yes, GNUMAKEFLAGS is definitely better for this use. On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible wrote: > Dmitry Goncharov wrote: > > Once the makefi

Re: MAKEFLAGS=-r

Dmitry Goncharov wrote: > Once the makefile author knows the makefile does not need built-in > rules, they should add MAKEFLAGS=-r in the makefile and > this will do a good service to all their users. The premise "does not need built-in rules" is likely true for most Makefil

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

Update of bug #58556 (project make): Component Version:None => 4.2.1 ___ Reply to this item at: ___

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

Follow-up Comment #7, bug #58556 (project make): Duh that should be: "If .SUFFIXES does not contain ".o", then the rule is a target rule not an inference rule." ___ Reply to this item at:

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

Follow-up Comment #6, bug #58556 (project make): I agree this is not right. Here is what happens: First, the command line is parsed which creates a goal target named ".o". Second, because "-r" was not given, the default rules are created. One of the default rules is the suffix rule for ".o",

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

Follow-up Comment #5, bug #58556 (project make): Sorry, copied the wrong line. In my last comment, "| make - foo.o" should be "| make -f - foo.o". ___ Reply to this item at:

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

Follow-up Comment #4, bug #58556 (project make): It is not ineffective! Did you try it? touch foo.c printf MAKEFLAGS=r | make - foo.o make: *** No rule to make target 'foo.o'. Stop. make foo.o cc-c -o foo.o foo.c The builtin rule is suppressed by MAKEFLAGS, as expected. This doesn't work

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

Follow-up Comment #3, bug #58556 (project make): printf 'MAKEFLAGS=r \n .SUFFIXES:' | make - .o is completely ineffective and printf 'MAKEFLAGS=r \n .SUFFIXES:' | make -f - .o is ineffective because MAKEFLAGS=r is read after the internal makefile was read. BTW: it s bad practice to set

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

ng exactly ".o" and nothing else, not an *implicit* rule, which seems like a bug. - True that the internal rules are read before the makefile, but MAKEFLAGS=r should be able to disable their use. It does disable them properly for a file named "foo.o", it only gets conf

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

Follow-up Comment #1, bug #58556 (project make): Any make implementation reads the internal make definitions before reading any normal makefile. Your observed behavior is expected behavior. ___ Reply to this item at:

[bug #58556] Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this

URL: <https://savannah.gnu.org/bugs/?58556> Summary: Make is confused by a target named ".o" and neither emptying .SUFFIXES nor MAKEFLAGS=r can prevent this Project: make Submitted by: log65536 Submitted on: Sun 14 Jun

[bug #45949] MAKEFLAGS += -r has no effect for current Makefile

URL: <http://savannah.gnu.org/bugs/?45949> Summary: MAKEFLAGS += -r has no effect for current Makefile Project: make Submitted by: None Submitted on: Sun 13 Sep 2015 07:45:04 AM UTC Severity: 3 - Normal

[bug #45949] MAKEFLAGS += -r has no effect for current Makefile

Follow-up Comment #1, bug #45949 (project make): Sorry, wrong make version. Was 3.81 and 3.82. Apparently, this has been fixed in 4.0 and 4.1. Please ignore. ___ Reply to this item at: