Official source release builds should not abort on (compilation) warnings
I will put my conclusion up front:
Official source releases should not build software with
-Werroror the equivalent.
(By official source releases I mean things like 'we are releasing version 1.x.y of our package today'.)
Perhaps you disagree. Then the rest of this entry is for you.
As I write this, the current release version of Rust is 1.10.0. This version (and probably all previous ones) won't build on the recently released Fedora 24 because of a C compiler issue. This isn't because of bug in the Fedora 24 version of gcc, and it's not due to the Fedora 24 gcc uncovering a previously unrecognized bug in Rust. Instead it's because of, well, this:
src/rt/miniz.c: In function ‘tinfl_decompress’: src/rt/miniz.c:578:9: error: this ‘for’ clause does not guard... [-Werror=misleading-indentation] for ( i = 0; i <= 143; ++i) *p++ = 8; for ( ; i <= 255; ++i) *p++ = 9; for ( ; i <= 279; ++i) *p++ = 7; for ( ; i <= 287; ++i) *p++ = 8; ^~~ src/rt/miniz.c:578:47: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’ for ( i = 0; i <= 143; ++i) *p++ = 8; for ( ; i <= 255; ++i) *p++ = 9; for ( ; i <= 279; ++i) *p++ = 7; for ( ; i <= 287; ++i) *p++ = 8; ^~~ [...] cc1: all warnings being treated as errors
Rust has opted to compile much or all of the C in its source tree
with the gcc options
-Wall -Werror, which mean 'emit more or less
all warnings that you can, and if you emit any warnings consider
this an error and stop'. Fedora 24 is one of the first Linux
distributions to ship with gcc 6, and gcc 6 has added some more
warnings, which now pick up more nits in the C code, and now
Rust doesn't build.
It would be one thing if this was pointing out a previously undiscovered error. But it's not. The code in the Rust 1.10.0 release is merely not ideal, and this example neatly illustrates the problem with making 'not ideal' a fatal error in official source releases. Put simply, the compiler's definition of 'not ideal' changes over time.
When you set your official releases to build with
or the equivalent, you're putting yourself on quicksand. It's
basically guaranteed that future compiler versions will have different
opinions on what to warn about, which means that official releases
of your software are going to stop building at some point in the
future for no good reason. Having your software stop building for
no good reason is not helping people.
(I say 'for no good reason' because if it actually built, the release would be no more broken than it was before the new nits were reported. The nits were always there, after all, even on all the systems that didn't report them.)
I think it's fine to use
-Werror in development if you want to.
But the moment you make a release, my very strong sysadmin opinion
is that the job of that release is to build correctly in as many
environments as possible, including future environments. An attempt
to build a release should fail on a system only if the end result
would be incorrect in a new way.
(If a release is incorrect on both system X and system Y but this is only uncovered on system Y, that should not be a fatal error. It's sufficient for release builds to be bug for bug equivalent to each other. This is probably too tricky to do in most cases, although maybe you should provide a 'I don't care, just force it to build' configuration option that suppresses as many compiler errors as possible.)
Another way to put this is that
-Wall -Werror is a service for
the developers; it surfaces nits and forces developers to fix them.
However, releases are not made for developers, they're made for
outside people. Forcing developer issues on outside people is both
futile (since outside people are not developers) and annoying. Thus
actual releases should have things like compiler options reoriented
to serve the needs of outside people instead of developers.