Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow easy disabling of Werror in source code releases #7122

Closed
Artoria2e5 opened this issue Dec 12, 2016 · 5 comments
Closed

Allow easy disabling of Werror in source code releases #7122

Artoria2e5 opened this issue Dec 12, 2016 · 5 comments
Labels
question Answer questions and provide assistance, not an issue with source code or documentation.
Milestone

Comments

@Artoria2e5
Copy link

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
Copy link

+1

@omajid
Copy link
Member

omajid commented Feb 21, 2017

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
Copy link
Contributor

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
Copy link
Member

am11 commented Feb 21, 2017

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

@swgillespie
Copy link
Contributor

@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.

janvorli referenced this issue in dotnet/coreclr Jun 2, 2017
Add a build flag to make -Werror optional and let the build continue
even in the presence of warnings.

This option is very useful for anyone compiling with a different
(version of the) compiler. A different (version of the) compiler may
produce a different set of warnings and a piece of code that compiles
without warnings may emit warnings with a different (version of the)
compiler.

Resolves https://github.com/dotnet/coreclr/issues/8586
ellismg referenced this issue in ellismg/coreclr Jun 7, 2017
Add a build flag to make -Werror optional and let the build continue
even in the presence of warnings.

This option is very useful for anyone compiling with a different
(version of the) compiler. A different (version of the) compiler may
produce a different set of warnings and a piece of code that compiles
without warnings may emit warnings with a different (version of the)
compiler.

Resolves https://github.com/dotnet/coreclr/issues/8586
@msftgits msftgits transferred this issue from dotnet/coreclr Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Answer questions and provide assistance, not an issue with source code or documentation.
Projects
None yet
Development

No branches or pull requests

6 participants