it depends on the promises the maintainer makes to themselves and to their users. I'd rather break the build and get immediately alerted by (hopefully moderately) upset downstream packagers than having this warning become visible in my users builds.
It isn't just about getting rid of a warning, but the new compiler has changed some important logic so this warning might highlight potentially undefined behavior. Am I, the maintainer OK with that - that is the main question I believe.
Might be useful to do regression with any new compiler being released especially when a product is used in safety or security critical systems.
-std=c17 -lm
Do you know of a way to get rpmbuild to keep the -ffat-lto-objects in the ar libs?
The only way to ensure discipline and rid a large code base of warnings is to use -Werror
It may sound drastic until you're the poor intern that needs to refactor an active codebase with thousands of warning. Other than the technical debt it creates you're setting yourself up for having serious issue slipping through in all the noise.
"But some warnings might be false positives" ?
If one really must override the behavior it should be done explicitly and with a strong justification. This is possible either with a pragma[1]
#pragma GCC diagnostic ignored "-Wfoo"
-Wno-foo
[2] https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Warning-Options...
And this works as long as everybody has the same setup as you. This is unfortunately never the case. Kernel changes, libc changes, the compiler changes and sooner or later you will break the build.
Many replies seem to imply open source by default. Of course projects may have specific requirements, and open source is indeed a specific use case, but the majority of software is commercial, closed source.
Regarding compiler versions, many projects I worked on actually check that during the build because the code may only have been designed for or tested against a specific compiler/compiler version. In general upgrading the version of the compiler is an activity in itself because, indeed, this may require solving new warnings/compilation issues and a full test campaign.
That may be true for 'end user applications', but definitely not for libraries (thankfully). I use exactly zero closed source (precompiled) dependencies in my hobby and professional work because they are such pain to work with. Thankfully these days there's an open source alternative for pretty much everything, 15 years ago the situation was much more dire.
But when I look at the tools and applications I use daily, there's only two important applications that are closed source: VSCode and Chrome (and even this is debatable because both of those tools are just thin wrappers around Chromium: https://chromium.googlesource.com/chromium/src.git).
That doesn't prevent the compiler from expanding an existing warning, but that seems to break code less often than a blanket `-Werror`.
Hard disagree. No warnings means CI should fail (or otherwise scream loudly), not every build of your in-progress working tree. You can add a commit hook if you want but if it needs to be enforced then it isn't really discipline.
Even for CI you probably don't want -Werror but instead run the build completely so that you can track all warnings.
And for source released to others -Werror is downright rude as you have no idea what warnings their possible future compiler will have.
That might sound drastic but that in fact enforces discipline and the removal of warnings and is IMHO very good practice especially if you start doing that from day one.
For legacy projects this can be a goal after an comprehensive phase of warnings removal.
I've worked of projects with and without "all warnings as errors" and ultimately it is well worth it.