On 2023-01-04, Mike Frysinger <vap...@gentoo.org> wrote:
> On 04 Jan 2023 21:10, Nick Bowler wrote:
[...]
>> maybe something like:
>>
>> % cat >Makefile <<'EOF'
>> at_f = $(@F)
>> foo/bar.o:
>> a='$(@F:.o=)' b='$(at_f:.o=)'; test x"$$a.o" = x"$(@F)" || a=$$b;\
>> echo $$a
>> EOF
>
> this is interesting. we actually have some uses of this already in
> the tree. no one seems to have complained though afaict.
Note that the NetBSD bug affects only substitutions on file/directory
variants like $(@F:a=b), there is no parse problem (that I know of)
with substitutions on the normal forms like $(@:a=b).
> automake-1.13+ has:
> lib/am/subdirs.am:AM_RECURSIVE_TARGETS +=
> $(am__recursive_targets:-recursive=)
>
> automake-1.9+ has:
> lib/am/texibuild.am: for f in $@ $@-[0-9] $@-[0-9][0-9]
> $(@:.info=).i[0-9] $(@:.info=).i[0-9][0-9]; do \
>
> dmake is one implementation that fails, and your suggestion doesn't work
> :/.
> $ dmake foo/bar.o
> dmake: Error: -- Incomplete macro expression [)' b='$(at_f:.o=)'; test
> x"$$a.o" = x"$(@F)" || a=$$b;\
> echo $$a]
Huh, I somehow have never noticed this problem with dmake. So the
right-hand side cannot be empty on this one.
> how portable is $() ? that seems to work in GNU make & dmake.
To expand to the empty string? I expect that's probably fine, but not
sure about using a make variable on the RHS of a suffix substitution.
At least, this does not appear to work on ULTRIX (the substituted string
is output literally, not expanded at all).
I think my trick can be salvaged to work on all of these crazy
implementations by substituting no-op shell syntax instead:
% cat >Makefile <<'EOF'
at_f = $(@F)
foo/bar.o:
a='$(@F:.o='')' b='$(at_f:.o='')'; \
test x"$$a.o" = x"$(@F)" || a=$$b; \
echo $$a
EOF
Cheers,
Nick
