Please, no, don't use -Werror with -Wall or -Wextra. When you write your code and compile with -Werror on your old version of GCC (either because you're behind on GCC releases, or because you wrote the code in the past), and I want to compile it with my new version which has added some warnings, I don't want to have to mess around in your build configuration and remove -Werror.
Instead, do any of the following:
* Compile normally without -Werror, but have a test suite which compiles all your tests with -Werror. Make sure to only accept patches which don't break the test suite (probably using some CI system). If you don't want actual tests, a "test suite" which just makes sure `make clean && make CFLAGS=-Werror` doesn't fail would suffice.
* Use -Werror for regular builds, but enable only a fixed set of warnings, not -Wall or -Werror.
* Make your build system record warnings, and complain about them for every single build, not just the builds which happen to recompile the files which trigger warnings. This doesn't _guarantee_ that your project is warning-free like the other two do, but I imagine a lot of the reason projects end up with warnings is that people just see the warning once, and then never again until the file has to be recompiled.
I can't count the number of times I have wanted to use some project, but then had to dig through the project's Makefile or autotools m4/shell soup or gn files or meson files or cmake files or ad-hoc compile script or some other build configuration, just because my compiler is newer than the author's.
> Please, no, don't use ... when distributing your code
FTFY. It's fine to use them for development, but a major pain in the ass if you are distributing your code for others to compile (looking at you, google).
Yeah, I don't care how people or organizations actually write their code, I just want to download the code they distribute (through git or tarballs) and run the commands listed in a readme without the build failing because GCC thinks there's an unnecessary number of parentheses around an expression.
The three alternatives were meant as somthing easy one could do instead of blindly using using -Werror to achieve the same advantages, but there are of course more ways to do it.
I have also had the fortune of using Goole code. I have been meaning to write a blog post about the issues one encounters when using a Goole library without being a part of Google.
I actually don't even like -Werror for development. When I'm developing/testing/debugging, I frequently want to run partially implemented functions (a good example of this is repeatedly commenting out blocks of code to bisect a problem). Trying to deal with warnings about unused variables/parameters is extremely cumbersome.
I want to opt out of bad warnings-as-errors, rather than failing to opt into good ones. -Wall -Wextra -pedantic -Werror for me - followed by a bunch of -Wno-xyz like -Wno-unused-variable.
You could also use -Wno-error=unused-variable, but I find warnings as warnings almost completely pointless outside of extremely niche circumstances. I will lose them in a sea of other errors when a template goes awry, and after fixing that and building again the warning will disappear because the TU with said warning didn't need rebuilding.
I agree. The main place I find -Werror to be valuable is on the CI server, where you're checking that committed code compiles cleanly on your target platforms.
Absolutely not the fault of Werror. Werror is fine and a great idea. Your complaint here is crappy build systems where you can't easily adjust flags. Yeah that's garbage and so normal we sometimes accept it without thinking how utterly rubbish it is. But it's sure not Werror at fault of you update things and have trouble working out how to do something basic and trivial with the build system.
Werror forever. Don't do crappy build systems so you can do sensible things like enabling Werror.
I'm not sorry, but using a build system which makes it easy to disable -Werror doesn't help. It's still somehing everyone who wants to use your program has to figure out how to do, and if you're actually using an obscure build system (which it sounds like you're suggesting), then that's even more annoying. If everyone on the planet used one build system which had a singular way to disable -Werror you'd have a point, but that's not exactly going to happen.
It's not that it's usually _hard_ to figure out how to disable -Werror. In a correctly written Makefile, it's literally just `make CFLAGS=-Wno-error`. It's about having to figure it out at all. Don't make life annoying for every one of your users just because you're too lazy to set up your project such that builds used while developing (such as debug builds) use -Werror, while regular builds don't.
If you absolutely need every build to use -Werror, then please, just include your build system's version of `CFLAGS=-Wno-error` in your readme's compile instructions (even when using make; `CFLAGS=-Wno-error` works for _correctly written_ makefiles, which most makefiles are not.)
You've got build system Stockholm syndrome! :-) Changing a flag because you've changed compiler (or any other reason) should take no thought in the 5 seconds it takes. Any flag change. The end.
But... this isn't about my own code using my preferred build system. Of course you can quickly change any flag if you know the build system works and hiw your project uses it. It will not take 5 seconds with no though to figure out how a build system you have never used before lets you change build flags. Besides, even if it did take just 5 seconds and no thought, I wouldn't know it's necessary before I've tried to compile, maybe noticed that it will take a while because it's a big project, gone away and done something else for a bit, and returned to a failed build because one file a couple of minutes in had an unnecessary set of parentheses somewhere.
I absolutely don't understand what stockholm syndrome has to do with anything. I haven't advocated for any particular build system.
If you can change build systems flags easily, without thought, very quickly. Do you still think Werror is a bad idea?
Assuming your answer to that is the same as mine. If you always have a build system where you can change flags easily, without thought very quickly, you do use Werror. We frequently (always?) don't have such a build system and we're used to that. We're prisoners of it. It sucks. C build systems are utterly terrible. We're captured by them. Whether it's autotools, cmake, scons, a bajillion make files used directly or whatever. I think acknowledging it is reasonable. I think claiming they are other than terrible is stockholm syndrome. (Note that they may not be capable of being improved, there may be nothing better, etc etc. - I make no claims about it).
Not using a flag because it makes life hard when the compiler is upgraded and the flag needs to be changed is a build system issue. Really.
>
Please, no, don't use -Werror with -Wall or -Wextra. When you write your code and compile with -Werror on your old version of GCC (either because you're behind on GCC releases, or because you wrote the code in the past), and I want to compile it with my new version which has added some warnings, I don't want to have to mess around in your build configuration and remove -Werror.
100% disagree. If compilers add new warnings it's because they have new insights in your code, and old invalid but "working" code may not work at all in the newer version and eat your hard disk. So instead of risking your data, just accept that it won't work with this newer version of the language.
A new compiler version isn't a new version of the language. Most warnings are about completely valid code which nonetheless should be avoided. Code which was correct in an earlier version if GCC continues to be correct in new versions of GCC.
Unused variables, using `if (somevar = othervar)` instead of `if ((somevar = othervar))`, code which uses operators without parentheses where GCC has decided the operator precedence is unexpected and should have extra parentheses to be clearer, a switch which doesn't cover all the values of an enum, unnecessary parentheses in a variable declaration. Those are all warnings which absolutely don't mean that the code is broken. The author should absolutely fix new warnings like that, but that shouldn't be the responsibility of someone who just wants to use your open source project.
I agree about open source projects, then compiler options should not be so strict. But during development it might be useful; I use -Werror before releasing piece of code, just not to add any new warnings.
BTW, a few years ago we had a nasty bug (feature?), that might have been prevented when converted into error, but... "because we always have very large build logs I didn't notice the new warning." http://0x80.pl/notesen/2015-03-22-compiler-warnings.html
Instead, do any of the following:
* Compile normally without -Werror, but have a test suite which compiles all your tests with -Werror. Make sure to only accept patches which don't break the test suite (probably using some CI system). If you don't want actual tests, a "test suite" which just makes sure `make clean && make CFLAGS=-Werror` doesn't fail would suffice.
* Use -Werror for regular builds, but enable only a fixed set of warnings, not -Wall or -Werror.
* Make your build system record warnings, and complain about them for every single build, not just the builds which happen to recompile the files which trigger warnings. This doesn't _guarantee_ that your project is warning-free like the other two do, but I imagine a lot of the reason projects end up with warnings is that people just see the warning once, and then never again until the file has to be recompiled.
I can't count the number of times I have wanted to use some project, but then had to dig through the project's Makefile or autotools m4/shell soup or gn files or meson files or cmake files or ad-hoc compile script or some other build configuration, just because my compiler is newer than the author's.