4 ms·
> Unfortunately it's not as simple as always enabling -Werror: I was already bitten in the backside by Werror. Allow me to tell you how. I was working on a le
by nuerow 5y ago
> Unfortunately it's not as simple as always enabling -Werror:
I was already bitten in the backside by Werror. Allow me to tell you how.
I was working on a legacy C++ project and my employer uses an in-house build system that automatically builds the whole dependency tree if any dependency changes. A previous team was a staunch supporter of the "no Werror considered harmful" philosophy, and made it their point to even pass it to unit tests.
That's all fine and dandy, except compilers are upgraded and older compiler versions are deprecated out of our reach. Consequently, when I did a minor update to my project and launched a build job, the entire dependency tree started failing left and right, throwing a million error messages as a packed wall of text. The root cause? The current version of GCC was updated to throw warnings regarding some inane drivel involving white spaces, and with Werror passed everywhere those were upgraded to full blown errors.
The end result was a couple of weeks wasted going through the dependency tree to tackle warnings, because otherwise the build pipeline failed spectacularly.
- emidln 5y agoThis seems like your compiler toolchain definition should have been a part of your build system's graph. I do this exact thing, with -Werror on, and bumping to a new gcc version or clang version typically exposes new errors that will be blocking on gerrit until I fix the corresponding now warning code. Bazel makes this easy, but you can definitely do it with CMake or other systems too.
- danuker 5y ago> inane drivel involving white spaces I suspect you wouldn't enjoy Python.
- throwaway889900 5y agoTreating a stylistic warning as an error is completely different than a semantic error being an actual error.
- dv_dt 5y agoThis is not a reason to avoid -Werror, but a reason to approach changes in nontrivial build environments like one would approach significant changes with the software itself.
- nuerow 5y ago> This is not a reason to avoid -Werror Sorry but it really was. Passing Werror like confetti was the root cause of a problem that led to two weeks of downtime and added absolutely no value at all, and the solution consisted of addressing said warnings alone. And if there was any doubt, the upgrade was undoubtedly trivial, mainly due to the fact that the project still targeted C++11, and with exception of the Werror nonsense was absolutely flawless.
- MaulingMonkey 5y ago> and the solution consisted of addressing said warnings alone. Alternative solutions which should not have taken two weeks would've included: -Wno-inane-drivel-involving-white-spaces -Wno-error=inane-drivel-involving-white-spaces Just because you're using -Werror doesn't mean literally every single warning in the compiler ever should be a hard error. It means errors should be the default, allowing you to opt-out of stupid warnings-as-errors, rather than needing to opt-in to critical warnings-as-errors.
- Arnavion 5y agoIf the team that owned these dependencies were militant enough to enable Werror for tests, they might have also insisted that the warnings be fixed properly instead of being suppressed.
- dv_dt 5y agoI have had instances where upgrades of the compiler added bugs, or where warnings identified new potential bugs. And not always revolving around the error flags either. The update after analysis and probably some retesting concluded as trivial, but before undertaking the change I think it has a risk of having the same impact as a change of software. It’s not -Werror at the root of this general work (yes it turned that way in this specific case), but the analysis and recheck after was the core work from the compiler upgrade.