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