Yes exactly. For example GNU coreutils auto enables -Werror for devs when running from a git repo, whereas tarball releases do not add that option. See:
I agree whole heartedly. When I'm programming I typically want most things that would cause a warning to stop me in my tracks. However I cannot count the number of times I've been trying to build someone else's code and the configuration uses -Werror and things that didn't raise a warning on their version of gcc or clang do on mine and now I've got to fix possibly dozens of not actual errors.
It's not scalable for you either. If everything becomes an error, you can't go a single day without fixing it and everything the compiler + your dependencies - aka, just some other people you've never met - complains about.
In particular if you update a library and they deprecate some functions, -Wdeprecated will start emitting some warnings, which are now errors. Do you think you can fix that in a day? It could take months to fix something that's literally not a problem yet.
By the way, I couldn't build MariaDB on this one machine because some plugin we don't use has -Werror set and fails with obscure C++ nonsense.
> In particular if you update a library and they deprecate some functions, -Wdeprecated will start emitting some warnings, which are now errors. Do you think you can fix that in a day? It could take months to fix something that's literally not a problem yet.
It doesn't take months to add -Wno-deprecated to a Makefile.
> It doesn't take months to add -Wno-deprecated to a Makefile.
After which you no longer have any visibility on what deprecated fxns you're calling, which means one day updating that library again is going to completely block you until you rework your interface.
Enable -Werror in debug builds, disable it in production builds (in publicly released builds).
Reason: -Werror is helpful for you, useless for a 3rd party.