Warning options

Warning options

[skaller]

Ocaml appears to be following the same path as gcc with
respect to warnings: if a warning option isn't recognized
it is reported as a hard error.

This feature creates an unnecessary upwards compatibility
barrier, and I request the INRIA team consider fixing it.
The correct strategy is to generate a warning, but
continue compiling anyhow. 

The alternative is to use 'autoconf' style configuration
checks in all build configurations (which is I hate)

This problem affected me as follows:

(a) I am using CVS Ocaml

(b) There is a new warning Y -- unused variable
    added to the CVS version of Ocaml

(c) I have lots of code, some not written by me,
    which triggers that warning, and in the clutter
    I actually missed an important warning
    (incomplete match)

(d) I put -w y to disable the warning

(e) My client can't build the code now, because he isn't
using the CVS version of Ocaml, his version doesn't
support the new warning

Warning flags should be treated like #pragma in C: the
compiler is *required* to ignore one it does
not recognize.

My comment does not apply to compiler options with
a semantic impact, however warnings are purely
a quality of implementation issue (QUI).

Ignoring bad warning flags is also mandatory for upwards 
compatility in cases where the implementor wishes 
to remove a warning.

My suggestion is simply that in this case only:

  -w ?

the value of ? is used if possible, and a warning
printed if this version of the compiler doesn't know
what it means, alternatively ignore it completely,
or provide a new warning like -w W w which disables/enables
the warning about bad warning flags depending on the
default (kind of complex ..)


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] Warning options

[Damien Doligez]

On Feb 11, 2005, at 01:48, skaller wrote:

> Ocaml appears to be following the same path as gcc with
> respect to warnings: if a warning option isn't recognized
> it is reported as a hard error.
>
> This feature creates an unnecessary upwards compatibility
> barrier, and I request the INRIA team consider fixing it.
> The correct strategy is to generate a warning, but
> continue compiling anyhow.

You're right, I will remove the check and silently ignore the
bad warning flags.

> (d) I put -w y to disable the warning

In the meantime, you can use "-w aCDFMPSUVX" to disable the Y
warning in a compatible way.  Not very elegant, but it should
work.

> or provide a new warning like -w W w which disables/enables
> the warning about bad warning flags depending on the
> default (kind of complex ..)

I don't think we want to go that far.

-- Damien