disabling -Werror on a autotools based build

Ralf Corsepius rc040203 at freenet.de
Mon Mar 28 03:47:20 UTC 2011


On 03/28/2011 12:48 AM, Kevin Kofler wrote:
> Sergio Belkin wrote:
>
>> 2011/3/27 Ralf Corsepius<rc040203 at freenet.de>:
>>> Packages adding -Werror by themselves are poorly designed.
>>
>> Just to learn: Ralf, Why do you say that? :-)
>
> Using -Werror by default is a very bad idea. Warnings can have false
> positives, or otherwise be harmless.  And in particular, different compiler
> versions can trigger different warnings: false positives get fixed, but new
> warnings get added. So using -Werror makes you very dependent on the
> compiler version.

.. and the architecture and other cflags ...

In practice, people who are adding -Werror to their configurations by 
default sooner or later will experience, their code will to not compile 
in environments different from theirs, because different warnings will 
be raised and because minor warnings are being escalated to errors by 
-Werror.

Surely, warnings indicate "there might be something wrong with the code, 
somebody may want to look into", but blindly making warnings errors 
isn't wise either.

Less theoretical: gcc-4.6.0 for instance warns about 
"unused-but-set-variable", at places where gcc < 4.6.0 had been silent:

foo.c:89:34: warning: variable 'status' set but not used 
[-Wunused-but-set-variable]

When looking into the code, you will discover cases like this:

int doXXX()
{
    int status = doXXX();
    ...
}

Nothing wrong with code, just an overly nervous compiler.

> And really, a warning is not an error for a reason.

Exactly.

> It makes sense to use -Werror-* for some specific warnings, e.g.
> -Werror-implicit-function-declaration in C, but a blanket -Werror in shipped
> tarballs is a very bad idea.

ACK.

More generally speaking, -Werror is suitable for upstream developers, 
when trying to go after issues with their code, but automatically adding 
it is hardly suitable for production SW-packages.

Ralf




More information about the devel mailing list