Message ID | patch-1.1-e700d372e0c-20220405T195425Z-avarab@gmail.com (mailing list archive) |
---|---|
State | Accepted |
Commit | 8af0699b7a86a6f3c2fe9b745bcbe56ec777feac |
Headers | show |
Series | Documentation/Makefile: fix "make info" regression in dad9cd7d518 | expand |
On Tue, Apr 05, 2022 at 09:56:20PM +0200, Ævar Arnfjörð Bjarmason wrote: > Fix a regression in my dad9cd7d518 (Makefile: move ".SUFFIXES" rule to > shared.mak, 2022-03-03). As explained in the GNU make documentation > for the $* variable, available at: > > info make --index-search='$*' > > This rule relied on ".texi" being in the default list of suffixes, as > seen at: > > make -f/dev/null -p | grep -v -e ^# -e ^$|grep -F .SUFFIXES > > The documentation explains what was going on here: > > In an explicit rule, there is no stem; so '$*' cannot be determined > in that way. Instead, if the target name ends with a recognized > suffix (*note Old-Fashioned Suffix Rules: Suffix Rules.), '$*' is > set to the target name minus the suffix. For example, if the > target name is 'foo.c', then '$*' is set to 'foo', since '.c' is a > suffix. GNU 'make' does this bizarre thing only for compatibility > with other implementations of 'make'. You should generally avoid > using '$*' except in implicit rules or static pattern rules. > > If the target name in an explicit rule does not end with a > recognized suffix, '$*' is set to the empty string for that rule. > > I.e. this rule added back in 5cefc33bffd (Documentation: add > gitman.info target, 2007-12-10) was resolving gitman.texi from > gitman.info. We can instead just use the more obvious $< variable > referring to the prerequisite. > > This was the only use of $* in our Makefiles in an explicit rule, the > three remaining ones are all implicit rules, and therefore didn't > depend on the ".SUFFIXES" list. > > Reported-by: Adam Dinwoodie <adam@dinwoodie.org> > Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> > --- > > On Tue, Apr 05 2022, Adam Dinwoodie wrote: > > > With this commit, I get the same noisy warnings, but I also get the > > error "could not open .texi: No such file or directory". > > Sorry about the regression. This fixes it, and as noted above I'm > pretty sure this was the only fallout of the change. > > (I didn't have building the full extended documentation as part of my > local build, but I'll be adding it now). Confirmed this patch fixes things for me. Thanks for the quick fix! Tested-by: Adam Dinwoodie <adam@dinwoodie.org>
Adam Dinwoodie <adam@dinwoodie.org> writes: > Confirmed this patch fixes things for me. Thanks for the quick fix! > > Tested-by: Adam Dinwoodie <adam@dinwoodie.org> Thanks, both.
On Wed, Apr 06, 2022 at 09:43:42AM -0700, Junio C Hamano wrote: > Adam Dinwoodie <adam@dinwoodie.org> writes: > > > Confirmed this patch fixes things for me. Thanks for the quick fix! > > > > Tested-by: Adam Dinwoodie <adam@dinwoodie.org> > > Thanks, both. Indeed; thanks for the fix, Ævar. This sub-thread was a fun read for me to get to learn about a new "make" quirk. You learn something new every day ;-). Thanks, Taylor
diff --git a/Documentation/Makefile b/Documentation/Makefile index 1eb9192dae8..44c080e3e5b 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -390,7 +390,7 @@ gitman.texi: $(MAN_XML) cat-texi.perl texi.xsl $(RM) $@+ gitman.info: gitman.texi - $(QUIET_MAKEINFO)$(MAKEINFO) --no-split --no-validate $*.texi + $(QUIET_MAKEINFO)$(MAKEINFO) --no-split --no-validate $< $(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml $(QUIET_DB2TEXI)$(DOCBOOK2X_TEXI) --to-stdout $*.xml >$@