[Development] Enabling -Werror developer builds

[Alan Alpert]

On Mon, Aug 19, 2013 at 3:14 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> Hello
>
> Commit ebfd85a499a4382ace09d443b1f35cd6b1848af6 adds support for -Werror, but
> it hasn't been acted on yet. The commit says:
>
>     This is enabled only for -developer-builds and only for certain
>     compiler-version combinations that are in a whitelist.
>
>     It also requires each library, plugin or tool to declare whether it is
>     supposedly clean of warnings. When most targets are clean, we can
>     consider inverting.
>
> So, expanding:
> 1) -Werror is opt-in for regular builds (pass -warnings-are-errors to
> configure), and opt-out for developer builds (pass -no-warnings-are-errors).
>
> 2) -Werror is enabled only for certain compiler versions. I'll update the
> whitelist to have an upper range too. For example, right now it enables -
> Werror for GCC 4.6 and above. I'm going to introduce an upper limit because we
> don't know what new warnings our code triggers with newer versions of GCC.
> That means we'll need to first clean up the warnings before expanding the
> whitelist.

How is this "clean up" to be managed? The scenario I'm envisioning is
that warnings are cleaned up inside qtbase, allowing the change to
pass CI, while a new warning appears in another module which is then
broken by the qtbase change. We might need to integrate qt5.git
merging into the whitelist expansion test somehow, or provide another
solution so that all modules are checked before updating the
whitelist.

Other than this future concern, setting -Werror like this sounds good
to me. Some people build with it already so I've received bugs before
when public headers don't compile with -Werror.

--
Alan Alpert