Re: why automake command-line options were low in precedence

[Stefano Lattarini]

On Saturday 22 January 2011, Ralf Wildenhues wrote:
> 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.
>
And I think this should be changed.  After all, if the user wants
persistence of options between reruns, he can specify those option
in a "persistent place" (i.e., AM_INIT_AUTOMAKE in configure.ac or
AUTOMAKE_OPTIONS in Makefile.am), not on the command line.

Also, note that options such as `--ignore-deps' and `--foreign'
originated when automake still couldn't trace AM_INIT_AUTOMAKE
calls in configure.ac, so the command line was the only natural
place where to specify "global" options.  This is not anymore
the case today, and in fact I don't think we would find users
preferring:
  $ automake --foreign -Wall
over:
  AM_INIT_AUTOMAKE([foreign -Wall])
This is even more true now that we suggest to use autoreconf
(so that automake is not even directly called anymore!).

In short: most automake command-line options are an historical
accident, and (in the longish term) they should be treated as
such IMHO.

To summarize once again: if automake is finally changed to have
cmdline options take precedence over all other options, then the
use of cmdline options should be only a mean for *temporarily*
overriding the "proper" options, either for experimentation or
debugging.  Do not expect them to play nice with rebuild rules,
period.

-*-*-*-

Here are two examples which IMHO shows legitimate(ish) usages of
the proposed semantics.

A developer which currently uses 'foreign' strictness in his
package:
  AM_INIT([1.11.1 foreign dist-bzip2])
would like to (try to) convert to 'gnu' strictness.  To rapidly
gauge how complicate that might be, he runs (from top-level):
  $ automake --gnu
take a look at the warnings/errors, and decides whether going
on with the conversion would be appropriate.

And now a more complicated example, involving also the rebuild
rules.  A developer in the middle of converting the package from
'foreign' to 'gnu' spots an automake error that he thinks might
not be related to the new 'gnu' strictness; and tries this to
ascertain that with:
  $ automake --foreign path/to/culprit/Makefile
And in fact, the error is still there.  The developer makes some
research, understands the reason of that error, and adjusts the
Makefile.am to fix it.  He then wants to regenerate the Makefile,
and also all the relevant targets declared there.  So he does:
 $ (cd path/to/culprit && make clean all check)
an he will clearly expect (and want) the automake call triggered
by the rebuild rules *not* to use the `--foreign' option.

-*-*-*-

> 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.
>
See above.
 
> 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.
>
FWIW, I think the rebuild rules should never pass any command-line
option to automake.

> 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.
>
Yuck ...

> 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
>
This seems sligthly better.  But then you note ...
>
> 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?
>
Yes.  But maybe the precedence could still be changed, if what I wrote
above makes sense too.

> 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
>
With my proposed semantics, the test would break here.

> +$sleep
> +# Setting AUTOMAKE_OPTIONS should have an effect.
> +cat >Makefile.am <<\END
> +AUTOMAKE_OPTIONS = gnu
> +END
> +AUTOMAKE_fails
> +grep README stderr
> +
> +:
> 
> 

Regards,
  Stefano