[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andrew W. Nosenko
Subject: Re: [RFC + SIMPLE PATCHES] {maint} foreign mode and -Wportability
Date: Tue, 5 Oct 2010 17:18:53 +0300

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, and options in
>> 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
>     win over AM_INIT_AUTOMAKE options 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 and
AM_INIT_AUTOMAKE options in (thouch, I have no opinion

>  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])
    AM_INIT_AUTOMAKE([foreign -Wall])
should enable them.

    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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]