On July 7, 2014 11:39:38 PM David Faure wrote: > On Monday 05 May 2014 13:14:07 Alex Merry wrote: > > On 05/05/14 07:27, Matthew Dawson wrote: > > > Hi all, > > > > > > I was looking into my frameworks, to prepare them for the 5.0. One > > > thing > > > was looking into was the deprecation defines. In KConfig, there are a > > > couple of> > > > > > > defines to disable deprecated functions: > > > - KDE_NO_DEPRECATED > > > > As you mention, this is a leftover, and not correct. > > In case anyone's bored, there are still 99 files in KF5 using > KDE_NO_DEPRECATED (without counting kdelibs4support). > > The affected frameworks are kcompletion, kconfig, kdewebkit, kemoticons, > kglobalaccel, khtml, kiconthemes, kio, kitemviews, kparts, kwidgetaddons and > kxmlgui.... I have a patch sitting in review for kconfig. I'm waiting on a policy decision about how to handle virtuals and *NO_DEPRECATED. The policy is waiting on getting it written, and for that I'm working on getting a new contributor for helping write such documentation.
> > > - KCONFIGCORE_NO_DEPRECATED > > > - KCONFIGGUI_NO_DEPRECATED > > > > Both of these are correct, for their respective libraries. > > > > > Where KDE_NO_DEPRECATED seems to be from kdelibs, and > > > KCONFIG*_NO_DEPRECATED are from cmake's generate_export_header function. > > > Going forward, which is considered to be the correct way to have > > > deprecated pieces of code excluded from the build? > > > > > > And: If generate_export_header is used, should all frameworks be > > > extended > > > with a switch to easily enable/disable its deprecation exclusion > > > defines? > > > > I suggested this a couple of months ago - you can pass an argument to > > generate_export_header to do it (which you would make dependent on an > > option). I think the general view was that it wasn't worth it > > (especially for frameworks where deprecated code is minimal or mostly > > header-only). Applications can always put the *_NO_DEPRECATED defines in > > their build scripts if they want, I guess. > > Not sure I even understand the question; but looking at *_export.h, it seems > that apps can remove all deprecated APIs by setting DEFINE_NO_DEPRECATED? > Strange name (not namespaced in any way), and is it documented anywhere? I can't really find any documentation on it. And DEFINE_NO_DEPRECATED is defined in *export.h, so applications can't just define it and have it work (I think? Maybe it redefining doesn't work?). And it is undefined, so if you have a library compiling without, warnings appear everywhere! My Google-fu won't tell me if that is a good thing to do, or is undefined behaviour. -- Matthew
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
