Re: MAKECMDGOALS

[David Boyce]

It would make more sense to me for --warn-undefined-variables to simply
ignore builtin variables. Surely the point of the option is to find out
about mistakes the makefile writer may have made so whether the
implementation sets $(MAKECMDGOALS) or $(MAKEFILES) or $(GNUMAKEFLAGS) is
not of interest. If the user sets it it will be set, of course, and if not
it's whatever the documentation says it should be.

David

On Mon, Feb 1, 2021 at 6:34 AM Sébastien Hinderer <
Sebastien.Hinderer@inria.fr> wrote:

> Dear Paul,
>
> Many thanks for your response.
>
> I was not trying to debate :)
>
> It seems I used "defined" where youu use "set" but that's what I meant.
> Shouldn't make set this variable to theempty string rather than not
> setting it at all?
>
> Cheers,
>
> Sébastien.
>
>
>
>
> Paul Smith (2021/02/01 09:17 -0500):
> > On Mon, 2021-02-01 at 11:49 +0100, Sébastien Hinderer wrote:
> > >    'Make' will set the special variable 'MAKECMDGOALS' to the list of
> > >    goals you specified on the command line.  If no goals were given on
> > >    the command line, this variable is empty.
> > >
> > > If I define the following Makefile:
> > >
> > > ifeq "$(MAKECMDGOALS)" ""
> > >
> > > make --warn-undefined-variables
> > >
> > > Makefile:1: warning: undefined variable 'MAKECMDGOALS'
> > >
> > > Am I correct that there is a mismatch between make's documented and
> > > real behaviour?
> >
> > Hm.  Well, I could use a language lawyer's response and say that "this
> > variable is empty" is not the same thing as "this variable is set to
> > the empty value".
> >
> > The variable _IS_ empty, in the same way that any unset variable is
> > empty.
> >
> > If you want to tell the difference between a variable that is not set
> > at all versus set to the empty string, you have to use the
> > $(origin ...) function.
> >
> > Instead of your code you could use:
> >
> >     MAKECMDGOALS ?= default
> >
> > which will set MAKECMDGOALS IFF it has never been set at all (not even
> > to the empty string).
> >
> > Probably this section of the documentation should be updated to be more
> > clear so that reading it doesn't require language lawyering.
> >
>
>