GNU bug report logs - #7673
Bad option precedence: AM_AUTOMAKE_INIT and AUTOMAKE_OPTIONS might win over command line

Previous Next

To reply to this bug, email your comments to 7673 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Bad option precedence: AM_AUTOMAKE_INIT and AUTOMAKE_OPTIONS might
	win over command line
Date: Sat, 18 Dec 2010 15:12:17 +0100

Hello automakers

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:

  $ touch install-sh missing COPYING README AUTHORS NEWS INSTALL
  $ cat > configure.ac <<'END'
  AC_INIT([foo], [1.0])
  AM_INIT_AUTOMAKE([gnu])
  AC_CONFIG_FILES([Makefile])
  END
  $ : > Makefile.am
  $ aclocal
  $ automake --foreign
  Makefile.am: required file `./ChangeLog' not found
  $ sed -i 's/^AM_INIT_AUTOMAKE.*/AM_INIT_AUTOMAKE/' configure.ac
  $ echo 'AUTOMAKE_OPTIONS = gnu' > Makefile.am
  $ automake --foreign
  Makefile.am: required file `./ChangeLog' not found

While this behaviour might have had its historical reasons, I think its
confusing, suboptimal, and inconsistent with that of pratically all the
sane Unix and GNU programs.

The right precedence for *every* option would IMHO be:

 "command line" wins over AUTOMAKE_OPTIONS wins over AM_INIT_AUTOMAKE

Regards,
   Stefano

Message #8 received at 7673 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7673 <at> debbugs.gnu.org
Subject: Re: bug#7673: Bad option precedence: AM_AUTOMAKE_INIT and
	AUTOMAKE_OPTIONS might win over command line
Date: Sun, 19 Dec 2010 12:48:13 +0100

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

Cheers,
Ralf

Message #11 received at 7673 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 7673 <at> debbugs.gnu.org
Subject: Re: bug#7673: Bad option precedence: AM_AUTOMAKE_INIT and
	AUTOMAKE_OPTIONS might win over command line
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

Message #14 received at 7673 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 7673 <at> debbugs.gnu.org
Subject: Re: bug#7673: Bad option precedence: AM_AUTOMAKE_INIT and
	AUTOMAKE_OPTIONS might win over command line
Date: Thu, 23 Dec 2010 19:47:36 +0100

On Saturday 18 December 2010, Stefano Lattarini wrote:
> The right precedence for *every* option would IMHO be:
> 
>  "command line" wins over AUTOMAKE_OPTIONS wins over AM_INIT_AUTOMAKE
> 
JFTR, this is where the issue came up first:
 <http://lists.gnu.org/archive/html/automake-patches/2010-10/msg00033.html>

Sorry for not adding that reference or citing the original reporter
(Andrew W. Nosenko) right away.

Regards,
   Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.