On 29/03/17 12:09 +0100, Tomasz Kloczko wrote:
For some reason you email landed in my spam folder :)
On Wed, 2017-03-29 at 10:15 +0100, Jonathan Wakely wrote:
On 19/03/17 03:33 +0000, Tomasz Kłoczko wrote:
> Started cleaning parted.spec and found method *much* more often used.
>
> [tkloczko@domek SPECS.fedora]$ grep CFLAGS * | grep -- -Wno
> alex4.spec: CFLAGS="$RPM_OPT_FLAGS *-Wno*-deprecated-declarations"
There's nothing wrong with this option. Many C++ packages want to
support building with a C++98 compiler, so they use std::auto_ptr.
That gives warnings when built with a modern GCC using default
settings. Disabling the warning is reasonable.
Generally you are right. However you cannot fix something if you don't know that some issue with code exist :)
What I'm trying to tell is that as long as suppressing such warnings is hard coded in spec files it decreases probability of fixing the
code.
And my point is the code doesn't need fixing. "Fixing" code to stop
using std::auto_ptr usually means replacing it with std::unique_ptr,
which will break that code if it's supposed to build with a C++98
compiler.
Packages build logs are preserved and served publicly.
Number of all compile warnings says something as well about general "heal"s of the source code.
Not all compiler warnings are equal.
> xscreensaver.spec:export CFLAGS="$CFLAGS *-Wno*-long-long"
> xscreensaver.spec:export CFLAGS="$CFLAGS *-Wno*-variadic-macros"
These are harmless to disable, but also redundant. Fedora's GCC
defaults to C11 which supports long long and variadic macros, so won't
warn about them anyway.
Not everything in your report is a problem. Automatically emailing
somebody from upstream or refusing to allow those -Wno-* options in
spec files would not improve Fedora measurably.
Please "#define problem". No one here is talking about any problems per se.
Does it mean that enable reporting compile warnings is changing the code? Of course not.
Does it mean that enable suppressing those warnings allows make somehow "faulty" code better in the future? Of course as well not.
And that is the issue that full viability of those warnings only makes build logs slightly shorter and nothing more.
It does not help in anything .. do you see this now?
BTW xscreensaver is perfect example code which public interest of maintaining its source code is declining because some undergoing X11-
Wayland changes.
As gcc is constantly progressing with reporting some type of more of less potential issues as warnings there is no to many people
interested in maintaining code which maintenance stagnates.
If package like xscreensaver in the future will start producing come compile/linking time errors something like number of warnings may
help make decision about final abandon such package.
I'm not talking about new warnings added by GCC (I've been working on
GCC for about 15 years, you can assume I know how it works).
I was talking about specific warnings from your report, pointing out
they are not indicative of problems in the code.
-Wlong-long and -Wvariadic-macros are not new warnings, and don't tell
you you're doing something risky. Disabling those warnings because you
are intentionally relying on GNU extensions of C99 features is
harmless.
Turning off *all* warnings would be concerning, and could help make a
decision about retiring a package. But turning off these specific
warnings is not concerning.
Not all compiler warnings are equal.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
