>>>>> "dv" == Didier Verna <[EMAIL PROTECTED]> writes:

dv>     Hi!

Salut !

dv> Here's an attempt to implement warning disabling by passing a
dv> `no<category>' argument to -W (or in the WARNINGS env var. The
dv> `syntax' category is also turned back on by default.

This is not enough: -Wall,nosyntax will not work as expected, and
-Wnone, as suggested by Alexandre, would be great.

But you raised real problems which go beyond the scope of Autoconf and
which should be cleanly solved once for all, if possible uniformly for
all the GNU tools.

Let me explain the idea that led to the inception of the envvar
WARNINGS.

There are plenty of tools, such as gawk etc., which are able to spot
portability issues, or constructs they tolerate but as extensions.  If
you intend to develop a portable application, you really want to know
if you use such things, but you don't want to set $AWK, $CC etc. with
the -Wall etc.  In addition, there is no standard option accepted by
all the tools.

A simple idea is a new std envvar, WARNINGS which contains a comma
separated list of warning categories.  Two are mandatory: error, and
all.  More may be needed, eg, posix, none, portable.  Then just run
the test suite with WARNINGS=all,error, and you should be able to
catch quite a few things (this would be a pleasure for the Autoconf
test suite: being able to simulate the brokenness of some systems).

The existence of this variable is one thing, its use another one.

You raise the problem of service interaction between a. applications'
defaults, b. WARNINGS, c. command line options.

There are several options:


      i Cumulative:
        Honor a + b + c (user should use `none' or `nosth' to remove
        something in a or b).


     ii Cumulative defaults:
        Honor c if given, otherwise a + b.


    iii Chain:
        Honor c if given otherwise b otherwise a.


I personally prefer iii.


We first have to make a choice, then implement IMHO.  We need a full
specification, for instance we must decide whether several --warnings
accumulate ---IMHO, they should.  Also, it should be case insensitive
(think of POSIX for instance).


There maybe other problems I didn't spot, feel free to highlight them,
as you did for `no<cat>'.

        Akim

Reply via email to