Re: [bug #26596] MAKEFLAGS documentation tweak

[Stefano Lattarini]

On 05/23/2013 10:28 PM, Paul Smith wrote:
> On Wed, 2013-05-22 at 22:09 +0200, Stefano Lattarini wrote:
>> On 05/22/2013 06:56 PM, Paul Smith wrote:
>>> 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.
> 
> Unfortunately I think that as currently implemented in Git, MFLAGS is
> not as good as MAKEFLAGS for testing flags inside a makefile.  See
> below.
> 
>>> 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.
> 
> Correct.
> 
>>>     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.
> 
> This is where I think you'll run into problems with MFLAGS.  See below.
>
Actually, not me (Automake copes with that change just fine), but your
explanation below shows that other users might indeed run into problems.

>>>      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.
> 
> You did... for MFLAGS, I said:
> 
>>> 1. Rules 1-3,5,6 above hold, except that if there are
>>>    single-letter/no argument options they will always be preceded
>>>    by a "-".
> 
> Note the exception.  So, if there are single-letter/no argument options
> they will always start with "-"
>
Sorry, I somehow managed to miss the meaning of that.  Thanks for the
additional explanation!

>> is now superseded by this one (IMHO much clearer and more manageable):
>>
>>     $ make -f- <<<'all:; @echo $(MFLAGS)' -Id -k -i
>>     -ki -Ifoo
> 
> Correct.
> 
>> That change don't have any effect on Automake AFAICS, so no objection
>> from me.
> 
> The problem is item #2a as you list it above.  It means that if you run:
> 
>     echo 'all:;@echo "$(MFLAGS")' | make -f- --no-print-directory
> 
> then in previous versions of make you'd get:
> 
>     - --no-print-directory
> 
> while in new versions you'll get:
> 
>     --no-print-directory
> 
> That is, that initial single "-" is no longer present in MFLAGS.  What
> that means is that this statement:
> 
>>> 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 not true when you substitute '$(MFLAGS)' instead of '-$(MAKEFLAGS)',
> because the firstword of MFLAGS might be a long option like
> "--no-print-directory".  With MAKEFLAGS, since it starts with a space if
> there are no single-letter/no argument options, '-$(MAKEFLAGS)' will
> resolve to "- --no-print-directory" and firstword will be "-".
>
As for me, I do not care deeply, since the code in Automake still works
fine with the new MFLAGS/MAKEFLAGS format; but I think the new MFLAGS
behaviour might be seen as a regression by some users.  But I can't say
if that will be just a mild annoyance or a major usability breakage.
I'll leave it to other to comment of this (I haven't formed a strong
opinion on it, nor would I trust such an opinion anyway).

> I made this change to MFLAGS on purpose because, in the future, I'd like
> to be able to remove this weird special handling of "-" targets (that
> would require breaking makefiles which currently use '-$(MAKEFLAGS)' on
> their recursive make invocations, but that usage is illegal already and
> will already break in some situations).
> 
(In fact, what is the point of passing $(MAKEFLAGS) explicitly?  After
all, it's role is to be exported automatically to sub-make invocations...)

> But, if this change to MFLAGS is a big problem we should discuss it.
>
As I said, *for me*, it is not.

>> Is this tested in the GNU make testsuite?  I'd love such a simple, sane
>> behavior not to regress involuntarily.
> 
> It should be, yes, although today it's not.  In fact, all the various
> command line options should have regression tests for their behavior WRT
> MAKEFLAGS and recursion but most don't.
> 
Pity.

>>> 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.
> 
> --trace takes an optional argument, so "--trace" is a valid flag by
> itself with no "=".
>
OK, but it seems to be that GNU make normalizes it in $(MAKEFLAGS) to
always have an argument (even the default one) appended to it.  But
maybe that is some of an implementation detail, and it's better not
to rely on it explicitly?

>>> 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.
> 
> Ah!  That's good news indeed.  I wonder if you can comment on the above
> change (to remove "-" from MFLAGS in those situations) and whether you
> think it will cause problems or not.
> 
My opinions have been stated above.  But if I were you, I wouldn't give
them too much weight; after all, my interactions with make are quite
unusual, being mostly limited to the features Automake needs *and* can
use ...

Thanks,
  Stefano