Re: [RFC + SIMPLE PATCHES] {maint} foreign mode and -Wportability

[Stefano Lattarini]

On Tuesday 05 October 2010, Andrew W wrote:
> On Tue, Oct 5, 2010 at 14:24, Stefano Lattarini
> 
> <address@hidden> wrote:
> > On Tuesday 05 October 2010, Ralf Wildenhues wrote:
> >> I agree that it is wrong to let '-Wportability foreign' not
> >> produce portability warnings (esp. since the option parsing
> >> order between command-line, options in configure.ac, and
> >> options in Makefile.am makes overriding hard), but I think the
> >> right fix for that would be to remember whether we defaulted
> >> the '-Wportability' setting or whether it came from an explicit
> >> setting.
> > 
> > What about this proposal (I still have no code):
> > 
> >  1. Add proper test(s) ensuring that AUTOMAKE_OPTIONS in
> > Makefile.am win over AM_INIT_AUTOMAKE options in configure.in,
> > which in turn win over cmdline options.
> 
> Excuse me, but commandline should always win over defaults, config
> files, etc, IMO.
I agree, but unfortunately automake has not behaved like that for a
quite long time (at least w.r.t. setting of gnu/foreign/... modes),
and still doesn't today:

 $ aclocal --version
 aclocal (GNU automake) 1.11.1
 Copyright (C) 2009 Free Software Foundation, Inc.
  ...
 $ automake --version
 automake (GNU automake) 1.11.1
 Copyright (C) 2009 Free Software Foundation, Inc.
 ...
 $ cat > configure.in <<END
 AC_INIT([foo], [1.0])
 AM_INIT_AUTOMAKE([gnu])
 AC_CONFIG_FILES([Makefile])
 END
 $ touch Makefile.am install-sh missing
 $ touch INSTALL NEWS AUTHORS ChangeLog # but *not* `README'
 $ aclocal
 $ automake --foreign # fails!
 Makefile.am: required file `./README' not found
 $ echo $?
 1

Actually, it's worse that that, because automake is not even consistent
in having command line overridden by AM_INIT_AUTOMAKE:

 $ sed -i 's/^\(AM_INIT_AUTOMAKE\).*/\1([foreign])' configure.ac
 $ automake --gnu # fails again!
 Makefile.am: required file `./README' not found
 $ echo $?
 1

The same behaviours can be observed with at least versions 1.9.6 of
aclocal and automake.

> In our case it means that commandline should have
> precedence over both AUTOMAKE_OPTIONS in Makefile.am and
> AM_INIT_AUTOMAKE options in configure.in (thouch, I have no opinion
> about AUTOMAKE_OPTIONS vs. AM_INIT_AUTOMAKE precedence).
This must definitely be "AUTOMAKE_OPTIONS wins over AM_INIT_AUTOMAKE",
otherwise AUTOMAKE_OPTIONS has no reason to exist.

BTW, given the Automake design and required infrastructure, I'm starting
to think that the only command line arguments that should be accepted by
automake are `--help', `--version', and the list of individual makefiles
to be processed (if any).  All the other options/switches should be
reserved to AM_INIT_AUTOMAKE and AUTOMAKE_OPTIONS.  That would make
things much simpler and consistent.  And hopelessly break backward
compatibility :-(

> >  2. Clearly document the above behaviour in the manual.
> >  3. Add (xfailing) tests ensuring that explicit `-W...' options
> >     always win over implicit warnings triggered by foreign, cygnus,
> >     gnu or gnits modes. (QUESTION: should this be true regardless of
> >     the place the `-W...' options are specified?  E.g., should a
> >     `-Wportability' specified on command line enable portability 
> >     warnings even if `foreign' is specified in AM_INIT_AUTOMAKE?
> 
> Yes, should.  At least I would prefer it.  The same
>     AM_INIT_AUTOMAKE([foreign -Wportability])
> or
>     AM_INIT_AUTOMAKE([foreign -Wall])
> should enable them.
>
> Also
>     AM_INIT_AUTOMAKE([foreign -Wno-portability])
> should default the portability warnings to "off", but when invoked as:
>   $ automake -Wportability
> they should be turned on (regardless of -W... and startdard-strictness
> options in AM_INIT_AUTOMAKE or AUTOMAKE_OPTIONS)
I agree.  But again, this is not the case with current automake:

 $ cat > configure.in <<END
 AC_INIT([foo], [1.0])
 AM_INIT_AUTOMAKE([foreign])
 AC_CONFIG_FILES([Makefile])
 END
 $ touch install-sh missing
 $ echo 'foo = $(wildcard *)' > Makefile.am
 $ aclocal
 $ automake -Wportability -Werror # succeeds!
 $ echo $?
 0

And while I agree that the current behaviour is broken, fixing it seems
quite tricky.  But patches are very welcome ;-)

Regards,
  Stefano