[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #26596] MAKEFLAGS documentation tweak
Re: [bug #26596] MAKEFLAGS documentation tweak
Thu, 23 May 2013 16:28:33 -0400
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
> > 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.)
This is where I think you'll run into problems with MFLAGS. See below.
> > 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 "-"
> 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.
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:
while in new versions you'll get:
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 "-".
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).
But, if this change to MFLAGS is a big problem we should discuss it.
> 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 "=".
> > 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.