Re: MAKECMDGOALS

[Kaz Kylheku (gmake)]

On 2021-02-01 06:17, Paul Smith wrote:
> 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.

But the warning says "undefined", not "empty".

Is the warning actually about empty variables? If so, its wording is
misleading, as is the name of the option which controls it.

> 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

But that's more of a thing we use for user-overridable variables
that we want to set to default values like

      CFLAGS ?= -O2

Not for ensuring that a documented built-in actually exists.

> which will set MAKECMDGOALS IFF it has never been set at all (not even
> to the empty string).

Maybe MAKECMDGOALS *should* be set to the empty string by make?

However, that kind of change will break Makefiles.

Unknown numbers of existing Makefiles in the wild are using
$(origin MAKECMDGOALS), and relying on that to produce the word
"undefined" when no goals have been given.

GNU Make has broken things for users before, such as suddenly turning
off the lexicographic sorting behavior in $(wildcard ...).

The impact of that kind of change, though not eliminated, could be
softened if Make had some way of emulating old behaviors. For instance,
NU Bash has the following environment variable:

       BASH_COMPAT
              The value is  used  to  set  the  shell's  compatibility
              level.   See  the description of the shopt builtin below
              under SHELL BUILTIN COMMANDS for a  description  of  the
              various  compatibility  levels  and  their effects.  The
              value may be a decimal number (e.g., 4.2) or an  integer
              (e.g.,  42)  corresponding  to the desired compatibility
              level.  If BASH_COMPAT is unset  or  set  to  the  empty
              string,  the  compatibility  level is set to the default
              for the current version.  If BASH_COMPAT  is  set  to  a
              value that is not one of the valid compatibility levels,
              the shell prints an error message and sets the  compati‐
              bility  level  to  the  default for the current version.
              The valid compatibility levels correspond to the compat‐
              ibility  options accepted by the shopt builtin described
              below (for example, compat42 means that 4.2 and  42  are
              valid  values).   The  current  version  is also a valid
              value.

The shopt documentation describes all the meaningful version values
and their specific effect:

              compat41
                      If  set, bash, when in posix mode, treats a sin‐
                      gle quote in a double-quoted parameter expansion
                      as  a special character.  The single quotes must
                      match  (an  even  number)  and  the   characters
                      between the single quotes are considered quoted.
                      This is the behavior of posix mode through  ver‐
                      sion  4.1.  The default bash behavior remains as
                      in previous versions.