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

[Andrew W. Nosenko]

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

>  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)

>  4. Add some more micellanous tests on options setting/overriding.
>  5. Implement the behaviour sketched in [3] above.  This might be
>     tricky, possibly requiring some non-obvious refactoring (in
>     which case more tests will be needed).

-- 
Andrew W. Nosenko <address@hidden>