On Tue, Oct 5, 2010 at 14:24, Stefano Lattarini
<stefano.lattar...@gmail.com> 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 <andrew.w.nose...@gmail.com>
