On Wed, Sep 27, 2023 at 9:33 AM Markus F.X.J. Oberhumer
wrote:
> Very stange GNU make behaviour with pattern-specific variables - note
Thank you for your report.
i attached a fix here https://savannah.gnu.org/bugs/index.php?64822
regards, Dmitry
On Wed, 2023-09-27 at 17:17 +0200, Markus F.X.J. Oberhumer wrote:
> Thanks for trying to help me understanding this issue.
It's a learning process for me too 🙂 Interesting topic!
>
> ### BEGIN Makefile
> FOO +=
> build/%: BAR +=
> build/release: ; @echo "FOO='$(FOO)' BAR='$(BAR)'"
> ### END
>
Thanks for trying to help me understanding this issue.
### BEGIN Makefile
FOO +=
build/%: BAR +=
build/release: ; @echo "FOO='$(FOO)' BAR='$(BAR)'"
### END
# changes BAR in unexpected ways; see 1) and 2) below
$ make FOO=X BAR=Y
vs.
# this works as expected
$ env FOO=X BAR=Y make
1) how can
I certainly tried out your snippet the first time before replying 🙂
To my mind, what you're missing is the fact that `build/% : BAR +=' is
evaluated as part of `build/release'.
It is no different than the following snippet from the manual:
🙶
objects = foo.o bar.o
foo.o : defs.h
bar.o : defs.h te
I think you did not get what I'm complaining about. Please
try this 3-line Makefile:
### BEGIN
FOO +=
build/%: BAR +=
build/release: ; @echo "FOO='$(FOO)' BAR='$(BAR)'"
### END
And run "make FOO=X BAR=Y"
BAR is now **two** Y aka 'Y Y' which does not make any sense.
~Markus
On 2023-09-27 16:2
Invoking make like `make FOO=X BAR=Y' causes Make to consider `FOO' and
`BAR' as special recursive/deferred variables.
>From GNU Make manual:
> all ordinary assignments of the same variable in the makefile are
> ignored; we say they have been overridden by the command line
> argument.
Each on
