[Top][All Lists]

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

why automake command-line options were low in precedence

From: Ralf Wildenhues
Subject: why automake command-line options were low in precedence
Date: Sat, 22 Jan 2011 09:43:57 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

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 contains --foreign in the rebuild rules for itself.

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

$ echo "AUTOMAKE_OPTIONS = gnu" >>

and duly rerun 'make'.  Oops: that --foreign would just cause automake
to ignore your option.  Worse yet, you can `touch' 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 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 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?


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

diff --git a/tests/ b/tests/
index a9672ac..045c2b5 100644
--- a/tests/
+++ b/tests/
@@ -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
+# 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 <>.
+# It should be possible to override an earlier automake command-line
+# option with AUTOMAKE_OPTIONS.
+. ./defs || Exit 1
+cat >> <<\END
+: >
+$AUTOMAKE -a --foreign
+# now contains --foreign.  Ensure it is retained somehow.
+# Setting AUTOMAKE_OPTIONS should have an effect.
+cat > <<\END
+grep README stderr

reply via email to

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