KDE/kdelibs/kdeui
Peter Kümmel
syntheticpp at gmx.net
Sat Mar 11 13:23:08 GMT 2006
Thiago Macieira wrote:
> You'll notice that QT3_SUPPORT is used everywhere throughout
> Qt{Core,Gui,Xml,Network} between the modifier and the return type. But
> it's defined to be empty unless QT3_SUPPORT_WARNINGS is defined.
>
> The same goes for QT_COMPAT and QT_COMPAT_WARNINGS.
>
Ok, now it's clear.
>> my problem was that kdemacros.h does not include qglobal.h so all
>> all the qt macros are unknown and the disabling in case of msvc
>> does not work:
>
> It should include QtCore/qglobal.h.
>
Including qglobal.h was not a good idea of me, it's not necessary
when we don't test on qt macros.
> And, as I said in other emails, we should define our own
> KDE_DEPRECATED_WARNINGS to turn it on and off.
>
Yes, this is a good idea, and should solve all the problems.
(but it's not possible to remove all deprecated functions,
like it could be done with Brad's approach)
Moving to this code as following implications
(with the currebt svn code):
- deprecated warning are disabled by default
- when enabling gcc has no problems, but msvc build is broken
but a soft migration is still possible (by disabling)
Sometimes we could enable the warnings by default, at least in kdelibs.
Do we still need more discussion on it?
> Developers should use a recent compiler and turn that warning on when
> writing their application, but it should not be on by default. Just like
> in Qt.
>
More information about the kde-core-devel
mailing list