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@xxxxxxxxxxxxx> > Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> > --- > > 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@xxxxxxxxxxxxx>
