Reviving an old thread about the following construct.
foo = mumble
if COND
foo = blurgle
endif
Tom> I've long thought that we should, eventually, support the
Tom> latter use. It seems to have a clearly defined meaning.
Tom> And it is even useful in some situations. For instance,
Tom> suppose in a very large project you want to `include' some
Tom> boilerplate. Then you might conditionally override some
Tom> value or another in a particular Makefile.am.
I think we have three choices:
1. Like with "standard" Makefile assignments, the second
definition of `foo' overrides the first one. So `foo'
is undefined when COND is false.
2. The second definition of `foo' _partially_ overrides the
first one. Yielding a definition equivalent to
if COND
foo = blurgle
else
foo = mumble
endif
3. This construct is ill-formed and should be diagnosed.
#3 is what Automake 1.7 assumes; it seems you want #2; and
#1 doesn't make any sense (just consider
if COND
a = A
else
a = B
endif
).
Let's consider another snippet.
if COND1
foo = mumble
else
foo = mumble
endif
if COND2
foo = blurgle
endif
At a first glance, this looks equivalent to the previous
construct. However Automake 1.7 isn't aware of this and
produces the following Makefile fragment, without the
slightest warning:
@COND2_TRUE@foo = blurgle
@COND1_TRUE@foo = mumble
@COND1_FALSE@foo = mumble
(The order of definitions in the output doesn't match the order
of definitions in the input, because Automake doesn't keep track
of this sort of things.)
IMO this is a bug. Either we should diagnose an error (#3), or we
should produce something sensible (#2).
If we take road #2, then the third `foo' definition should partially
override previous definitions of `foo', in the COND2 condition; as
if the user had written
if COND2
foo = blurgle
else
if COND1
foo = mumble
else
foo = mumble
endif
endif
This seems to suggest a way to implement #2 easily. When
defining a variable in condition `COND', append `!COND' to all
previous definitions' conditions.
This also works for things like
foo = mumble
foo = blurgle
which would be interpreted as
foo = blurgle
if FALSE
foo = mumble
endif
Something that I don't know how to handle is the tracking of
location for variables whose conditions have been changed as a
side effect of a redefinition. It will be confusing if Automake
diagnoses something about a variable `defined in condition
COND1_TRUE COND2_FALSE' and then point the user to the place
where the variable was simply defined in COND1_TRUE (should we
explain that COND2_FALSE was added because the variable was
later redefined in COND2_TRUE? how?)
Another question is when should this construct be allowed? I
agree #2 is useful when the definitions and redefinitions are in
different files. IMO #3 would be helpful when the
(re)definitions are in the same file. I can't think of any
reason why a variable would be redefined in the same file,
except user's inattention.
Opinions?
--
Alexandre Duret-Lutz
