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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
