Misuse of warnings-as-errors?
I’m pretty new to boost, but I’m sensing a desire to have cake and eat it too … correct me if I’m wrong of course! I see several places in the bug tracking system where people complain about compiler warnings and are told that fixing that sort of thing is completely ridiculous and the bugs are closed as “won't fix”. But then warnings-as-errors is enabled in several places – libs/pool/test, libs/type_traits/test, libs/units/test, etc. Shouldn’t boost have one or the other? Either warnings are important enough to treat them as errors in the unit tests (in which case they should get fixed) or else they’re not that important and warnings-as-errors shouldn’t be enabled by default anywhere? Thanks, Chris
On Thursday 01 May 2014 16:23:48 Chris Cooper wrote:
I’m pretty new to boost, but I’m sensing a desire to have cake and eat it too … correct me if I’m wrong of course!
I see several places in the bug tracking system where people complain about compiler warnings and are told that fixing that sort of thing is completely ridiculous and the bugs are closed as “won't fix”.
But then warnings-as-errors is enabled in several places – libs/pool/test, libs/type_traits/test, libs/units/test, etc.
Shouldn’t boost have one or the other? Either warnings are important enough to treat them as errors in the unit tests (in which case they should get fixed) or else they’re not that important and warnings-as-errors shouldn’t be enabled by default anywhere?
This is basically each library's choice, there's no common requirement. Personally I think that trying to work around all warnings in code is a rather pointless and even detrimental thing to do.
On 01/05/14 18:34, Andrey Semashev wrote:
On Thursday 01 May 2014 16:23:48 Chris Cooper wrote:
I’m pretty new to boost, but I’m sensing a desire to have cake and eat it too … correct me if I’m wrong of course!
I see several places in the bug tracking system where people complain about compiler warnings and are told that fixing that sort of thing is completely ridiculous and the bugs are closed as “won't fix”.
But then warnings-as-errors is enabled in several places – libs/pool/test, libs/type_traits/test, libs/units/test, etc.
Shouldn’t boost have one or the other? Either warnings are important enough to treat them as errors in the unit tests (in which case they should get fixed) or else they’re not that important and warnings-as-errors shouldn’t be enabled by default anywhere?
This is basically each library's choice, there's no common requirement. Personally I think that trying to work around all warnings in code is a rather pointless and even detrimental thing to do.
Every library author should make a reasonable attempt that correct code involving usage of their library does not generate warnings.
On 1 May 2014 17:23, Chris Cooper wrote:
Shouldn’t boost have one or the other?
Why?
Either warnings are important enough to treat them as errors in the unit tests (in which case they should get fixed) or else they’re not that important and warnings-as-errors shouldn’t be enabled by default anywhere?
I think that's a false dichotomy. If a particular library does compile warning-free, whether because it's the intention of that library's maintainer or by chance, your view seems to be that it must not be allowed to use -Werror because some other libraries can't or won't or just don't use it.
I’m pretty new to boost, but I’m sensing a desire to have cake and eat it too … correct me if I’m wrong of course!
I see several places in the bug tracking system where people complain about compiler warnings and are told that fixing that sort of thing is completely ridiculous and the bugs are closed as “won't fix”.
But then warnings-as-errors is enabled in several places – libs/pool/test, libs/type_traits/test, libs/units/test, etc.
Shouldn’t boost have one or the other? Either warnings are important enough to treat them as errors in the unit tests (in which case they should get fixed) or else they’re not that important and warnings-as-errors shouldn’t be enabled by default anywhere?
Personally, I like my stuff to be warning free, and in something as "core" as type_traits, any warning at all can be a real pain that gets repeated dozens of times each with 10 pages of instantiation back-trace, so I think it makes sense to enforce a no-warnings policy in that one case. In other libraries, and in particular if they have dependencies on other Boost libraries (even just testing dependencies) then trying to enforce a no-warning policy is probably a road to perdition. John.
On May 1, 2014 12:52:51 PM EDT, John Maddock <boost.regex@virgin.net> wrote:
I see several places in the bug tracking system where people complain
about compiler warnings and are told that fixing that sort of thing is completely ridiculous and the bugs are closed as “won't fix”.
But then warnings-as-errors is enabled in several places –
libs/pool/test, libs/type_traits/test, libs/units/test, etc.
Shouldn’t boost have one or the other?
Personally, I like my stuff to be warning free, and in something as "core" as type_traits, any warning at all can be a real pain that gets repeated dozens of times each with 10 pages of instantiation back-trace, so I think it makes sense to enforce a no-warnings policy in that one case.
+1 ___ Rob (Sent from my portable computation engine)
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Chris Cooper Sent: 01 May 2014 17:24 To: boost@lists.boost.org Subject: [boost] Misuse of warnings-as-errors?
I'm pretty new to boost, but I'm sensing a desire to have cake and eat it too . correct me if I'm wrong of course!
I see several places in the bug tracking system where people complain about compiler warnings and are told that fixing that sort of thing is completely ridiculous and the bugs are closed as "won't fix".
But then warnings-as-errors is enabled in several places - libs/pool/test, libs/type_traits/test, libs/units/test, etc.
Shouldn't boost have one or the other? Either warnings are important enough to treat them as errors in the unit tests (in which case they should get fixed) or else they're not that important and warnings-as-errors shouldn't be enabled by default anywhere?
In an ideal world yes, blizzards of warnings are a PITA, but ... It often is isn't that simple, and a thankless task. https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines I think the consensus is that if you enforce warnings-as-errors, then you are on your own. You may be able to do it, but if not, then tough. We did our best but ... Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830
participants (7)
-
Andrey Semashev -
Chris Cooper -
John Maddock -
Jonathan Wakely -
Mathias Gaunard -
Paul A. Bristow -
Rob Stewart