This is true, but the whole things sounds like anathema to the OpenBSD ethos, as I know it, which seems obsessed with a sort of functional correctness and consistency.
Enabling Werror sounds like exactly the sort of thing that'd be encouraged by default, and only disabled on ports that couldn't be patched to fix it. Or at least, enabled on ports that can have it enabled.
(that said, I know that the vast majority of software won't compile with Werror, so, ?)
-Werror can be useful for CI, but elsewhere it is obnoxious. Warnings should be warnings, errors should be errors. If you always turn warnings into errors then you remove a useful tool.
Warnings do not mean the program is incorrect, and lack of warnings do not mean the program is correct. It is just heuristics, and changes between major versions and different implementations, even while the program execution behavior is exactly the same. OpenBSD cares about portability. A well implemented program should work correctly with a good range of different reasonable compilers, and -Werror really throws a wrench in that.
Imagine you want to update the compiler to a new major version that has some corner-case correctness improvement or some security mitigation feature - but it also has a new warning. Can't do that! Unless you change the source of a bunch of libraries and applications which you didn't write. Mistakes have been made fixing warnings, like the infamous Debian openssl fix that removed most of the entropy from generated ssh keys.
If you care about correctness, you pay attention to and fix warnings where appropriate, without forcing yourself by making all your builds on different compiler versions/implementations just fail.
There was a time that CPython wanted to add a deprecation warning, but some popular libraries ran tests with the equivalent of -Werror during a regular build/install (trying to be super-correct best-practices etc), so adding a warning would break compatibility with most of the ecosystem, so CPython couldn't just add the warning using the long-established system. Instead they had to come up with a new system for warnings shown in some circumstances and not others, to effectively trick these super-best-practices projects into still working.
There is nothing wrong with -Werror, if you control the exact set of diagnostics!
The problem are the "surprise me!" warning options (-Wall, -Wextra) of GCC which bring in diagnostics which differ from version to version. So then with -Werror, the language has become a moving target: what is considered a bad construct that stops the translation is changing.
The problem with not using -Wall and -Werror and just specifying the exact diagnostics you want, together with -Werror, is that you don't benefit from the discovery of defects brought about by new diagnostic options.
The fix for that is to have an ongoing thread of activity in your project dedicated to exploring new compiler options (supported by a special build configuration).
I'm not involved in OpenBSD but I don't see the value in preventing an end user from installing arbitrary packages just because the compiler was updated recently. The person being notified of the error is the wrong person.
True, but OpenBSD seems to some extent value correctness over "usability". I can imagine the argument being made that if something changed and caused the package to stop building, it should be fixed, because the warning was potentially significant.
Since they do want the OS to be practical and usable, though, your argument also holds true, and seems to take precedence here. Just kind of surprised they'd make a policy of explicitly patching out upstream's Werror, since it implies it's "supposed" to work with no errors.
You are speaking way too conceptually and not looking at the actual warnings that compilers report.
Some compilers will warn about:
while (true) { ... }
having a constant condition. The fix is to write:
for (;;) { ... }
to nobody's benefit.
I've used languages that warn if you use snake_case instead of camelCase, because it violates their preferred naming convention. Or if you accidentally use a tab somewhere, it'll warn about a mix of tabs and spaces.
None of these matter for correctness, yet you're advocating to break the build for correctness.
OpenBSD's ports tree gets compiled using multiple compilers (clang/gcc) and compiler versions (base 4.2.1, ports gcc8/11), across many different architectures. In most cases when an upstream has added -Werror to a Makefile, they have not considered this. It's good for testing, but not for reliably compiling software.
gcc has been shoving warnings into -Wall or -Wextra that actually belong to a linter for years, for example -Wmisleading-indentation.
Bug free software that compiles warning free has to be updated because of the stylistic preferences of some RedHat person practically with every new gcc release.
For KPI harvesting developers of course "fixing" non-issues is financially attractive.
