Re: MAKEFLAGS=-r

[Paul Smith]

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:

>   .SUFFIXES:

which is very different than what you actually added.

You can read about how it works in the GNU Make manual:

https://www.gnu.org/software/make/manual/html_node/Suffix-Rules.html

Note in particular the last 3 paragraphs.

Re: MAKEFLAGS=-r

[Dmitry Goncharov]

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 prerequisite 'GNUmakefile.o'.

If you want to reset the list of known suffixes
.SUFFIXES:
You can then add your own suffixes to this list
.SUFFIXES: .h .c .cpp .S .o

If you want to prevent make from remaking GNUmakefile
GNUmakefile::;

regards, Dmitry

Re: MAKEFLAGS=-r

[Jeffrey Walton]

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 makefile and
> > > this will do a good service to all their users.
>
> I'm not sure I've followed the entire discussion yet, but FYI I do not
> usually recommend this method of clearing the default rules.  There are
> issues with modifying MAKEFLAGS, especially with some older versions of
> GNU Make.  And also, in some older versions setting MAKEFLAGS in the
> makefile doesn't actually take effect anyway: it only helps for sub-
> makes.
>
> My recommendation has been to disable the built-in rules directly, if
> you don't need them.  For example you can use:
>
>   .SUFFIXES:
>
> to disable most of the built in rules (this is a POSIX standard
> facility so it's helpful even for other versions of make).
>
> Unfortunately that doesn't fix all problems because GNU Make also has a
> few built-in rules that are defined using pattern rules (because suffix
> rules are not powerful enough).  So a full list of "turn it all off"
> would be this:
>
>   .SUFFIXES:
>   %:: %,v
>   %:: RCS/%,v
>   %:: RCS/%
>   %:: s.%
>   %:: SCCS/s.%

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
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'GNUmakefile'...
Updating makefiles
 Considering target file 'GNUmakefile'.
  Looking for an implicit rule for 'GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.o'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.c'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.cc'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.C'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.cpp'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.p'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.f'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.F'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.m'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.r'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.s'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.S'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.mod'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.sh'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile,v'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'RCS/GNUmakefile,v'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'RCS/GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 's.GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'SCCS/s.GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.o'.
  Looking for a rule with intermediate file 'GNUmakefile.o'.
   Avoiding implicit rule recursion.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.cpp'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.c'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.cc'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.C'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.p'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.f'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.F'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.m'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefi

Re: MAKEFLAGS=-r

[Bruno Haible]

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
https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html
> 
> "The MAKEFLAGS variable can also be useful if you want to have certain
> options, such as ‘-k’ (see Summary of Options), set each time you run
> make. You simply put a value for MAKEFLAGS in your environment. You
> can also set MAKEFLAGS in a makefile, to specify additional flags that
> should also be in effect for that makefile. "

This kind of documentation structure has room for improvement.

If MAKEFLAGS has one purpose, the communication with sub-make invocations,
it's got to be documented in a section "Communicating Options to a Sub-make".

If MAKEFLAGS has two different purposes, semantically that far away, there
should be two documentation sections, "Communicating Options to a Sub-make"
and "Activating make options by default".

Bruno

Re: MAKEFLAGS=-r

[Bruno Haible]

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 Makefile
at a time.

Together with the other arguments by Paul [1], this means the .SUFFIXES
approach is much much preferable.

Bruno

[1] https://lists.gnu.org/archive/html/bug-make/2023-07/msg00063.html

Re: MAKEFLAGS=-r

[Dmitry Goncharov]

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 certain
options, such as ‘-k’ (see Summary of Options), set each time you run
make. You simply put a value for MAKEFLAGS in your environment. You
can also set MAKEFLAGS in a makefile, to specify additional flags that
should also be in effect for that makefile. "

regards, Dmitry

Re: MAKEFLAGS=-r

[Dmitry Goncharov]

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 and other options specified on the command
line also take effect.

regards, Dmitry

Re: MAKEFLAGS=-r

[Dmitry Goncharov]

On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible  wrote:
> So I wondered whether I should add this variable definition in the Makefile.am
files of my GNU packages.

i think, that would be good.

>   "you should be sure not to include any options that will drastically
>affect the actions of make"

We should ensure that the makefile does not need built-in rules.

>   "It’s best to use GNUMAKEFLAGS only with flags which won’t materially
>change the behavior of your makefiles."

i don't see a reason for gnumakeflags to be suitable for some options,
but not others.
If you set gnumakeflags to some value, that value will be passed to
submake in makeflags, anyway.

> and this on stackoverflow [3]:

>   "You shouldn't set MAKEFLAGS at all. ...
>MAKEFLAGS is intended, really, to be an internal implementation passing
>arguments from a parent make to a child make. It's not intended,
>generally, to be modified by a makefile."

i sort of agree, that was the original purpose.
Then people wanted to be able to have makefile set options.
And someone decided to use makeflags for this as well.
And implemented it.

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

You can reset .suffixes instead if you don't want to propagate -r to submake.
Alternatively, you can do something like

oldmflags := $(filter-out -%,$(MAKEFLAGS))
MAKEFLAGS += -r
mflags = MAKEFLAGS="$(oldmflags) $(filter -%,$(MAKEFLAGS)) $(MAKEOVERRIDES)"
all:; $(mflags) $(MAKE) -C lib

regards, Dmitry

Re: MAKEFLAGS=-r

[Bruno Haible]

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

Bruno

Re: MAKEFLAGS=-r

[Paul Smith]

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 not sure I've followed the entire discussion yet, but FYI I do not
usually recommend this method of clearing the default rules.  There are
issues with modifying MAKEFLAGS, especially with some older versions of
GNU Make.  And also, in some older versions setting MAKEFLAGS in the
makefile doesn't actually take effect anyway: it only helps for sub-
makes.

My recommendation has been to disable the built-in rules directly, if
you don't need them.  For example you can use:

  .SUFFIXES:

to disable most of the built in rules (this is a POSIX standard
facility so it's helpful even for other versions of make).

Unfortunately that doesn't fix all problems because GNU Make also has a
few built-in rules that are defined using pattern rules (because suffix
rules are not powerful enough).  So a full list of "turn it all off"
would be this:

  .SUFFIXES:
  %:: %,v
  %:: RCS/%,v
  %:: RCS/%
  %:: s.%
  %:: SCCS/s.%

Hopefully these are just considered funnily-named targets and won't
hurt anything, when used in non-GNU Make versions of make.

I admit this is annoying since it's possible that the catalog of built-
in rules could change in the future.

Re: MAKEFLAGS=-r

[David Boyce]

I know nothing about autotools, so I should probably stop talking, but not
quite yet.

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 so presumably that's
what you mean. But the thing is, I don't believe other make programs are
reactive to MAKEFLAGS being set within the makefile. At least, it's been a
long time since I read POSIX but I don't think it's required. My assumption
may be wrong but if not, setting MAKEFLAGS would be a NOP in non-GNU makes
anyway. Except that it would take effect in recursive invocations but that
complicates things further.

Anyway, I really should stop talking since I know zero about automake.

David

On Mon, Jul 17, 2023 at 11:22 AM Bruno Haible  wrote:

> 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 actions
> to be actually executed.
>
> > And yes, GNUMAKEFLAGS is definitely better for this use.
>
> But MAKEFLAGS+=-r or GNUMAKEFLAGS+=-r is not something one can use in a
> Makefile.am, since this is invalid syntax for a POSIX make program.
> Thus, for those who want to get rid of implicit rules because Automake
> provides the rules already, it's either MAKEFLAGS=-r or nothing at all.
>
> Bruno
>
>
>
>

Re: MAKEFLAGS=-r

[Bruno Haible]

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 actions
to be actually executed.

> And yes, GNUMAKEFLAGS is definitely better for this use.

But MAKEFLAGS+=-r or GNUMAKEFLAGS+=-r is not something one can use in a
Makefile.am, since this is invalid syntax for a POSIX make program.
Thus, for those who want to get rid of implicit rules because Automake
provides the rules already, it's either MAKEFLAGS=-r or nothing at all.

Bruno

Re: MAKEFLAGS=-r

[David Boyce]

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 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
> Makefiles
> generated by GNU Automake, because
>   - GNU Automake generates its own rules already,
>   - Whenever rules are executed that don't obey the variables listed in
> [1],
> such as CPPFLAGS, it is a bug that the package's user should rightfully
> report.
>
> So I wondered whether I should add this variable definition in the
> Makefile.am
> files of my GNU packages. But then I read this in the documentation [2]:
>
>   "you should be sure not to include any options that will drastically
>affect the actions of make"
>
> and
>
>   "It’s best to use GNUMAKEFLAGS only with flags which won’t materially
>change the behavior of your makefiles."
>
> and this on stackoverflow [3]:
>
>   "You shouldn't set MAKEFLAGS at all. ...
>MAKEFLAGS is intended, really, to be an internal implementation passing
>arguments from a parent make to a child make. It's not intended,
>generally, to be modified by a makefile."
>
> and this in Oracle's documentation [4]:
>
>   "Do not define MAKEFLAGS in your makefiles."
>
> 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].
>
> > The manual should lead by example.
>
> Yes, I agree. But if the example contradicts all the advice given in the
> rest
> of the manual and elsewhere, I will certainly not use it in my Makefiles.
>
> Also, what the example did not tell me: 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? In other words, is it a good idea
> to use MAKEFLAGS=-r in Makefiles that recurse to other Makefiles (and that
> are maintained independently)?
>
> Bruno
>
> [1]
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Preset-Output-Variables.html
> [2]
> https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html
> [3] https://stackoverflow.com/questions/19611004/
> [4] https://docs.oracle.com/cd/E19504-01/802-5880/make-65/index.html
> [5]
> https://www.gnu.org/software/make/manual/html_node/Concept-Index.html#Concept-Index_cp_letter-M
> [6]
> https://www.gnu.org/software/make/manual/html_node/Name-Index.html#Name-Index_fn_letter-M
>
>
>
>
>

Re: MAKEFLAGS=-r

[Bruno Haible]

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 Makefiles
generated by GNU Automake, because
  - GNU Automake generates its own rules already,
  - Whenever rules are executed that don't obey the variables listed in [1],
such as CPPFLAGS, it is a bug that the package's user should rightfully
report.

So I wondered whether I should add this variable definition in the Makefile.am
files of my GNU packages. But then I read this in the documentation [2]:

  "you should be sure not to include any options that will drastically
   affect the actions of make"

and

  "It’s best to use GNUMAKEFLAGS only with flags which won’t materially
   change the behavior of your makefiles."

and this on stackoverflow [3]:

  "You shouldn't set MAKEFLAGS at all. ...
   MAKEFLAGS is intended, really, to be an internal implementation passing
   arguments from a parent make to a child make. It's not intended,
   generally, to be modified by a makefile."

and this in Oracle's documentation [4]:

  "Do not define MAKEFLAGS in your makefiles."

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

> The manual should lead by example.

Yes, I agree. But if the example contradicts all the advice given in the rest
of the manual and elsewhere, I will certainly not use it in my Makefiles.

Also, what the example did not tell me: 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? In other words, is it a good idea
to use MAKEFLAGS=-r in Makefiles that recurse to other Makefiles (and that
are maintained independently)?

Bruno

[1] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Preset-Output-Variables.html
[2] 
https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html
[3] https://stackoverflow.com/questions/19611004/
[4] https://docs.oracle.com/cd/E19504-01/802-5880/make-65/index.html
[5] 
https://www.gnu.org/software/make/manual/html_node/Concept-Index.html#Concept-Index_cp_letter-M
[6] 
https://www.gnu.org/software/make/manual/html_node/Name-Index.html#Name-Index_fn_letter-M

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

[Paul D. Smith]

Update of bug #58556 (project make):

   Component Version:None => 4.2.1  


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Paul D. Smith]

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", which sees the already-existing
".o" goal target and applies the recipe to it.  Then finally we try to build. 
Since the ".o" is an actual target now, the code that handles -r as part of
MAKEFLAGS has no effect on it.  This is clearly not right.  It's a little
tricky though because GNU make keeps all the different types of targets in the
same big bucket of targets indexed by name.  So, it's not really possible to
have both a target ".o" which is a goal target and a target ".o" which is a
suffix rule target, but have them be two different things.

I suspect the only way to make it work as the user expects, is to delay the
conversion of the command line goals into internal targets until after all
makefiles are read in and parsed.

POSIX's requirements here are a little tricky.  If you have a rule with the
target ".o" and the ".o" appears as a member of .SUFFIXES, then that rule is
an inference rule not a target rule.  If .SUFFIXES does not contain ".o", then
the rule is an inference rule not a target rule.  So, you don't really know
until the entire makefile has been parsed and you know the final value of
.SUFFIXES, which it is.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Rossen Mikhov]

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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Rossen Mikhov]

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 ONLY when the target is named exactly ".o".

But as I said, the point here is not whether MAKEFLAGS=r is effective in
principle or not; it is effective whenever it should be and that works fine.
If you insist, you can ignore the part of this report that refers to MAKEFLAGS
at all, and the bug is still there.

Especially the following point:

> - There are no prerequisites in the empty directory, so an implicit rule
with prerequisites should not be invoked at all, whether the rule is builtin
or is actually defined in the main makefile. Neither "make foo" nor "make
foo.o" tries to invoke "cc" in any way, only "make .o" does. 

Matching an implicit rule when its prerequisites are non-existing is in direct
contradiction to the manual section 10.8 "Implicit Rule Search Algorithm". So
there seems to be an internal rule with *no prerequisites* for a file named
".o" (which I identified as an explicit, not implicit rule, from the "make -d"
output). This is the essence of what I am reporting. Everything else is
diagnostics, things I tried in order to investigate the circumstances where
this manifests in order to be helpful to the people looking into this. Thank
you for bearing with me.


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58556>

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Jörg Schilling]

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 MAKEFLAGS= as this is an internal variable that
is intended for make to communicate with it's sub-make calls.

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58556>

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Rossen Mikhov]

Follow-up Comment #2, bug #58556 (project make):

Reading internal definitions before reading the makefile is fine, but this bug
report specifically makes the following points:

- There are no prerequisites in the empty directory, so an implicit rule with
prerequisites should not be invoked at all, whether the rule is builtin or is
actually defined in the main makefile. Neither "make foo" nor "make foo.o"
tries to invoke "cc" in any way, only "make .o" does.

- "make -dp" behaves as if this is an *explicit* internal rule, specifically
matching 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 confused by a file named ".o".

- In any case, if there are internal rules that are impossible to disable and
are going to be used anyway, they should be printed by "make -p", which they
are not.

Is all of this still expected?


___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58556>

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Jörg Schilling]

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:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[Rossen Mikhov]

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 2020 01:39:34 AM JST
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

In an empty directory:

$ make .o
cc  -o .o
cc: fatal error: no input files
compilation terminated.
make: *** [: .o] Error 1

This was unexpected, because no prerequisites exist in the directory.
Looking into the relevant parts from "make -dp .o":

Considering target file '.o'.
 File '.o' does not exist.
 Finished prerequisites of target file '.o'.
Must remake target '.o'.
...
.o:
$(LINK.o) $^ $(LOADLIBS) -o $@

It doesn't mention trying implicit rules, so it seems to be matching the
builtin as an explicit rule. Is this intentional?

Even if this is by design, there should be a way to turn it off from the
makefile. I tried:

$ printf 'MAKEFLAGS=r \n .SUFFIXES:' | make - .o
cc  -o .o
cc: fatal error: no input files
compilation terminated.
make: *** [: .o] Error 1

This is strange, because now "make -p" doesn't mention any rules involving
".o" at all, yet it still manages to call the linker.

I should note that "make -r" from the command line does work properly, and
"MAKEFLAGS=r" does disable the bulitins for targets not named like a default
suffix.

I also note that I found this while trying to fix a buggy makefile. Being able
to actually work with a target named ".o" is not important here, it is just
that a more correct error message might have helped while debugging the
makefile.





___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58556>

___
  Message sent via Savannah
  https://savannah.gnu.org/

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

[anonymous]

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
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.1
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

The 5.7.3 section of the documentation states that:

_The MAKEFLAGS variable can also be useful if you want to have certain
options, such as ‘-k’ (see Summary of Options), set each time you run
make. You simply put a value for MAKEFLAGS in your environment. You can also
set MAKEFLAGS in a makefile, to specify additional flags that should also be
in effect for that makefile._

This does not seams to be true, at least for the -r flag. Example makefile:


MAKEFLAGS += -r
foo.c:
touch $@


Apparently, _MAKEFLAGS += -r_ does not force make to ignore all implicit rules
for the current makefile:


$ rm foo.* ; make foo.o
touch foo.c
cc-c -o foo.o foo.c


While:


$ rm foo.* ; make -r foo.o
make: *** No rule to make target `foo.o'.  Stop.






___

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45949>

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

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

[anonymous]

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:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make