[Top][All Lists]

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

bug#7671: Presetting various *CLEANFILES variables

From: Ralf Wildenhues
Subject: bug#7671: Presetting various *CLEANFILES variables
Date: Sun, 19 Dec 2010 12:43:54 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

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

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
    foo += baz
    substed += baz
    DIST_COMMON += baz

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


reply via email to

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