"-Wall -Wextra -Werror" are you allies :)
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.
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).
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.
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.
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.)
I absolutely don't understand what stockholm syndrome has to do with anything. I haven't advocated for any particular build system.
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.
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.
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.
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
-Wall -Wextra -Werror=return-type
I've actually had some pieces of code where it was super useful to enable that padding warning as an error. Some complicated C++ types that needed to have identical memory layouts across compilers yet often weren't because of some really nasty shenanigans...
-Weverything is for people who really want to explicitly opt out of every warning they don't like.