{"thread":{"id":"58862","subject":"[PATCH 1/1] Avoid multiple patterns when recipes generate one file","startedAt":"2022-11-27T22:43:46Z","lastAt":"2022-12-06T09:13:48Z","messageCount":23,"participants":["Paul Smith","Ævar Arnfjörð Bjarmason","Junio C Hamano","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"468051","messageId":"20221127224251.2508200-2-psmith@gnu.org","threadId":"58862","inReplyTo":"20221127224251.2508200-1-psmith@gnu.org","subject":"[PATCH 1/1] Avoid multiple patterns when recipes generate one file","fromName":"Paul Smith","fromEmail":"psmith@gnu.org","sentAt":"2022-11-27T22:42:51Z","receivedAt":"2022-11-27T22:43:46Z","isPatch":true,"sender":{"key":"psmith@gnu.org","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"A GNU make pattern rule with multiple targets has always meant that\na single invocation of the recipe will build all the targets.\nHowever in older versions of GNU make a recipe that did not really\nbuild all the targets would be tolerated.\n\nStarting with GNU make 4.4 this behavior is deprecated and pattern\nrules are expected to generate files to match all the patterns.\nIf not all targets are created then GNU make will not consider any\ntarget up to date and will re-run the recipe when it is run again.\n\nModify Documentation/Makefile to split the man page-creating pattern\nrule into a separate pattern rule for each pattern.\n\nReported-by: Alexander Kanavin \nSigned-off-by: Paul Smith \n---\n Documentation/Makefile | 12 ++++++++++--\n 1 file changed, 10 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex d47acb2e25..21375cd3f2 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -351,8 +351,16 @@ $(OBSOLETE_HTML): %.html : %.txto $(ASCIIDOC_DEPS)\n manpage-base-url.xsl: manpage-base-url.xsl.in\n \t$(QUIET_GEN)sed \"s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|\" $< > $@\n \n-%.1 %.5 %.7 : %.xml manpage-base-url.xsl $(wildcard manpage*.xsl)\n-\t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n+\n+manpage-prereqs := manpage-base-url.xsl $(wildcard manpage*.xsl)\n+manpage-cmd = $(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n+\n+%.1 : %.xml $(manpage-prereqs)\n+\t$(manpage-cmd)\n+%.5 : %.xml $(manpage-prereqs)\n+\t$(manpage-cmd)\n+%.7 : %.xml $(manpage-prereqs)\n+\t$(manpage-cmd)\n \n %.xml : %.txt $(ASCIIDOC_DEPS)\n \t$(QUIET_ASCIIDOC)$(TXT_TO_XML) -d manpage -o $@ $<\n-- \n2.35.3\n\n"},{"id":"468052","messageId":"20221127224251.2508200-1-psmith@gnu.org","threadId":"58862","inReplyTo":null,"subject":"[PATCH 0/1] Avoid multiple patterns when recipes generate one file","fromName":"Paul Smith","fromEmail":"psmith@gnu.org","sentAt":"2022-11-27T22:42:50Z","receivedAt":"2022-11-27T22:43:47Z","isPatch":true,"sender":{"key":"psmith@gnu.org","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"Needed for GNU make 4.4 or above. This is backward-compatible with\nall previous versions of GNU make.\n\nI'm not sure if this should be considered a bug fix; I based it on\nmaint just in case.\n\nPaul Smith (1):\n Avoid multiple patterns when recipes generate one file\n\n Documentation/Makefile | 12 ++++++++++--\n 1 file changed, 10 insertions(+), 2 deletions(-)\n\n\nbase-commit: e7e5c6f715b2de7bea0d39c7d2ba887335b40aa0\n-- \n2.35.3\n\n"},{"id":"468088","messageId":"221128.86mt8bkyqt.gmgdl@evledraar.gmail.com","threadId":"58862","inReplyTo":"20221127224251.2508200-2-psmith@gnu.org","subject":"Re: [PATCH 1/1] Avoid multiple patterns when recipes generate one file","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-28T13:08:35Z","receivedAt":"2022-11-28T13:16:11Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Nov 27 2022, Paul Smith wrote:\n\n> A GNU make pattern rule with multiple targets has always meant that\n> a single invocation of the recipe will build all the targets.\n> However in older versions of GNU make a recipe that did not really\n> build all the targets would be tolerated.\n>\n> Starting with GNU make 4.4 this behavior is deprecated and pattern\n> rules are expected to generate files to match all the patterns.\n> If not all targets are created then GNU make will not consider any\n> target up to date and will re-run the recipe when it is run again.\n>\n> Modify Documentation/Makefile to split the man page-creating pattern\n> rule into a separate pattern rule for each pattern.\n>\n> Reported-by: Alexander Kanavin \n> Signed-off-by: Paul Smith \n> ---\n\nThanks for fixing downstream, and for working on GNU make.\n\n> Documentation/Makefile | 12 ++++++++++--\n> 1 file changed, 10 insertions(+), 2 deletions(-)\n>\n> diff --git a/Documentation/Makefile b/Documentation/Makefile\n> index d47acb2e25..21375cd3f2 100644\n> --- a/Documentation/Makefile\n> +++ b/Documentation/Makefile\n> @@ -351,8 +351,16 @@ $(OBSOLETE_HTML): %.html : %.txto $(ASCIIDOC_DEPS)\n> manpage-base-url.xsl: manpage-base-url.xsl.in\n> \t$(QUIET_GEN)sed \"s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|\" $< > $@\n> \n> -%.1 %.5 %.7 : %.xml manpage-base-url.xsl $(wildcard manpage*.xsl)\n> -\t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n> +\n> +manpage-prereqs := manpage-base-url.xsl $(wildcard manpage*.xsl)\n> +manpage-cmd = $(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n> +\n> +%.1 : %.xml $(manpage-prereqs)\n> +\t$(manpage-cmd)\n> +%.5 : %.xml $(manpage-prereqs)\n> +\t$(manpage-cmd)\n> +%.7 : %.xml $(manpage-prereqs)\n> +\t$(manpage-cmd)\n> \n> %.xml : %.txt $(ASCIIDOC_DEPS)\n> \t$(QUIET_ASCIIDOC)$(TXT_TO_XML) -d manpage -o $@ $<\n\nWhether we use eval/define or not (I just tried to avoid the repetition)\nI think referring to $(DOC_MAN[157]) here probably makes more sense if\nwe're poking at these rules.\n\nI.e. in this case the rest of the Makefile is carrying forward what\nmanpages we're generating exactly, so rather than a wildcard %.1 to\n%.xml we can narrow it down to just the %.1 files we're going to b\ngenerating (but maybe that's best left for later...):\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex 5e1a7f655c2..7404cead084 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -351,8 +351,12 @@ $(OBSOLETE_HTML): %.html : %.txto $(ASCIIDOC_DEPS)\n manpage-base-url.xsl: manpage-base-url.xsl.in\n \t$(QUIET_GEN)sed \"s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|\" $< > $@\n \n-%.1 %.5 %.7 : %.xml manpage-base-url.xsl $(wildcard manpage*.xsl)\n-\t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n+define doc-man-tmpl\n+$$(DOC_MAN$(1)): %.$(1) : %.xml manpage-base-url.xsl $$(wildcard manpage*.xsl)\n+\t$$(QUIET_XMLTO)$$(XMLTO) -m $$(MANPAGE_XSL) $$(XMLTO_EXTRA) man $$<\n+\n+endef\n+$(eval $(foreach n,1 5 7,$(call doc-man-tmpl,$(n))))\n \n %.xml : %.txt $(ASCIIDOC_DEPS)\n \t$(QUIET_ASCIIDOC)$(TXT_TO_XML) -d manpage -o $@ $<\n"},{"id":"468119","messageId":"43914959458ef34a0f29271afa9c9d981c2b3553.camel@gnu.org","threadId":"58862","inReplyTo":"221128.86mt8bkyqt.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH 1/1] Avoid multiple patterns when recipes generate one file","fromName":"Paul Smith","fromEmail":"psmith@gnu.org","sentAt":"2022-11-28T18:33:57Z","receivedAt":"2022-11-28T18:35:33Z","isPatch":true,"sender":{"key":"psmith@gnu.org","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Mon, 2022-11-28 at 14:08 +0100, Ævar Arnfjörð Bjarmason wrote:\n> Whether we use eval/define or not (I just tried to avoid the\n> repetition) I think referring to $(DOC_MAN[157]) here probably makes\n> more sense if we're poking at these rules.\n> \n> I.e. in this case the rest of the Makefile is carrying forward what\n> manpages we're generating exactly, so rather than a wildcard %.1 to\n> %.xml we can narrow it down to just the %.1 files we're going to b\n> generating (but maybe that's best left for later...):\n\nI have no opinion on which is better :).\n\nI'm not sure what the above comment is asking for though: are you going\nto take over pushing this change? Or do you want me to reroll the\ncommit with these changes instead? Or are we waiting for more\nopinions?\n\n> diff --git a/Documentation/Makefile b/Documentation/Makefile\n> index 5e1a7f655c2..7404cead084 100644\n> --- a/Documentation/Makefile\n> +++ b/Documentation/Makefile\n> @@ -351,8 +351,12 @@ $(OBSOLETE_HTML): %.html : %.txto $(ASCIIDOC_DEPS)\n>  manpage-base-url.xsl: manpage-base-url.xsl.in\n>         $(QUIET_GEN)sed \"s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|\" $< > $@\n>  \n> -%.1 %.5 %.7 : %.xml manpage-base-url.xsl $(wildcard manpage*.xsl)\n> -       $(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n> +define doc-man-tmpl\n> +$$(DOC_MAN$(1)): %.$(1) : %.xml manpage-base-url.xsl $$(wildcard manpage*.xsl)\n> +       $$(QUIET_XMLTO)$$(XMLTO) -m $$(MANPAGE_XSL) $$(XMLTO_EXTRA) man $$<\n> +\n> +endef\n> +$(eval $(foreach n,1 5 7,$(call doc-man-tmpl,$(n))))\n>  \n>  %.xml : %.txt $(ASCIIDOC_DEPS)\n>         $(QUIET_ASCIIDOC)$(TXT_TO_XML) -d manpage -o $@ $<\n\n"},{"id":"468123","messageId":"221128.86k03ekis2.gmgdl@evledraar.gmail.com","threadId":"58862","inReplyTo":"43914959458ef34a0f29271afa9c9d981c2b3553.camel@gnu.org","subject":"Re: [PATCH 1/1] Avoid multiple patterns when recipes generate one file","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-28T18:57:56Z","receivedAt":"2022-11-28T18:58:58Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Nov 28 2022, Paul Smith wrote:\n\n> On Mon, 2022-11-28 at 14:08 +0100, Ævar Arnfjörð Bjarmason wrote:\n>> Whether we use eval/define or not (I just tried to avoid the\n>> repetition) I think referring to $(DOC_MAN[157]) here probably makes\n>> more sense if we're poking at these rules.\n>> \n>> I.e. in this case the rest of the Makefile is carrying forward what\n>> manpages we're generating exactly, so rather than a wildcard %.1 to\n>> %.xml we can narrow it down to just the %.1 files we're going to b\n>> generating (but maybe that's best left for later...):\n>\n> I have no opinion on which is better :).\n>\n> I'm not sure what the above comment is asking for though: are you going\n> to take over pushing this change? Or do you want me to reroll the\n> commit with these changes instead? Or are we waiting for more\n> opinions?\n\nJust a suggestion in case you thought it helped, but I think we can just\ngo for your version.\n"},{"id":"468187","messageId":"patch-v2-3.4-6db7dd74e52-20221129T140159Z-avarab@gmail.com","threadId":"58862","inReplyTo":"cover-v2-0.4-00000000000-20221129T140159Z-avarab@gmail.com","subject":"[PATCH v2 3/4] Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-29T14:09:16Z","receivedAt":"2022-11-29T14:09:29Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Since GNU make 4.4 the semantics of the $(MAKEFLAGS) variable has\nchanged in a backward-incompatible way, as its \"NEWS\" file notes:\n\n Previously only simple (one-letter) options were added to the MAKEFLAGS\n variable that was visible while parsing makefiles. Now, all options are\n available in MAKEFLAGS. If you want to check MAKEFLAGS for a one-letter\n option, expanding \"$(firstword -$(MAKEFLAGS))\" is a reliable way to return\n the set of one-letter options which can be examined via findstring, etc.\n\nThis upstream change meant that e.g.:\n\n\tmake man\n\nWould become very noisy, because in shared.mak we rely on extracting\n\"s\" from the $(MAKEFLAGS), which now contains long options like\n\"--jobserver-auth=fifo:\", which we'll conflate with the \"-s\"\noption.\n\nSo, let's change this idiom we've been carrying since [1], [2] and [3]\nas the \"NEWS\" suggests.\n\nNote that the \"-\" in \"-$(MAKEFLAGS)\" is critical here, as the variable\nwill always contain leading whitespace if there are no short options,\nbut long options are present. Without it e.g. \"make --debug=all\" would\nyield \"--debug=all\" as the first word, but with it we'll get \"-\" as\nintended. Then \"-s\" for \"-s\", \"-Bs\" for \"-s -B\" etc.\n\n1. 0c3b4aac8ec (git-gui: Support of \"make -s\" in: do not output\n anything of the build itself, 2007-03-07)\n2. b777434383b (Support of \"make -s\": do not output anything of the\n build itself, 2007-03-07)\n3. bb2300976ba (Documentation/Makefile: make most operations \"quiet\",\n 2009-03-27)\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n git-gui/Makefile | 2 +-\n shared.mak | 4 ++--\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/git-gui/Makefile b/git-gui/Makefile\nindex 56c85a85c1e..a0d5a4b28e1 100644\n--- a/git-gui/Makefile\n+++ b/git-gui/Makefile\n@@ -116,7 +116,7 @@ ifeq ($(uname_S),Darwin)\n \tTKEXECUTABLE = $(shell basename \"$(TKFRAMEWORK)\" .app)\n endif\n \n-ifeq ($(findstring $(MAKEFLAGS),s),s)\n+ifeq ($(findstring $(firstword -$(MAKEFLAGS)),s),s)\n QUIET_GEN =\n endif\n \ndiff --git a/shared.mak b/shared.mak\nindex be1f30ff206..aeb80fc4d5a 100644\n--- a/shared.mak\n+++ b/shared.mak\n@@ -37,13 +37,13 @@ space := $(empty) $(empty)\n QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir\n QUIET_SUBDIR1 =\n \n-ifneq ($(findstring w,$(MAKEFLAGS)),w)\n+ifneq ($(findstring w,$(firstword -$(MAKEFLAGS))),w)\n PRINT_DIR = --no-print-directory\n else # \"make -w\"\n NO_SUBDIR = :\n endif\n \n-ifneq ($(findstring s,$(MAKEFLAGS)),s)\n+ifneq ($(findstring s,$(firstword -$(MAKEFLAGS))),s)\n ifndef V\n ## common\n \tQUIET_SUBDIR0 = +@subdir=\n-- \n2.39.0.rc0.993.g0c499e58e3b\n\n"},{"id":"468188","messageId":"patch-v2-1.4-42b4f241c97-20221129T140159Z-avarab@gmail.com","threadId":"58862","inReplyTo":"cover-v2-0.4-00000000000-20221129T140159Z-avarab@gmail.com","subject":"[PATCH v2 1/4] Documentation/Makefile: de-duplicate *.[157] dependency list","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-29T14:09:14Z","receivedAt":"2022-11-29T14:09:32Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Use the \"DOC_MAN[157]\" variables combined into a new \"DOC_MANN\" to\ndeclare that e.g. \"git-am.1\" depends on \"manpage-base-url.xsl\"\netc. This change helps to make a subsequent change smaller.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n Documentation/Makefile | 7 ++++++-\n 1 file changed, 6 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex 5e1a7f655c2..d239f6751f0 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -129,9 +129,13 @@ ARTICLES_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))\n HTML_FILTER ?= $(ARTICLES_HTML) $(OBSOLETE_HTML)\n DOC_HTML = $(MAN_HTML) $(filter $(HTML_FILTER),$(ARTICLES_HTML) $(OBSOLETE_HTML))\n \n+DOC_MANN =\n DOC_MAN1 = $(patsubst %.txt,%.1,$(filter $(MAN_FILTER),$(MAN1_TXT)))\n+DOC_MANN += $(DOC_MAN1)\n DOC_MAN5 = $(patsubst %.txt,%.5,$(filter $(MAN_FILTER),$(MAN5_TXT)))\n+DOC_MANN += $(DOC_MAN5)\n DOC_MAN7 = $(patsubst %.txt,%.7,$(filter $(MAN_FILTER),$(MAN7_TXT)))\n+DOC_MANN += $(DOC_MAN7)\n \n prefix ?= $(HOME)\n bindir ?= $(prefix)/bin\n@@ -351,7 +355,8 @@ $(OBSOLETE_HTML): %.html : %.txto $(ASCIIDOC_DEPS)\n manpage-base-url.xsl: manpage-base-url.xsl.in\n \t$(QUIET_GEN)sed \"s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|\" $< > $@\n \n-%.1 %.5 %.7 : %.xml manpage-base-url.xsl $(wildcard manpage*.xsl)\n+$(DOC_MANN): manpage-base-url.xsl $(wildcard manpage*.xsl)\n+%.1 %.5 %.7 : %.xml\n \t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n \n %.xml : %.txt $(ASCIIDOC_DEPS)\n-- \n2.39.0.rc0.993.g0c499e58e3b\n\n"},{"id":"468189","messageId":"cover-v2-0.4-00000000000-20221129T140159Z-avarab@gmail.com","threadId":"58862","inReplyTo":"20221127224251.2508200-1-psmith@gnu.org","subject":"[PATCH v2 0/4] Makefiles: GNU make 4.4 fixes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-29T14:09:13Z","receivedAt":"2022-11-29T14:09:33Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"GNU Make 4.4 was released just about a month ago[1], this series picks\nup & amends a change from Paul Smith (the GNU make maintainer), and\nthen fixes another bug in our Makefiles as a result of a\nbackwards-incompatible change in how $(MAKEFLAGS) works in 4.4.\n\nJunio: I think this is worth considering for merging down in the rc\nperied. We can limp along without these fixes, but not being able to\nbuild the docs to completion (as far as make is concerned) and the new\nwarnings fixed by 2/4 will probably break things for or annoy some\npackagers.\n\nThe 3/4 then fixes the output being always-verbose for our\nsub-Makefiles for the affected targets. 4/4 is pure-refactoring, but I\nthink should help build confidence in the preceding changes.\n\n1. https://lwn.net/Articles/913253/\n\nPaul Smith (1):\n Documentation/Makefile: avoid multiple patterns when generating one\n file\n\nÆvar Arnfjörð Bjarmason (3):\n Documentation/Makefile: de-duplicate *.[157] dependency list\n Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4\n Documentation/Makefile: narrow wildcard rules to our known files\n\n Documentation/Makefile | 15 ++++++++++++---\n git-gui/Makefile | 2 +-\n shared.mak | 4 ++--\n 3 files changed, 15 insertions(+), 6 deletions(-)\n\nRange-diff against v1:\n1: 115d79fe1fc ! 1: 42b4f241c97 Avoid multiple patterns when recipes generate one file\n @@\n ## Metadata ##\n -Author: Paul Smith \n +Author: Ævar Arnfjörð Bjarmason \n \n ## Commit message ##\n - Avoid multiple patterns when recipes generate one file\n + Documentation/Makefile: de-duplicate *.[157] dependency list\n \n - A GNU make pattern rule with multiple targets has always meant that\n - a single invocation of the recipe will build all the targets.\n - However in older versions of GNU make a recipe that did not really\n - build all the targets would be tolerated.\n + Use the \"DOC_MAN[157]\" variables combined into a new \"DOC_MANN\" to\n + declare that e.g. \"git-am.1\" depends on \"manpage-base-url.xsl\"\n + etc. This change helps to make a subsequent change smaller.\n \n - Starting with GNU make 4.4 this behavior is deprecated and pattern\n - rules are expected to generate files to match all the patterns.\n - If not all targets are created then GNU make will not consider any\n - target up to date and will re-run the recipe when it is run again.\n -\n - Modify Documentation/Makefile to split the man page-creating pattern\n - rule into a separate pattern rule for each pattern.\n -\n - Reported-by: Alexander Kanavin \n - Signed-off-by: Paul Smith \n + Signed-off-by: Ævar Arnfjörð Bjarmason \n \n ## Documentation/Makefile ##\n +@@ Documentation/Makefile: ARTICLES_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))\n + HTML_FILTER ?= $(ARTICLES_HTML) $(OBSOLETE_HTML)\n + DOC_HTML = $(MAN_HTML) $(filter $(HTML_FILTER),$(ARTICLES_HTML) $(OBSOLETE_HTML))\n + \n ++DOC_MANN =\n + DOC_MAN1 = $(patsubst %.txt,%.1,$(filter $(MAN_FILTER),$(MAN1_TXT)))\n ++DOC_MANN += $(DOC_MAN1)\n + DOC_MAN5 = $(patsubst %.txt,%.5,$(filter $(MAN_FILTER),$(MAN5_TXT)))\n ++DOC_MANN += $(DOC_MAN5)\n + DOC_MAN7 = $(patsubst %.txt,%.7,$(filter $(MAN_FILTER),$(MAN7_TXT)))\n ++DOC_MANN += $(DOC_MAN7)\n + \n + prefix ?= $(HOME)\n + bindir ?= $(prefix)/bin\n @@ Documentation/Makefile: $(OBSOLETE_HTML): %.html : %.txto $(ASCIIDOC_DEPS)\n manpage-base-url.xsl: manpage-base-url.xsl.in\n \t$(QUIET_GEN)sed \"s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|\" $< > $@\n \n -%.1 %.5 %.7 : %.xml manpage-base-url.xsl $(wildcard manpage*.xsl)\n --\t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n -+\n -+manpage-prereqs := manpage-base-url.xsl $(wildcard manpage*.xsl)\n -+manpage-cmd = $(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n -+\n -+%.1 : %.xml $(manpage-prereqs)\n -+\t$(manpage-cmd)\n -+%.5 : %.xml $(manpage-prereqs)\n -+\t$(manpage-cmd)\n -+%.7 : %.xml $(manpage-prereqs)\n -+\t$(manpage-cmd)\n ++$(DOC_MANN): manpage-base-url.xsl $(wildcard manpage*.xsl)\n ++%.1 %.5 %.7 : %.xml\n + \t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n \n %.xml : %.txt $(ASCIIDOC_DEPS)\n - \t$(QUIET_ASCIIDOC)$(TXT_TO_XML) -d manpage -o $@ $<\n-: ----------- > 2: e232f308e40 Documentation/Makefile: avoid multiple patterns when generating one file\n-: ----------- > 3: 6db7dd74e52 Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4\n-: ----------- > 4: f1bc3c16904 Documentation/Makefile: narrow wildcard rules to our known files\n-- \n2.39.0.rc0.993.g0c499e58e3b\n\n"},{"id":"468190","messageId":"patch-v2-2.4-e232f308e40-20221129T140159Z-avarab@gmail.com","threadId":"58862","inReplyTo":"cover-v2-0.4-00000000000-20221129T140159Z-avarab@gmail.com","subject":"[PATCH v2 2/4] Documentation/Makefile: avoid multiple patterns when generating one file","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-29T14:09:15Z","receivedAt":"2022-11-29T14:09:34Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"From: Paul Smith \n\nA GNU make pattern rule with multiple targets has always meant that\na single invocation of the recipe will build all the targets.\nHowever in older versions of GNU make a recipe that did not really\nbuild all the targets would be tolerated.\n\nStarting with GNU make 4.4 this behavior is deprecated and pattern\nrules are expected to generate files to match all the patterns.\nIf not all targets are created then GNU make will not consider any\ntarget up to date and will re-run the recipe when it is run again.\n\nI.e. a command like:\n\n\tmake -C Documentation git-am.1\n\nWill never be satisfied that \"git-am.1\" has been made, because we\ndidn't also make \"git-am.5\" and \"git-am.7\", as the warning it'll emit\nindicates:\n\n\t$ make -C Documentation git-am.1\n\t[...]\n\t XMLTO git-am.1\n\tMakefile:355: warning: pattern recipe did not update peer target 'git-am.7'.\n\tMakefile:355: warning: pattern recipe did not update peer target 'git-am.5'.\n\nModify Documentation/Makefile to split the man page-creating pattern\nrule into a separate pattern rule for each pattern. This requires a\nsmall amount of copy/pasting, but due to splitting out the \"DOC_MANN\"\nin the preceding commit it's not too bad.\n\nReported-by: Alexander Kanavin \nSigned-off-by: Paul Smith \nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n Documentation/Makefile | 6 +++++-\n 1 file changed, 5 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex d239f6751f0..89929e3d60b 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -356,7 +356,11 @@ manpage-base-url.xsl: manpage-base-url.xsl.in\n \t$(QUIET_GEN)sed \"s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|\" $< > $@\n \n $(DOC_MANN): manpage-base-url.xsl $(wildcard manpage*.xsl)\n-%.1 %.5 %.7 : %.xml\n+%.1 : %.xml\n+\t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n+%.5 : %.xml\n+\t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n+%.7 : %.xml\n \t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n \n %.xml : %.txt $(ASCIIDOC_DEPS)\n-- \n2.39.0.rc0.993.g0c499e58e3b\n\n"},{"id":"468191","messageId":"patch-v2-4.4-f1bc3c16904-20221129T140159Z-avarab@gmail.com","threadId":"58862","inReplyTo":"cover-v2-0.4-00000000000-20221129T140159Z-avarab@gmail.com","subject":"[PATCH v2 4/4] Documentation/Makefile: narrow wildcard rules to our known files","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-29T14:09:17Z","receivedAt":"2022-11-29T14:09:37Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Instead of declaring that we'll generate e.g. any \"%.1\" from a\ncorresponding \"%.xml\" let's narrow that list down to only our known\nmanpage files, and likewise for %.xml.\n\nWe already generated e.g. \"man1\" on the basis of \"$(DOC_MAN1)\", we\njust weren't keeping track of what we were generating exactly in the\nthese middle steps.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n Documentation/Makefile | 16 ++++++++--------\n 1 file changed, 8 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex 89929e3d60b..f84b54ac093 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -356,14 +356,14 @@ manpage-base-url.xsl: manpage-base-url.xsl.in\n \t$(QUIET_GEN)sed \"s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|\" $< > $@\n \n $(DOC_MANN): manpage-base-url.xsl $(wildcard manpage*.xsl)\n-%.1 : %.xml\n-\t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n-%.5 : %.xml\n-\t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n-%.7 : %.xml\n-\t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n-\n-%.xml : %.txt $(ASCIIDOC_DEPS)\n+define doc-mann-rule\n+$$(DOC_MAN$(1)) : %.$(1) : %.xml\n+\t$$(QUIET_XMLTO)$$(XMLTO) -m $$(MANPAGE_XSL) $$(XMLTO_EXTRA) man $$<\n+\n+endef\n+$(eval $(foreach n,1 5 7,$(call doc-mann-rule,$(n))))\n+\n+$(MAN_XML): %.xml : %.txt $(ASCIIDOC_DEPS)\n \t$(QUIET_ASCIIDOC)$(TXT_TO_XML) -d manpage -o $@ $<\n \n user-manual.xml: user-manual.txt user-manual.conf asciidoctor-extensions.rb GIT-ASCIIDOCFLAGS\n-- \n2.39.0.rc0.993.g0c499e58e3b\n\n"},{"id":"468220","messageId":"xmqqr0xl1bbk.fsf@gitster.g","threadId":"58862","inReplyTo":"cover-v2-0.4-00000000000-20221129T140159Z-avarab@gmail.com","subject":"Re: [PATCH v2 0/4] Makefiles: GNU make 4.4 fixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-11-30T01:27:11Z","receivedAt":"2022-11-30T01:27:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> GNU Make 4.4 was released just about a month ago[1], this series picks\n> up & amends a change from Paul Smith (the GNU make maintainer), and\n> then fixes another bug in our Makefiles as a result of a\n> backwards-incompatible change in how $(MAKEFLAGS) works in 4.4.\n>\n> Junio: I think this is worth considering for merging down in the rc\n> peried.\n\n\"in the rc period\" -> \"before -rc1\".\n\nYes I was planning to merge down Paul's topic which was very much\nminimum and obvious. I do not think \"while at it, make it less\n"},{"id":"468225","messageId":"xmqqtu2hyt2s.fsf@gitster.g","threadId":"58862","inReplyTo":"patch-v2-1.4-42b4f241c97-20221129T140159Z-avarab@gmail.com","subject":"Re: [PATCH v2 1/4] Documentation/Makefile: de-duplicate *.[157] dependency list","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-11-30T04:17:15Z","receivedAt":"2022-11-30T04:17:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> -%.1 %.5 %.7 : %.xml manpage-base-url.xsl $(wildcard manpage*.xsl)\n> +$(DOC_MANN): manpage-base-url.xsl $(wildcard manpage*.xsl)\n\nNot a new issue, but to avoid getting affected by an untracked new\nxsl files, shouldn't we expand the wildcard at the source level\nhere? I.e.\n\n $(DOC_MANN): manpage-base-url.xsl \\\n manpage-bold-literal.xsl \\\n manpage-normal.xsl \\\n manpage-quote-apos.xsl \\\n manpage.xsl\n\nor something?\n\n> +%.1 %.5 %.7 : %.xml\n> \t$(QUIET_XMLTO)$(XMLTO) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<\n> \n> %.xml : %.txt $(ASCIIDOC_DEPS)\n"},{"id":"468226","messageId":"xmqqpmd5yt1g.fsf@gitster.g","threadId":"58862","inReplyTo":"patch-v2-2.4-e232f308e40-20221129T140159Z-avarab@gmail.com","subject":"Re: [PATCH v2 2/4] Documentation/Makefile: avoid multiple patterns when generating one file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-11-30T04:18:03Z","receivedAt":"2022-11-30T04:18:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> From: Paul Smith \n>\n> A GNU make pattern rule with multiple targets has always meant that\n> a single invocation of the recipe will build all the targets.\n> However in older versions of GNU make a recipe that did not really\n> build all the targets would be tolerated.\n\nThis was in 'next' and was merged to -rc1 already.\n\nThanks, both.\n"},{"id":"468227","messageId":"xmqqk03dyskc.fsf@gitster.g","threadId":"58862","inReplyTo":"patch-v2-3.4-6db7dd74e52-20221129T140159Z-avarab@gmail.com","subject":"Re: [PATCH v2 3/4] Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-11-30T04:28:19Z","receivedAt":"2022-11-30T04:28:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> Since GNU make 4.4 the semantics of the $(MAKEFLAGS) variable has\n> changed in a backward-incompatible way, as its \"NEWS\" file notes:\n>\n> Previously only simple (one-letter) options were added to the MAKEFLAGS\n> variable that was visible while parsing makefiles. Now, all options are\n> available in MAKEFLAGS. If you want to check MAKEFLAGS for a one-letter\n> option, expanding \"$(firstword -$(MAKEFLAGS))\" is a reliable way to return\n> the set of one-letter options which can be examined via findstring, etc.\n\nWow. That's a bold move for GNU make folks to make.\n\n> This upstream change meant that e.g.:\n>\n> \tmake man\n>\n> Would become very noisy, because in shared.mak we rely on extracting\n> \"s\" from the $(MAKEFLAGS), which now contains long options like\n> \"--jobserver-auth=fifo:\", which we'll conflate with the \"-s\"\n> option.\n\nDo our uses of $(MAKEFLAGS) for the $(PRINT_DIR) and the $(QUIET)\nmacros that do not affect correctness? $(QUIET) thing I suspect\nwill merely be annoyance, but $(PRINT_DIR) might affect correctness\ndepending on how $(MAKE) output is being used.\n\nI have to wonder how many projects they have broken with this change\n;-).\n\nIn any case, this seems like a good thing to do. I am not sure if\nthis is so urgent to add in the -rc period, or can safely wait post\nrelease.\n\nThanks.\n"},{"id":"468228","messageId":"25c59966c83cdae078bdefa49f47ca8d3199475c.camel@gnu.org","threadId":"58862","inReplyTo":"xmqqk03dyskc.fsf@gitster.g","subject":"Re: [PATCH v2 3/4] Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4","fromName":"Paul Smith","fromEmail":"psmith@gnu.org","sentAt":"2022-11-30T05:49:09Z","receivedAt":"2022-11-30T05:50:48Z","isPatch":true,"sender":{"key":"psmith@gnu.org","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Wed, 2022-11-30 at 13:28 +0900, Junio C Hamano wrote:\n> I have to wonder how many projects they have broken with this change\n\nSome, but not that many. Most projects don't try to investigate\nMAKEFLAGS, and of those that do many were already using the recommended\nmethod, because even prior to GNU make 4.4 it was possible for\nMAKEFLAGS to have stray \"s\" characters, in unusual situations (for\nexample if MAKEFLAGS were set in the makefile).\n\nThere were various bugs filed that various options could not be\ninvestigated from within makefiles and also that running make from\nwithin $(shell ...) didn't work right because MAKEFLAGS was not set.\n\nIt was just a mess, trying to keep the value of MAKEFLAGS set to\ndifferent values at different points in the processing of make.\n\nAlso, ensuring this trick for searching MAKEFLAGS continues to work\nwould have meant strictly controlling what new options we could add to\nGNU make. I haven't seen any other project use the filter-out --%\ntrick that the Git makefiles do, but even with that it won't help if a\nnew single-letter option that takes an argument is added.\n"},{"id":"468231","messageId":"cover-v3-0.1-00000000000-20221130T081835Z-avarab@gmail.com","threadId":"58862","inReplyTo":"cover-v2-0.4-00000000000-20221129T140159Z-avarab@gmail.com","subject":"[PATCH v3 0/1] Makefiles: GNU make 4.4 fixes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-30T08:23:48Z","receivedAt":"2022-11-30T08:24:57Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"A now much-smaller re-roll of a potential for-v2.39.0 fix for GNU make\n4.4 compatibility.\n\nJunio: Sorry about the overlapping submission, at the time I didn't\nsee Paul's in the \"What's Cooking\", and thought it hadn't been picked\nup at all (maybe I just forgot to look at the actual branches).\n\nThis v3 is just the \"MAKEFLAGS\" patch. I agree with your [2] that we\nmight want to leave this post-release, i.e. it'll just be (a lot) more\nverbose, but does it break anything? Probably not.\n\nOn the other hand the fix here is trivial, and literally just the\nexact solution to this compatibility problem suggested by GNU make's\n\"NEWS\" file, and nothing else. So merging this before the release\nshould be low-risk...\n\n1. https://lore.kernel.org/git/cover-v2-0.4-00000000000-20221129T140159Z-avarab@gmail.com/\n2. https://lore.kernel.org/git/xmqqk03dyskc.fsf@gitster.g/\n\nÆvar Arnfjörð Bjarmason (1):\n Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4\n\n git-gui/Makefile | 2 +-\n shared.mak | 4 ++--\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\nRange-diff against v2:\n1: 42b4f241c97 < -: ----------- Documentation/Makefile: de-duplicate *.[157] dependency list\n2: e232f308e40 < -: ----------- Documentation/Makefile: avoid multiple patterns when generating one file\n3: 6db7dd74e52 = 1: 432518b2dd7 Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4\n4: f1bc3c16904 < -: ----------- Documentation/Makefile: narrow wildcard rules to our known files\n-- \n2.39.0.rc0.1028.gb88f24da998\n\n"},{"id":"468232","messageId":"patch-v3-1.1-432518b2dd7-20221130T081835Z-avarab@gmail.com","threadId":"58862","inReplyTo":"cover-v3-0.1-00000000000-20221130T081835Z-avarab@gmail.com","subject":"[PATCH v3 1/1] Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-30T08:23:49Z","receivedAt":"2022-11-30T08:26:13Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Since GNU make 4.4 the semantics of the $(MAKEFLAGS) variable has\nchanged in a backward-incompatible way, as its \"NEWS\" file notes:\n\n Previously only simple (one-letter) options were added to the MAKEFLAGS\n variable that was visible while parsing makefiles. Now, all options are\n available in MAKEFLAGS. If you want to check MAKEFLAGS for a one-letter\n option, expanding \"$(firstword -$(MAKEFLAGS))\" is a reliable way to return\n the set of one-letter options which can be examined via findstring, etc.\n\nThis upstream change meant that e.g.:\n\n\tmake man\n\nWould become very noisy, because in shared.mak we rely on extracting\n\"s\" from the $(MAKEFLAGS), which now contains long options like\n\"--jobserver-auth=fifo:\", which we'll conflate with the \"-s\"\noption.\n\nSo, let's change this idiom we've been carrying since [1], [2] and [3]\nas the \"NEWS\" suggests.\n\nNote that the \"-\" in \"-$(MAKEFLAGS)\" is critical here, as the variable\nwill always contain leading whitespace if there are no short options,\nbut long options are present. Without it e.g. \"make --debug=all\" would\nyield \"--debug=all\" as the first word, but with it we'll get \"-\" as\nintended. Then \"-s\" for \"-s\", \"-Bs\" for \"-s -B\" etc.\n\n1. 0c3b4aac8ec (git-gui: Support of \"make -s\" in: do not output\n anything of the build itself, 2007-03-07)\n2. b777434383b (Support of \"make -s\": do not output anything of the\n build itself, 2007-03-07)\n3. bb2300976ba (Documentation/Makefile: make most operations \"quiet\",\n 2009-03-27)\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n git-gui/Makefile | 2 +-\n shared.mak | 4 ++--\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/git-gui/Makefile b/git-gui/Makefile\nindex 56c85a85c1e..a0d5a4b28e1 100644\n--- a/git-gui/Makefile\n+++ b/git-gui/Makefile\n@@ -116,7 +116,7 @@ ifeq ($(uname_S),Darwin)\n \tTKEXECUTABLE = $(shell basename \"$(TKFRAMEWORK)\" .app)\n endif\n \n-ifeq ($(findstring $(MAKEFLAGS),s),s)\n+ifeq ($(findstring $(firstword -$(MAKEFLAGS)),s),s)\n QUIET_GEN =\n endif\n \ndiff --git a/shared.mak b/shared.mak\nindex be1f30ff206..aeb80fc4d5a 100644\n--- a/shared.mak\n+++ b/shared.mak\n@@ -37,13 +37,13 @@ space := $(empty) $(empty)\n QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir\n QUIET_SUBDIR1 =\n \n-ifneq ($(findstring w,$(MAKEFLAGS)),w)\n+ifneq ($(findstring w,$(firstword -$(MAKEFLAGS))),w)\n PRINT_DIR = --no-print-directory\n else # \"make -w\"\n NO_SUBDIR = :\n endif\n \n-ifneq ($(findstring s,$(MAKEFLAGS)),s)\n+ifneq ($(findstring s,$(firstword -$(MAKEFLAGS))),s)\n ifndef V\n ## common\n \tQUIET_SUBDIR0 = +@subdir=\n-- \n2.39.0.rc0.1028.gb88f24da998\n\n"},{"id":"468256","messageId":"006f10e84c9108a7be7315fec753316ca743386c.camel@gnu.org","threadId":"58862","inReplyTo":"patch-v3-1.1-432518b2dd7-20221130T081835Z-avarab@gmail.com","subject":"Re: [PATCH v3 1/1] Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4","fromName":"Paul Smith","fromEmail":"psmith@gnu.org","sentAt":"2022-11-30T16:29:44Z","receivedAt":"2022-11-30T16:29:59Z","isPatch":true,"sender":{"key":"psmith@gnu.org","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Wed, 2022-11-30 at 09:23 +0100, Ævar Arnfjörð Bjarmason wrote:\n> Since GNU make 4.4 the semantics of the $(MAKEFLAGS) variable has\n> changed in a backward-incompatible way, as its \"NEWS\" file notes:\n\nHrm. I did try to look through the other makefiles to find similar\nconstructs and get them all, but apparently my grep fu was\ninsufficient. Bother.\n\nThanks.\n"},{"id":"468290","messageId":"xmqqpmd4ulnj.fsf@gitster.g","threadId":"58862","inReplyTo":"006f10e84c9108a7be7315fec753316ca743386c.camel@gnu.org","subject":"Re: [PATCH v3 1/1] Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-11-30T22:23:28Z","receivedAt":"2022-11-30T22:23:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Smith writes:\n\n> On Wed, 2022-11-30 at 09:23 +0100, Ævar Arnfjörð Bjarmason wrote:\n>> Since GNU make 4.4 the semantics of the $(MAKEFLAGS) variable has\n>> changed in a backward-incompatible way, as its \"NEWS\" file notes:\n>\n> Hrm. I did try to look through the other makefiles to find similar\n> constructs and get them all, but apparently my grep fu was\n> insufficient. Bother.\n>\n> Thanks.\n\nThanks, both. Will queue.\n"},{"id":"468313","messageId":"221201.86v8mvgsrj.gmgdl@evledraar.gmail.com","threadId":"58862","inReplyTo":"25c59966c83cdae078bdefa49f47ca8d3199475c.camel@gnu.org","subject":"Re: [PATCH v2 3/4] Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-12-01T12:37:09Z","receivedAt":"2022-12-01T13:25:59Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Nov 30 2022, Paul Smith wrote:\n\n> On Wed, 2022-11-30 at 13:28 +0900, Junio C Hamano wrote:\n>> I have to wonder how many projects they have broken with this change\n>\n> Some, but not that many. Most projects don't try to investigate\n> MAKEFLAGS, and of those that do many were already using the recommended\n> method, because even prior to GNU make 4.4 it was possible for\n> MAKEFLAGS to have stray \"s\" characters, in unusual situations (for\n> example if MAKEFLAGS were set in the makefile).\n>\n> There were various bugs filed that various options could not be\n> investigated from within makefiles and also that running make from\n> within $(shell ...) didn't work right because MAKEFLAGS was not set.\n>\n> It was just a mess, trying to keep the value of MAKEFLAGS set to\n> different values at different points in the processing of make.\n\nIt was definitely a bit of a hack on our part, but to be fair before\nthis 4.4 release doing it this way was recommended by the\ndocumentation. I see you changed that recently, but maybe this on top\nmakes sense?\n\t\n\tdiff --git a/doc/make.texi b/doc/make.texi\n\tindex e3a3ade4..9e9a894e 100644\n\t--- a/doc/make.texi\n\t+++ b/doc/make.texi\n\t@@ -5069,7 +5069,7 @@ Variable @code{MAKEFILES}}.\n\t @vindex MAKEFLAGS\n\t Flags such as @samp{-s} and @samp{-k} are passed automatically to the\n\t sub-@code{make} through the variable @code{MAKEFLAGS}. This variable is\n\t-set up automatically by @code{make} to contain the flag letters that\n\t+set up automatically by @code{make} to contain the normalized flag letters that\n\t @code{make} received. Thus, if you do @w{@samp{make -ks}} then\n\t @code{MAKEFLAGS} gets the value @samp{ks}.\n\t \n\t@@ -5085,6 +5085,10 @@ option has both single-letter and long options, the single-letter option is\n\t always preferred. If there are no single-letter options on the command line,\n\t then the value of @code{MAKEFLAGS} starts with a space.\n\t \n\t+The value of @code{MAKEFLAGS} does not correspond to the order in which\n\t+command line options are provided. Both @w{@samp{make -sk}} and @w{@samp{make -sk}}\n\t+will result in a @code{MAKEFLAGS} value of @samp{ks}.\n\t+\n\t @cindex command line variable definitions, and recursion\n\t @cindex variables, command line, and recursion\n\t @cindex recursion, and command line variable definitions\n\t@@ -12378,10 +12382,13 @@ influences such as interrupts (@code{SIGINT}), etc. You may want to install\n\t signal handlers to manage this write-back.\n\t \n\t @item\n\t-Your tool may also examine the first word of the @code{MAKEFLAGS} variable and\n\t+Your tool may also examine the first word of the @samp{-$(MAKEFLAGS)} expression and\n\t look for the character @code{n}. If this character is present then\n\t @code{make} was invoked with the @samp{-n} option and your tool may want to\n\t stop without performing any operations.\n\t+\n\t+Note that this is not equivalent to checking for the first word of\n\t+@code{MAKEFLAGS}.\n\t @end itemize\n\t \n\t @node Windows Jobserver, , POSIX Jobserver, Job Slots\n\nI.e. that \"Your tool\" part seems to still be assuming 4.3 semantics.\n\n> Also, ensuring this trick for searching MAKEFLAGS continues to work\n> would have meant strictly controlling what new options we could add to\n> GNU make. I haven't seen any other project use the filter-out --%\n> trick that the Git makefiles do, but even with that it won't help if a\n> new single-letter option that takes an argument is added.\n\nI'd think it would probably make sense to promise that GNU make will\nnever add such options, so that what's currently documented continues to\nwork. I.e. it supports:\n\n\t--debug=all\n\nNot these forms:\n\n\t-dwhy\n\t-d=why\n\nBut if we're on the topic: The only reason git's Makefile uses these is\nbecause it's trying to fake up some pretty verbose-but-not-too-verbose\nmode. You can see this in our tree at \"shared.mak\", the kernel does\nsomething similar.\n\nFor our Makefile this is pretty close to what we'd get from a simpler:\n\n\tmake -B --debug=why -s |\n sed -E -n \\\n\t\t-e \"s/.*: update target '(.*).o' due to.*/ CC \\\\1.o/\" \\\n -e 's/due to.*//' \\\n -e 'p'\n\nI.e. when we have %.o\" targets this is emitting \" CC $@\" lines, I've\nleft matching the rest as an excercise for the reader, but it would be\ne.g. \"GEN_PERL\" or whatever for %.pm and so on.\n\nI don't know what this would look like exactly, but it would be neat if\nGNU make supported some way to emit such friendly output in\ngeneral. Something like a sprintf format where you'd have access to the\nsort of input that \"due to\" string gets internally (and perhaps a bit\nmore, e.g. something indicating overall progress through the graph...).\n\n"},{"id":"468606","messageId":"1rq7o244-pos8-rp21-1q49-3210454n89nr@tzk.qr","threadId":"58862","inReplyTo":"xmqqpmd4ulnj.fsf@gitster.g","subject":"Re: [PATCH v3 1/1] Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-12-06T07:48:18Z","receivedAt":"2022-12-06T07:48:51Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 1 Dec 2022, Junio C Hamano wrote:\n\n> Paul Smith writes:\n>\n> > On Wed, 2022-11-30 at 09:23 +0100, Ævar Arnfjörð Bjarmason wrote:\n> >> Since GNU make 4.4 the semantics of the $(MAKEFLAGS) variable has\n> >> changed in a backward-incompatible way, as its \"NEWS\" file notes:\n> >\n> > Hrm. I did try to look through the other makefiles to find similar\n> > constructs and get them all, but apparently my grep fu was\n> > insufficient. Bother.\n> >\n> > Thanks.\n>\n> Thanks, both. Will queue.\n\nI noticed that this patch also touches Git GUI, a change which technically\nshould have come in via https://github.com/prati0100/git-gui, not directly\nvia git/git.\n\nSo let's make Pratyush [Cc:ed] aware of this change.\n\nWe probably want to avoid applying Git GUI changes directly to git/git in\nthe future. In the meantime, because I know that Pratyush is busy, I\nopened https://github.com/prati0100/git-gui/pull/83 with a (partial)\nbackport of this patch.\n\nThe following command demonstrates that this change is the only divergence\nthat would need backporting into Git GUI (the first SHA is the current tip\nof git/git's `main` and the second SHA is the latest git-gui tip that was\nmerged into git/git):\n\n\tgit diff 2e71cbbddd6:git-gui df4f9e28f64:\n\nFor the record, there is one change in git-gui's main branch that has not\nyet made it into git/git [*1*], but it merely appends a full stop\ncharacter to the end of a sentence in the `README.md` file, therefore\nthere is probably no urgency in pulling git-gui into git any time soon.\nThat typo fix waited over a year to make it into git/git, it can easily\nwait some more.\n\nCiao,\nJohannes\n\nFootnote *1*: https://github.com/prati0100/git-gui/commit/8cf36407cab\n"},{"id":"468608","messageId":"221206.86edtdc4rg.gmgdl@evledraar.gmail.com","threadId":"58862","inReplyTo":"1rq7o244-pos8-rp21-1q49-3210454n89nr@tzk.qr","subject":"Re: [PATCH v3 1/1] Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-12-06T08:13:08Z","receivedAt":"2022-12-06T08:32:15Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Dec 06 2022, Johannes Schindelin wrote:\n\n> Hi Junio,\n>\n> On Thu, 1 Dec 2022, Junio C Hamano wrote:\n>\n>> Paul Smith writes:\n>>\n>> > On Wed, 2022-11-30 at 09:23 +0100, Ævar Arnfjörð Bjarmason wrote:\n>> >> Since GNU make 4.4 the semantics of the $(MAKEFLAGS) variable has\n>> >> changed in a backward-incompatible way, as its \"NEWS\" file notes:\n>> >\n>> > Hrm. I did try to look through the other makefiles to find similar\n>> > constructs and get them all, but apparently my grep fu was\n>> > insufficient. Bother.\n>> >\n>> > Thanks.\n>>\n>> Thanks, both. Will queue.\n>\n> I noticed that this patch also touches Git GUI, a change which technically\n> should have come in via https://github.com/prati0100/git-gui, not directly\n> via git/git.\n> \n> I noticed that this patch also touches Git GUI, a change which technically\n> should have come in via https://github.com/prati0100/git-gui, not directly\n> via git/git.\n> \n> So let's make Pratyush [Cc:ed] aware of this change.\n> \n> We probably want to avoid applying Git GUI changes directly to git/git in\n> the future. In the meantime, because I know that Pratyush is busy, I\n> opened https://github.com/prati0100/git-gui/pull/83 with a (partial)\n> backport of this patch.\n\nShould it? I looked at https://github.com/prati0100/git-gui#contributing\nbefore including git-gui in that change, which says:\n\n\tEven though the project is hosted at GitHub, the development\n\tdoes not happen over GitHub Issues and Pull Requests. Instead,\n\tan email based workflow is used. The Git mailing list\n\t[git@vger.kernel.org](mailto:git@vger.kernel.org) is where the\n\tpatches are discussed and reviewed.\n\nAs a bit of deja-vu when trying to find if that was outdated or not I\nfound that you seemed to have had pretty much this exact exchange\nalready with the git-gui maintainer at\nhttps://lore.kernel.org/git/20190924122306.bcwe37wlahjimve7@yadavpratyush.com/\n\nWhich seems to have been followed-up by\nhttps://lore.kernel.org/git/pull.361.git.gitgitgadget@gmail.com/;\nI.e. you sent a git-gui change to this ML.\n\nOr do you mean that it should have been sent to this ML, Pratyush should\nhave pulled it, and Junio would have pulled upstream after that?\n"},{"id":"468609","messageId":"xmqqv8mo99ol.fsf@gitster.g","threadId":"58862","inReplyTo":"221206.86edtdc4rg.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v3 1/1] Makefiles: change search through $(MAKEFLAGS) for GNU make 4.4","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-12-06T09:13:30Z","receivedAt":"2022-12-06T09:13:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> Which seems to have been followed-up by\n> https://lore.kernel.org/git/pull.361.git.gitgitgadget@gmail.com/;\n> I.e. you sent a git-gui change to this ML.\n>\n> Or do you mean that it should have been sent to this ML, Pratyush should\n> have pulled it, and Junio would have pulled upstream after that?\n\nThe destination of the e-mailed patch was fine. I think what Dscho\nis saying is that the patch for git-gui should have been split into\nits own patch that is rooted at that project, i.e. the \"diff --git\"\nline shouldn't have had \"a/git-gui/Makefile\" but just \"a/Makefile\"\nif the patch were to modify the top-level Makefile of that project.\n\nThen the git-gui maintainer picks up the patch (after possible\nreview iterations), applies to his or her tree, and tells me to pull\nthe result with \"-Xsubtree=git-gui\" option.\n\nAt least that was how the world worked, when we had an active\ngit-gui maintainer. The same story goes for gitk part of the tree.\n\nThese days, neither subtree is very active and I am not sure how\nmuch value we are getting out of this \"clean separation\".\n\nThanks.\n\n"}]}