Re: MAKEFLAGS=-r

[Dmitry Goncharov]

On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible <bruno@clisp.org> 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