RFC: Avoiding #warning (C/C++ preprocessor extension)
frans.englich at telia.com
Tue Nov 1 16:22:41 GMT 2005
On Tuesday 01 November 2005 08:58, Stephan Kulow wrote:
> 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.
Yes, that's counterproductive. I'd say that the current state of trunk, these
large refactorings, are exceptional circumstances which, yes, -Werror doesn't
work for. I think that's ok, just as it's ok to commit code that introduce
temporary test regressions, as cause of a large overhaul/rewrite.
However, "if someone will compile with -Werror, he will take the easy way out
and remove the parameter name so that gcc shuts up" wouldn't occur in the
normal case, because overhauls wouldn't be necessary -- each change going in
would be an atomic, clean commit, introducing no warnings. Assuming -Werror
was a good idea overall, that is.
> 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
Yupp :} to quote Mark Mitchell:
"The set of places we warn is moving around from 3.4 to 4.0 to 4.1,
which annoys people using -Werror"
All this legacy/portage/compiler complexity is a shame, as usual.
More information about the kde-core-devel