Hello Behdad, and thanks for the bug report,
* Behdad Esfahbod wrote on Sat, Dec 18, 2010 at 01:55:22AM CET:
> If instead automake was changed to always pre-initialize *CLEANFILES
> variables, all snippets could just append to do variables and my git.mk
> snippet would be more generic and much more simpler at the same time.
What you can do now is either
- require your users to pre-initialize variables, or
- ship a header fragment to be included first, that sets the needed
variables.
Your proposed change would break typo detection, if we allowed += for
all unset variables. The question is whether typo detection is worth
it. If we only do it for *CLEANFILES variables, that would be very
inconsistent. Users have the same problems with lots of other variables
(EXTRA_DIST, SUFFIXES, SUBDIRS, etc, the list is not stable; see for
example gnulib/gnulib-tool for others). They would not be helped, while
at the same time Automake semantics becomes harder to grasp.
There are more subtle issues with conditionals and with variables that
are already set by automake or that are AC_SUBSTed from configure.ac; in
fact, most of all the uniqe/once-only/override warning machinery is to
disallow ambiguities in these cases.
For example, automake sets DIST_COMMON, an internal variable. Assume
the user writes
DIST_COMMON += foo
Should that add to the automake-given list? I would guess so. But what
about the following (assuming AC_SUBST([substed])):
foo = foo
if COND1
foo = bar
substed = bar
DIST_COMMON = bar
else
foo += baz
substed += baz
DIST_COMMON += baz
endif
The expectation again is clear, and for 'foo' things work out, but it is
not possible to realize for substed with the current implementation where
AC_SUBST([substed]) generates a single
substed = @substed@
line in Makefile.in. It might be fixable, but I haven't looked into it
and assume that at least the disjoint-condition handling may turn out
ugly.
Cheers,
Ralf
