[lmi] make: chaining target-specific, immediately-expanded variables

[Greg Chicares]

With this makefile:

--8<----8<-- eraseme.make --8<----8<--
target1:
        @echo xyz   = "$(xyz)"
        @echo flags = "$(flags)"
        touch $@

target2:
        @echo xyz   = "$(xyz)"
        @echo flags = "$(flags)"
        touch $@

xyz := default

target2: xyz += nondefault

flags := $(xyz)
--8<----8<-- eraseme.make --8<----8<--

what does
  make -f eraseme.make target2
echo?

SPOILER ALERT: ANSWER BELOW

Maybe the answer is obvious, but I was surprised.

I had expected that 'xyz' would be "default nondefault",
and that 'flags' would have the same value as 'xyz'.

'make' reads a makefile in two phases, and immediately-expanded
variables are assigned only in that phase.

The variables here are immediately expanded, so they're set in
the first phase only.

The question is: when and how are target-specific variables set?

AFAICS:
 - 'xyz' has a target-specific value, which is respected in the
   first phase, so it gets the value "default nondefault".
 - 'flags' has no target-specific value, so in the first phase
   it's assigned the value "default": the non-target-specific
   value of 'xyz', not its target-specific value. This surprised
   me because the non-target-specific value of 'xyz' doesn't seem
   to come into play when building 'target2', but 'make' decides
   what target(s) to build only in its second phase.

That's the only way I know to explain the output with make-4.3:

xyz = default nondefault
flags = default
touch target2

This minimalistic example demonstrates a latent defect in
'compiler_gcc.make', whose $(REQUIRED_COMPILER_FLAGS) is
immediately expanded. If $(optimization_flag) is added to
its definition instead of to $(CXXFLAGS), then this
target-specific value:

$(product_file_sources): optimization_flag += $(product_file_flags)

is disregarded.