headers
Stephan Kulow | 1 Nov 2005 09:58
Picon
Favicon
Gravatar

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Monday 31 October 2005 22:34, Frans Englich wrote:
> The world is way too complex, someone should rewrite it. I who thought it
> was even worth a try to clean up kdelibs and freeze it with -Werror :(

Sure it is, but that does not mean you should commit the flag. Most warnings I 
leave in the code are reminders on someone else to pick it up. Like we have
tons of unused name arguments - that are there to be removed. But if someone
will compile with -Werror, he will take the easy way out and remove the 
parameter name so that gcc shuts up. That's not the purpose, but that's what 
happening if you compile with -Werror.

And SUSE had to remove -Werror from all well intended KDE packages because
gcc4 decided Qt needs way more virtual destructors and warns about it in -Wall
now. Just too bad that adding them to Qt3 is binary incompatible. So good bye
-Werror

Greetings, Stephan
Permalink | Reply | 6 comments |
headers
Ralf Habacker | 1 Nov 2005 11:44
Picon
Favicon
Gravatar

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

Am Montag, 31. Oktober 2005 23:29 schrieb Martijn Klingens:
> On Monday 31 October 2005 23:24, Michael Pyne wrote:
> > Well the idea is that all of the warnings would be fixed between all of
> > the compilers.  i.e. the union of all warning flags would be fixed.  This
> > may be unrealistic but then again I haven't heard of compilers removing
> > perfectly good warnings so that really shouldn't be an issue.
>
> In my experience it only works locally. I used to build Kopete with -Werror
> for a while, but that's not a flag one should commit.
>
> An easy way to enable it for certain directories without having to touch
> files under revision control would be a nice gimmick for the new build
> system, but barring that you can always manually edit the generated
> Makefiles, or at least with the KDE 3.x build system you can.

Is somebody there who can make a summary/basis proposal how this could done 
for further discussions ? 

Ralf
Permalink | Reply | 0 comments |
headers
Martijn Klingens | 1 Nov 2005 13:26
Picon
Favicon

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 09:58, Stephan Kulow wrote:
> And SUSE had to remove -Werror from all well intended KDE packages because
> gcc4 decided Qt needs way more virtual destructors and warns about it in
> -Wall now. Just too bad that adding them to Qt3 is binary incompatible. So
> good bye -Werror

Doesn't it work if you patch the failing Qt includes with '#pragma GCC 
system_header'? AFAICS that shouldn't affect BC and should suppress the 
warnings and hence the -Werror traps.

See http://gcc.gnu.org/onlinedocs/gcc-3.2.3/cpp/Pragmas.html

--

-- 
Martijn
Permalink | Reply | 4 comments |
headers
Stephan Kulow | 1 Nov 2005 13:32
Picon
Favicon
Gravatar

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 13:26, Martijn Klingens wrote:
> On Tuesday 01 November 2005 09:58, Stephan Kulow wrote:
> > And SUSE had to remove -Werror from all well intended KDE packages
> > because gcc4 decided Qt needs way more virtual destructors and warns
> > about it in -Wall now. Just too bad that adding them to Qt3 is binary
> > incompatible. So good bye -Werror
>
> Doesn't it work if you patch the failing Qt includes with '#pragma GCC
> system_header'? AFAICS that shouldn't affect BC and should suppress the
> warnings and hence the -Werror traps.
>
Yeah, that's the kind of work arounds I talked about - qt-copy has the patch
from SUSE though.

Greetings, Stephan
Permalink | Reply | 0 comments |
headers
Mirko Boehm | 1 Nov 2005 14:29
Picon
Favicon
Gravatar

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Monday 31 October 2005 16:11, Frans Englich wrote:
> I think it would be cool if for for example kdelibs, once the Qt port is
> over, that the compilation was made more strict, that the code gradually
> compiled with more warning flags. In cases where global enabled warnings
> can't be used, such as including C headers, compiling Bison parsers and
> similar, the warnings can be disabled locally with -W-no-*.
>
> GCC's warnings are for the most time valid and AFAICT everyone agrees that
> they shouldn't be there -- but no one cares enough for fixing it. Thus,
> adding "-Werror" and other options would raise the bar for what goes in and
> increase the general "tidyness". Just a thought.
The one problem I see is that if "pedantic" is turned on, we get lots of 
warning messages from source code we do not have under our own control. I 
would definitly like to be able to disable such warning for certain include 
files, for example. 

From what I know, gcc does not have a #pragma disable... to put around include 
statements. 

Is there a solution to this problem?

--Mirko.
--

-- 
KDE e.V.: http://ev.kde.org
Permalink | Reply | 2 comments |
headers
Mirko Boehm | 1 Nov 2005 14:34
Picon
Favicon
Gravatar

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Monday 31 October 2005 23:15, Nicolas Goutte wrote:
> > I would
> > say that no release tarball should contain -Werror.  It may be useful
> > during development but it would be unnecessarily painful for release.
>
> ... so you cannot even have it in development, except if everybody would
> use the same gcc version.
Why not? It can be used as a standard during development, and removed before 
the release. 

On the other hand, I do not see the point. Removing annoying "unused 
parameter" warnings should be a habit, no need to make the compiler barf at 
the first point where it encounters it. What is wrong with letting make 
finish the compile, and then removing all the warnings at once?

Forcing -Werror is too much of an annoyance, I think.

--Mirko.
--

-- 
KDE e.V.: http://ev.kde.org
Permalink | Reply | 3 comments |
headers
George Staikos | 1 Nov 2005 15:59
Picon
Favicon

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 08:34, Mirko Boehm wrote:
> On Monday 31 October 2005 23:15, Nicolas Goutte wrote:
> > > I would
> > > say that no release tarball should contain -Werror.  It may be useful
> > > during development but it would be unnecessarily painful for release.
> >
> > ... so you cannot even have it in development, except if everybody would
> > use the same gcc version.
>
> Why not? It can be used as a standard during development, and removed
> before the release.
>
> On the other hand, I do not see the point. Removing annoying "unused
> parameter" warnings should be a habit, no need to make the compiler barf at
> the first point where it encounters it. What is wrong with letting make
> finish the compile, and then removing all the warnings at once?

  I use unused parameter warnings as a form of TODO.  If there is meaning to 
have them not used, they get Q_UNUSED.  If they will be used at some point 
and that code just isn't implemented, I don't touch them so I remember to fix 
it.

> Forcing -Werror is too much of an annoyance, I think.

  I definitely agree.

--

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mirko Boehm | 1 Nov 2005 14:54
Picon
Favicon
Gravatar

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 14:29, Mirko Boehm wrote:
> From what I know, gcc does not have a #pragma disable... to put around
> include statements.
I meanwhile stumbled over #pragma GCC system_header and (what I consider the 
better solution) -isystem to declare system include directory. -isystem 
replaces a -I.. declaration, with the difference that files in those 
directories do not generated warnings. 

That should solve one major annoyance right today :-)

--Mirko.
--

-- 
KDE e.V.: http://ev.kde.org
Permalink | Reply | 1 comment |
headers
Martijn Klingens | 1 Nov 2005 16:16
Picon
Favicon

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 14:54, Mirko Boehm wrote:
> I meanwhile stumbled over #pragma GCC system_header and (what I consider
> the better solution) -isystem to declare system include directory. -isystem
> replaces a -I.. declaration, with the difference that files in those
> directories do not generated warnings.

-isystem is interesting indeed. However, how do you use it in practice? AFAICS 
it requires fiddling with the build system to replace '-I $QTDIR/include' 
with '-isystem $QTDIR/include'.

Do you know 1. whether this can be enabled unconditionally in SVN and 2. if 
not, how it can be enabled locally?

--

-- 
Martijn
Permalink | Reply | 0 comments |
headers
Frans Englich | 1 Nov 2005 17:04
Picon

Re: RFC: Avoiding #warning (C/C++ preprocessor extension)

On Tuesday 01 November 2005 13:34, Mirko Boehm wrote:
> On Monday 31 October 2005 23:15, Nicolas Goutte wrote:
> > > I would
> > > say that no release tarball should contain -Werror.  It may be useful
> > > during development but it would be unnecessarily painful for release.
> >
> > ... so you cannot even have it in development, except if everybody would
> > use the same gcc version.
>
> Why not? It can be used as a standard during development, and removed
> before the release.
>
> On the other hand, I do not see the point. Removing annoying "unused
> parameter" warnings should be a habit, no need to make the compiler barf at
> the first point where it encounters it. What is wrong with letting make
> finish the compile, and then removing all the warnings at once?

If you ask me: absolutely nothing. The problem, as I see it, is that no one do 
that final check. Old warnings stays for ages -- "someone else is supposed to 
fix that". Thus, in order to have it done at all, one have put it directly in 
front of developers such that untidy code can't end up in the repository in 
the first place.

Applying the hypothetical "-Werror at development but not release time" would 
no doubt make the code more tidy. Apparently, that people would have to fix 
warnings "now" instead of "later" is too much work, and not worth the 
improvement it in general would mean.

Quoting: "Removing annoying 'unused parameter' warnings should be a habit". I 
think a good habit is doing it right now, when it is introduced. I think "I
(Continue reading)

Permalink | Reply | 0 comments |

Gmane