cps-org / cps-org/cps

When is -Werror a usage requirement?

Open
#15 3 comments 2 reactions 0 assignees View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.