Re: Possible bug with pattern-specific variables

[Bahman Movaqar]

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
> 
> 
> # 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 ?

That's about the only kind of assignment that works for "command
variables." 🤯  

However, my understanding is only based on trial-and-error and I haven't
been able to find any references to this particular assignment in the
manual except the excerpt I shared in my previous messages.

> 2) and I had expected that BAR is immutable anyway, just like FOO

The difference between `FOO' and `BAR' in your snippet is that the
pattern rule `build/%: BAR +=' matches the target `build/release' which
causes the variable assignment to be evaluated.

∎

As a rule of thumb, I rarely use command variables and environment
variables as they are.  They usually have cryptic all caps names which I
don't like at all.  To avoid them, I usually capture their value in
another "more consistent" variable before using them.  

For example, the following snippet predictably produces `my.bar=Y lorem
ipsum'.

🙶
my.bar = $(BAR)
build/%: my.bar += lorem ipsum
build/release: ; @echo "my.bar='$(my.bar)'"
🙸

∎

HTH,

-- 
Bahman

Join the chatter on Matrix:
         🌐 https://matrix.to/#/#.mk:matrix.org
      
Subscribe to the Lemmy community:
         🌐 https://lemmy.ml/c/makefile