> Please be sure to post the output of make --version
> so we know what version of GNU Make you are using.

Sorry I forgot. I am using GNU Make 4.4.1, which I built from sources myself:

GNU Make 4.4.1
Built for x86_64-pc-linux-gnu

> Also please show a minimally reproducible example

If I somehow manage to do it, I will post it here.

> I looked at the Makefile in the directory on GitHub you pointed to and
> there is no reference to GNUMAKEFLAGS or the "help" target there
> [...]

Yes, that is what I said: The makefile does not reference GNUMAKEFLAGS at all. That is why I was surprised to see that warning. I wrote the makefile myself and I have never used variable GNUMAKEFLAGS as far as I can remember.

I am guessing that GNU Make 4.4.1 must internally query variable GNUMAKEFLAGS as a side effect when the makefile tries to use some other rule or variable. But I do not know enough to debug the exact position.

How about you try the command I posted with that makefile with GNU Make 4.3 and 4.4.1 ? You should see the warning only with 4.4.1. The makefile is actually relatively straightforward and does not check the GNU Make version itself. That is, it behaves exactly the same, no matter what GNU Make version you are using.

Regards,
  rdiez

I don't thing this bug is fixed yet.

I am using the following makefile:

https://github.com/rdiez/DebugDue/tree/master/Toolchain

This is the command I am running:

$ make --no-builtin-variables --warn-undefined-variables help >/dev/null
make: warning: undefined variable 'GNUMAKEFLAGS'

The makefile does not reference GNUMAKEFLAGS at all.

With GNU Make 4.3 there is no such spurious warning.

I think it depends a little bit on what you think the goal of the option is.  I think that the goal should be to warn when users make use of non-standard variables that are not defined.  That is, it's there to catch various typos etc.

If that's the correct definition then it seems that any variable mentioned as any sort of default or official variable in the GNU make manual, should never be reported as undefined.

The problem is that to make that true the simplest way possible, we'd need to simply define all these variables as o_default which would then change the results of running $(origin XXX) for that variable XXX.

I don't know if that matters, or not.

I perhaps was over-eager to chalk up my observation as being the same underlying issue.  I still think there is a regression, but I certainly misreported it.  Try this:

/tmp$ make -f- <<<$'MAKEFLAGS += --warn-undefined-variables \n $(info MAKE_VERSION: ${MAKE_VERSION}  MAKECMDGOALS: ${MAKECMDGOALS})'
/tmp/GmuYbgmA:2: warning: undefined variable 'MAKECMDGOALS'
MAKE_VERSION: 4.4  MAKECMDGOALS:
make: *** No targets.  Stop.

/tmp$ make4.3 -f- <<<$'MAKEFLAGS += --warn-undefined-variables \n $(info MAKE_VERSION: ${MAKE_VERSION}  MAKECMDGOALS: ${MAKECMDGOALS})'
MAKE_VERSION: 4.3  MAKECMDGOALS:
make: *** No targets.  Stop.

Exactly how this difference comes to pass is beyond my ken, but there it is... in 4.3 the variable is empty whereas in 4.4 it is undefined.

There certainly is an easy workaround, but for some few cases, it is a significant difference.  Alas, mine was one of them.

FWIW: The exact same issue is present for the variable MAKECMDGOALS.  I have reported it as #63452

Hi.

GNU make 4.4 always attemps to expand GNUMAKEFLAGS.  This causes warning "make: warning: undefined variable 'GNUMAKEFLAGS'" to be emitted unless the variable exists.

Reproducing this is very easy (unless there is a Makefile to go there will be an error afterwards but that is unrelated).  One shall also ensure that there is no corresponding GNUMAKEFLAGS environment variable present.

$ (unset GNUMAKEFLAGS; make --no-builtin-variables --warn-undefined-variables)
make: warning: undefined variable 'GNUMAKEFLAGS'
[...]

Typically GNUMAKEFLAGS is always set via define_default_variables() at default.c:744.  However, if --no-builtin-variables is given then default_variables is not iterated.  Also, GNUMAKEFLAGS is no longer automatically added to the environment (commit 3ec497f8) during the first decode phase at main.c:1575.

When switches are decoded again GNUMAKEFLAGS is expanded using decode_env_switches() at main.c:2074.  However, this not guarded by lookup_variable().  So when the constructed variable '$(GNUMAKEFLAGS)' is expanded variable_expand_string() complains (and rightfully so) about the missing variable.

A workaround is to always provide (an empty) GNUMAKEFLAGS environment variable.