[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible bug with pattern-specific variables
From: |
Markus F.X.J. Oberhumer |
Subject: |
Re: Possible bug with pattern-specific variables |
Date: |
Wed, 27 Sep 2023 17:17:08 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
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 the expression "BAR +=" duplicate the contents of BAR ?
2) and I had expected that BAR is immutable anyway, just like FOO
~Markus
On 2023-09-27 16:51, Bahman Movaqar wrote:
> 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 test.h
> $(objects) : config.h
> 🙸
>
> In the above snippet, last line is not recipe for for `$(objects)'.
> However, it does mutate its prerequisites.
>
> In the same vein, line #2 of your snippet, while not being a recipe for
> `build/release', updates its prerequisites (in this case just a
> variable.)
>
> See https://www.gnu.org/software/make/manual/make.html#Multiple-Rules
>
> Does that make sense?
>
--
Markus Oberhumer, <markus@oberhumer.com>, http://www.oberhumer.com/