[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible bug with pattern-specific variables

From: Bahman Movaqar
Subject: Re: Possible bug with pattern-specific variables
Date: Wed, 27 Sep 2023 08:54:13 -0700
User-agent: Evolution 3.50.0

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

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




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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]