4 ms·
And thus, every boneheaded project that ships with -Werror enabled will inflict an excrement tornado of FAIL on its grateful users and packagers. THIS IS WHY Y
by jsizz 11y ago
And thus, every boneheaded project that ships with -Werror enabled will inflict an excrement tornado of FAIL on its grateful users and packagers.
THIS IS WHY YOU SHOULD NOT USE -Werror. NOT EVER. (And if you can't bring yourself to do anything about mere warnings, you shouldn't be in software engineering.)
- tomjakubowski 11y agoFrom the article: > This new warning isn't enabled by default. And even if it were, it's a matter of adding -Wno-misleading-indentation to make builds green again. Not a big deal. And besides, it's likely that fixing those warnings could be done mechanically. (and it's hardly true that every project that ships with -Werror has such misleading indentation somewhere in its code)
- cperciva 11y agoAnd even if it were, it's a matter of adding -Wno-misleading-indentation to make builds green again How does that help the person who is building the release you shipped six months ago with a new compiler?
- legulere 11y agoYou should have -Werror enabled on debug builds when developing and disabled on release builds.
- MereInterest 11y agoHuh. I would think it to be the other way around. When debugging, let me comment stuff out without erroring due to an unused variable or an unused parameter. Let me use a C-style cast to check the bit representation of an object. Then when building the release build, enable -Werror to make sure that I'm not sweeping anything under the rug.