On Tue, Apr 05, 2022 at 09:56:20PM +0200, Ævar Arnfjörð Bjarmason wrote:
Show 48 quoted lines
> 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>