3 ms·
The alternative is to fix warnings! You don't have to completely fail the build, to have the good engineering sense to fix warnings. Unless you never build loc
by ploxiln 3y ago
The alternative is to fix warnings! You don't have to completely fail the build, to have the good engineering sense to fix warnings.
Unless you never build locally? And never look at a build log? You really never improve code if Werror doesn't force you to?
It's really obnoxious to also immediately and completely fail the build for someone who wants to use an updated compiler, or wants to compile for a different architecture, or wants to compare to an older compiler, or a different vendor's compiler, or test with and updated library with changed headers, or ...
- not2b 3y agoTurning on -Werror means that once the warnings are eliminated, they stay eliminated, and a developer who adds code that produces a warning has their checkin rejected. If it isn't used the number of warnings will just grow and grow. You're right, updated compilers that have more warnings are an issue, and that's why the document recommends that -Werror be used during development but not in the shipped code (for open source projects), so the recipient of the code isn't blocked by the problem you cite.
- account42 3y ago> If it isn't used the number of warnings will just grow and grow. Only in shitty teams without discipline and only if warnings are not tracked in some other way.
- not2b 3y agoThe way to impose discipline effectively is to have automated checks. Like -Werror, and additional "lint"-style checks to make sure that coding guidelnes are followed. Non-shitty teams automate as much of the flow as possible, to catch mistakes early and help the human reviewers catch everything.
- pjmlp 3y agoMost companies have such teams, fortunate of those that never experienced such employers.