>> This is not limited to this release candidate: GNU make has behaved
>> like this for a very long time. However, it was only recently
>> reported.
>>
>> See Savannah bug #10708.
>>
>> https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=10708
>>
>>
>> This is not targeted to be fixed in GNU make 3.81 however.
at> What do you mena by "fixed" - as far as I can see, this is not
at> bug, is it?
I think it could be considered a bug, yes.
at> In order to achieve the desired behaviour now I need a way to
at> check if patsubst has made any substitutions when called OR a way
at> to test the result of patsubst to the third argument. How is this
at> done?
I think you're misunderstanding the issue. It's true that the example
in the bug is needlessly complex, which leads to misunderstandings about
what the bug actually is... a lesson to us all to make the example as
simple as possible and to leave out everything not directly related to
reproducing the bug.
Consider this makefile:
./foo: ; @echo $@
One would expect (_I_ would expect) this to print:
./foo
because that's the target name in the makefile. But in fact it prints:
foo
because make canonicalizes the target names so it can match them up;
consider this:
foo: bar
./foo: ; @echo $@
does "./foo" depend on bar? Make says yes and I think it's right. But
I also think "$@" should be the literal name of the target associated
with the command script.
The same thing happens for prerequisites and "$<" etc... although this
is less obvious; consider:
foo: ./bar ; @echo $<
bar: ; @:
Now, does this print "bar" or "./bar"?
Anyway, there is no patsubst called here, and there's no way to know
whether the target had a "./" prefix or not (unless you do it yourself
by setting your own variable or something rather than relying on $@ etc.)
It cannot be done.