Re: [bug #26596] MAKEFLAGS documentation tweak

[Stefano Lattarini]

On 05/22/2013 06:56 PM, Paul Smith wrote:
> On Wed, 2013-05-22 at 17:42 +0200, Stefano Lattarini wrote:
>> Hi Paul.
>>
>> On 05/22/2013 05:17 PM, Paul D. Smith wrote:
>>> Follow-up Comment #1, bug #26596 (project make):
>>>
>>> Hm.  I'm not sure why the immediate expansion has limited content.  Is there
>>> any purpose to this?  Wouldn't it just be better to have the immediate
>>> expansion resolve to the entire thing?  I'll have to look into it; maybe
>>> there's a good reason for doing it this way.
>>>
>> FWIW, the current behavior of $(MFLAGS) and $(MAKEFLAGS) is used as a
>> feature in Automake-NG (my Automake fork that assumes the generated
>> makefiles will only be run by GNU make); see the comments about the
>> 'am.make.is-running-with-option' macro in
>> <http://git.sv.gnu.org/cgit/automake.git/tree/lib/am/header-vars.mk?h=ng/master>
>> Changing it will probably break something there :-(
> 
> Perhaps... I'm not sure.
> 
>> But maybe, are you willing to implement new macro(s) that makes is
>> easier to probe at runtime, from within the makefiles, the flags
>> passed to GNU make?  In that case, I'd be more than willing to adjust
>> Automake and/or Automake-NG to take advantage of that.
> 
> I've reworked the MFLAGS / MAKEFLAGS generation to be more regular and
> rigorous yesterday, for 4.0, and to preserve _some_ backward-compat; I
> had thought about this issue when I did so.  Please comment on the
> rules:
>
I'll rework your wording to reference mostly MFLAGS, since that is what
both mainline Automake and Automake-NG currently use.

> For MFLAGS:
>      1. In all cases where an option has both single-letter and long
>         formats, the single-letter format will be used regardless of
>         what appeared on the command line.  Single-letter/no argument
>         options they will always be preceded by a "-".
>
This is good.

>      2. If there are no options or variable assignments for MAKEFLAGS,
>         it will resolve to the empty string.
>
And I assume that variable assignments will still *not* be placed in
$(MFLAGS), right?  Automake has so far been relying on that utterly.

>     2a. If there are no single-letter / no argument options, the whole
>         section is not present (i.e., no leading single dash, no leading
>         space, etc.)
OK.

>      3. Any single-letter / no argument options will always be in the
>         first word; there will be no "-" prefix to this word
>
Even for MFLAGS?  That would be a bad, backward-incompatible change.
But I see this is not the case luckily:

  $ make -f- -Ifoo -k -i  <<<'all:; @echo "$$MFLAGS"'
  -ik -Ifoo

so I must have misunderstand you.

>      5. Next, any options that have single-letter variations but take
>         arguments (optional or not) will appear, as " -X[arg]" (these
>         can never be combined).
>
Indeed, the current behaviour of GNU make 3.82:

    $ make -f- <<<'all:; @echo $(MFLAGS)' -Ifoo -k -i
   -kI foo -i

is now superseded by this one (IMHO much clearer and more manageable):

    $ make -f- <<<'all:; @echo $(MFLAGS)' -Id -k -i
    -ki -Ifoo

That change don't have any effect on Automake AFAICS, so no objection
from me.

>      6. Next any options that have only long names, with or without
>         arguments, will appear, as " --OPTION[=arg]".
> 
> For some reason, --eval options are not added to MFLAGS.  That might be
> a bug.
> 
> As a result, it should be completely reliable to use something like this
> to test for single-character, no argument options:
> 
>   $(if $(findstring k,$(firstword -$(MAKEFLAGS))),found k,no k)
>
Is this tested in the GNU make testsuite?  I'd love such a simple, sane
behavior not to regress involuntarily.

> Similarly you can test for single-character, argument options like this:
> 
>   $(if $(filter -I%,$(MAKEFLAGS)),found -I, no -I)
>
Ditto.

> And long options like this:
> 
>   $(if $(filter --trace%,$(MAKEFLAGS)),found --trace,no --trace)
>
Aren't you missing a '=' after '--trace' here.  Other than that, this
seems good as well.

> I understand that from a backward-compatibility standpoint relying on
> this behavior is problematic.
> 
The important thing for me is that the new behavior doesn't break the
existing idioms employed by Automake.  I've run the Automake testsuite
with the latest GNU make from git (both for mainline Automake and for
Automake-NG), and found no regression, so I can declare myself happy
for the moment.

Thanks,
  Stefano