[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #26596] MAKEFLAGS documentation tweak

From: Stefano Lattarini
Subject: Re: [bug #26596] MAKEFLAGS documentation tweak
Date: Fri, 24 May 2013 00:04:17 +0200

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.

>>> 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 ...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]