Subject: bug#7763: Remake rules botch up when 'foreign' and 'ignore-deps' are removed from AM_INIT_AUTOMAKE

From: Stefano Lattarini <[email-masked]>
Date: Thu, 30 Dec 2010 23:38:45 +0100

Hello automakers.

Currently, the Automake-generated rebuild rules[1] invoke automake with
some command-line options derived from arguments given to AM_INIT_AUTOMAKE.

[1] For more info, see:
    <http://www.gnu.org/software/automake/manual/html_node/Rebuilding.html>

For example, putting `foreign' in AM_INIT_AUTOMAKE generates remake rules
that rebuild outdated Makefile.in files using "$(AUTOMAKE) --foreign";
similarly, `no-dependencies' in AM_INIT_AUTOMAKE generates remake rules
that rebuild outdated Makefile.in files using "$(AUTOMAKE) --ignore-deps".

This semantic clearly breaka remake rules in the (admittedly unlikely and
corner-case) situation when e.g., `foreign' or `no-dependencies' arguments
are removed from the call to AM_INIT_AUTOMAKE (see attached testcases,
which should work with latest master -- v1.11-564-g635a250).

Let's now see explicitly and in detail how this happens (for the case of
the `foreign' option) ...

-*-*-

First, the developer creates a configure.ac that contains:
  AM_INIT_AUTOMAKE([foreign -Wall])
He runs aclocal, autoconf and automake; this generates a Makefile.in that
contains rebuild rules which call automake as "$(AUTOMAKE) --foreign".
He then runs configure, and those rebuild rules end up verbatim in the
generated Makefile.

At this point, the developer decides he wants to switch to the 'gnu'
strictness for his package; since 'gnu' is indeed the default strictness,
he simply modifies the AM_INIT_AUTOMAKE call to read:
  AM_INIT_AUTOMAKE([-Wall])
and then run "make", trusting that the rebuild rules in Makefile will
do all the required updates for him.

But alas, the existing rebuild rules in the Makefile will call
"$(AUTOMAKE) --foreign", and so, since no strictness is explicitly
specified in AM_INIT_AUTOMAKE, the 'foreign' strictness will still
be used.

-*-*-

Cooking up a patch to fix this problem shouldn't be difficult; but such a
patch would need to touch the same parts of the code modified by the pending
patch series "Explicit warning levels must always take precedence over those
implied by the strictness":
 <http://lists.gnu.org/archive/html/automake-patches/2010-12/msg00139.html>
Thus I will wait for that series to be applied first, to spare me useless
conflicts when merging and/or rebasing.

Regards,
   Stefano