When is -Werror a usage requirement?
- Dominant language
- Python
- Stars
- 191
- Forks
- 14
- PR merge metrics
- No merged PRs in 30d
Description
I think the answer to this is "never", and I think it should be excluded from the package specification. I'm referring to this part of the spec.
https://github.com/mwoehlke/cps/blob/30140eb6a4a96db35b6da15f61a2f4761cf91a44/features.rst#featureoptnofeaturewarnerror
To be sure, abstracting these options across compilers is itself a noble goal, but it is unclear to me why this abstraction needs to take place in a package spec. Such a feature seems more at home in a build system.
Unlike the language standards and threads options, warnings have no impact whatsoever on whether or not a consuming build succeeds and produces usable binaries. Adding `-Werror` to the mix becomes toxic. If I use `-Werror` and manually disable certain warnings, another package should not be able to enable them for me (nor be incompatible for this reason alone). On the other hand, if I do not wish to enable `-Werror` when testing with a nightly build of clang, then a package should not be able to force `-Werror` on me.
There is no shortage of examples of havoc wreaked by `-Werror`. Getting it injected transitively is a special kind of hell for package maintainers and first-party developers alike. Please remove this (or at least require that implementations provide a hook for disabling it).
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.