Subject: Re: bug#7673: Bad option precedence: AM_AUTOMAKE_INIT and AUTOMAKE_OPTIONS might win over command line

From: Stefano Lattarini <[email-masked]>
Date: Mon, 20 Dec 2010 19:34:31 +0100

On Sunday 19 December 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Sat, Dec 18, 2010 at 03:12:17PM CET:
> > Currently, the strictness-related options specified with AM_INIT_AUTOMAKE
> > in configure.ac and with AUTOMAKE_OPTIONS in Makefile.am win over those
> > specified on the command line:
> 
> > While this behaviour might have had its historical reasons,
> 
> The question is, what reasons?
> 
> > I think its
> > confusing, suboptimal, and inconsistent with that of pratically all the
> > sane Unix and GNU programs.
> 
> I agree.
> 
> > The right precedence for *every* option would IMHO be:
> > 
> >  "command line" wins over AUTOMAKE_OPTIONS wins over AM_INIT_AUTOMAKE
> 
> Somebody needs to find out why the choices were done, and what breaks,
> when we change this.  I remember that there were good reasons for this,
> but I all but forgot the details.
>
Here is one reason I could make out without having to search the archives
or the git logs (I hope to get to that in a second time).

Currently, in the automake-generated remake rules, automake gets invoked
with some command-line options that are derived from arguments passed to
AM_INIT_AUTOMAKE.  For example, having:
  AM_INIT_AUTOMAKE([gnu -Wall silent-rules no-dependencies])
in configure.ac will cause the remake rules to invoke automake with the
*command-line* options `--gnu' and `--ignore-deps'.

It's clear that, in this situation, having the command line options take
precedence over the options in AM_INIT_AUTOMAKE might cause those remake
rules to behave incorrectly whenever the arguments of AM_INIT_AUTOMAKE 
are modified.

For example, referring again to the example above, assume that we decide
that the conventions mandated by the GNU strictness are in fact too
strict for our package (maybe we don't want to ship a ChangeLog, say).
So we modify the AM_INIT_AUTOMAKE call to read:
  AM_INIT_AUTOMAKE([foreign -Wall silent-rules no-dependencies])
and run "make am--refresh" to regenerate the various Makefiles, configure,
config.status etc.  The rebuilt rules present in the current Makefile will
still invoke automake with the `--gnu' command-line option; if this would
take precedence over the `foreign' in AM_INIT_AUTOMAKE, the rebuild would
clearly fail.

At this point, it remains to understand why the remake rules invoke
automake with such command-line options, and if they have good reasons
to do so.

Regards,
   Stefano