KConfigBase cleanup
Thomas Braxton
brax108 at cox.net
Tue Jan 10 17:25:54 GMT 2006
On Tuesday 10 January 2006 11:04, Thiago Macieira wrote:
> David Faure wrote:
> >On Tuesday 10 January 2006 17:40, Thomas Braxton wrote:
> >> I was thinking it could be defined something like:
> >> #ifndef KDE3_SUPPORT
> >> #define KDE3_EXPORT KDE_NO_EXPORT // or KDE_DEPRECATED or a
> >> combination #else
> >> #define KDE3_EXPORT KDE_EXPORT
> >> #endif
> >> then I could move all of the functions that are still in KConfigBase
> >> for KDE3 support to kde3support.
> >
> >Well at least the definition (.h) of those methods would have to remain
> > in the class, so why not the code too? This is what Qt does, too -
> > libqt3support is only for entire classes, not for single methods.
>
> Which in turn means the whole kdelibs must be built with KDE3 + Qt3
> support enabled.
Only the parts that still use something from KDE3, as soon as it is ported the
define could be dropped from the compile flags. I envision something like
this:
add -DKDE3_SUPPORT -lkde3support for all modules
as the files get ported the porter could add
#ifdef KDE3_SUPPORT
#undef KDE3_SUPPORT
#include <k....h> for all classes that are ported
#define KDE3_SUPPORT
#endif
#include <k....h> for all classes that are not ported yet
at the top of the source. When there are no more KDE includes outside of the
ifdef block, just leave
#undef KDE3_SUPPORT
at the top of the source file. When this is done for all source files then
remove -DKDE3_SUPPORT -lkde3support. It would make it very easy to tell which
files have been ported and which haven't. When KDE3_EXPORT is no longer
needed all the functions marked with it could be removed, then it could be
removed.
Thomas
More information about the kde-core-devel
mailing list