Allow easy disabling of Werror in source code releases

[Artoria2e5]

While -Werror is a great thing for engineering and especially for CI testing, it gives users unnecessary problems as compilers may add new warnings in new releases. Therefore, putting -Werror in a non-development versions for users to compile is usually a short-sighted move.

From what I can see now, CoreCLR's -Werror is especially troublesome for "cutting edge" distros like Arch Linux (#8317, #6941). It has also broken on "fresh" OS X releases (#7275) as well as with new library versions that deprecate old methods (#7376, #5914). Although these information can be helpful for CoreCLR developers in finding potential problems, it must be recognized that users should be given a easy way to just make it compile instead of having a package randomly break due to non-critical outside changes.

(By "easy disabling" I am referring to some flags to append, not "just sed it away".)

List of -Werror spots: https://github.com/dotnet/coreclr/search?utf8=%E2%9C%93&q=Werror

[broncotc]

+1

[omajid]

Seconding. See also https://blog.flameeyes.eu/2009/02/future-proof-your-code-dont-use-werror/:

Because things change, and especially, warnings are added. The fact that a new compiler is stricter and considers a particular piece of code as something to warn about is not going to change the quality of the software per-se; ... users often enough just need the thing to build and work when they need it, and would prefer not to have to fix a few warnings first.

[swgillespie]

Also noting that it's not uncommon for projects using CMake to allow for users to specify CMake variables that determine if warnings are errors (e.g. LLVM's LLVM_ENABLE_WERROR http://llvm.org/docs/CMake.html). We could do something like that to turn -Werror off by default (for dev builds) but leave it on in the CI.

[am11]

@swgillespie, I think we can already do that: ./build.sh -cmakeargs -DLLVM_ENABLE_WERROR:BOOL=OFF

[swgillespie]

@am11 Yeah, if we had an equivalent of LLVM_ENABLE_WERROR, in our own CMake files, but we don't. I was suggesting that we do something similar to LLVM, not that we adopt their naming conventions for build-time variables.