why automake command-line options were low in precedence

[Ralf Wildenhues]

Imagine you have no special option in AM_INIT_AUTOMAKE nor
AUTOMAKE_OPTIONS, and say, Automake is changed so that command-line
options override the other two.  Then you run

$ automake --foreign

Then Makefile.in contains --foreign in the rebuild rules for itself.

Now, after hard work to make your package gnu-clean, you

$ echo "AUTOMAKE_OPTIONS = gnu" >> Makefile.am

and duly rerun 'make'.  Oops: that --foreign would just cause automake
to ignore your option.  Worse yet, you can `touch Makefile.am' all you
like, it won't go away through rebuilding unless you explicitly rerun
automake or autoreconf.


The story is similar when you originally had `foreign' in
AUTOMAKE_OPTIONS, but we can fix that setup by not propagating
AUTOMAKE_OPTIONS to command-line arguments in the rebuild rule.

But below is a patch to show what I mean.  (I don't grep Makefile.in on
purpose, to not specify the specific manner in which --foreign is
encoded there).

Maybe we need two kinds of command-line options, or a separator between
them.  Or a --no-override switch that turns them to low-precedence, so
that AUTOMAKE_OPTIONS would override regen rules.  As in: the
Makefile.in rule would contain:

        cd $(srcdir) && $(AUTOMAKE) --no-override --foreign Makefile

But even with that strategy, there are situations where things can
happen that I would not consider intuitive.  Consider this scenario:

Say, AUTOMAKE_OPTIONS contains `foreign', now the package has been made
gnu-compatible, and the developer decides to run

  automake --gnu Makefile

which in turn means the rebuild rule will contain (as per above change)

        cd $(srcdir) && $(AUTOMAKE) --no-override --gnu Makefile

but any triggered rebuild will let the `foreign' from AUTOMAKE_OPTIONS
win again.

In summary, I don't see a way to let command-line options interact with
the other option setters without surprises in some situations (whether
the command line has high or low precedence).  With that in store, I
don't know if it is useful at all to change the precedence.

Does that make sense?

Thanks,
Ralf

    Ensure AUTOMAKE_OPTIONS can override earlier command-line options.
    
    * tests/amopts-override.test: New test.
    * tests/Makefile.am (TESTS): Adjust.

diff --git a/tests/Makefile.am b/tests/Makefile.am
index a9672ac..045c2b5 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -135,6 +135,7 @@ amassign.test \
 ammissing.test \
 amopt.test \
 amopts-location.test \
+amopts-override.test \
 amopts-variable-expansion.test \
 amsubst.test \
 ansi.test \
diff --git a/tests/amopts-override.test b/tests/amopts-override.test
new file mode 100755
index 0000000..8a8d84f
--- /dev/null
+++ b/tests/amopts-override.test
@@ -0,0 +1,45 @@
+#! /bin/sh
+# Copyright (C) 2011 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# It should be possible to override an earlier automake command-line
+# option with AUTOMAKE_OPTIONS.
+
+. ./defs || Exit 1
+
+AUTOMAKE=$original_AUTOMAKE
+
+cat >>configure.in <<\END
+AC_OUTPUT
+END
+
+: >Makefile.am
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE -a --foreign
+# Makefile.in now contains --foreign.  Ensure it is retained somehow.
+./configure
+touch Makefile.am
+$MAKE
+$sleep
+# Setting AUTOMAKE_OPTIONS should have an effect.
+cat >Makefile.am <<\END
+AUTOMAKE_OPTIONS = gnu
+END
+AUTOMAKE_fails
+grep README stderr
+
+: