<p dir="ltr">Hi!</p>
<p dir="ltr">I'll do kcompletion and kemoticons.</p>
<p dir="ltr">Cheers,</p>
<p dir="ltr">David Gil<br>
El 07/07/2014 23:39, "David Faure" <<a href="mailto:faure@kde.org">faure@kde.org</a>> escribió:<br>
><br>
> On Monday 05 May 2014 13:14:07 Alex Merry wrote:<br>
> > On 05/05/14 07:27, Matthew Dawson wrote:<br>
> > > Hi all,<br>
> > ><br>
> > > I was looking into my frameworks, to prepare them for the 5.0. One thing<br>
> > > was looking into was the deprecation defines. In KConfig, there are a<br>
> > > couple of><br>
> > > defines to disable deprecated functions:<br>
> > > - KDE_NO_DEPRECATED<br>
> ><br>
> > As you mention, this is a leftover, and not correct.<br>
><br>
> In case anyone's bored, there are still 99 files in KF5 using<br>
> KDE_NO_DEPRECATED (without counting kdelibs4support).<br>
><br>
> The affected frameworks are kcompletion, kconfig, kdewebkit, kemoticons,<br>
> kglobalaccel, khtml, kiconthemes, kio, kitemviews, kparts, kwidgetaddons and<br>
> kxmlgui....<br>
><br>
> I'll take care of kio and kparts, since I maintain these.<br>
><br>
> > > - KCONFIGCORE_NO_DEPRECATED<br>
> > > - KCONFIGGUI_NO_DEPRECATED<br>
> ><br>
> > Both of these are correct, for their respective libraries.<br>
> ><br>
> > > Where KDE_NO_DEPRECATED seems to be from kdelibs, and<br>
> > > KCONFIG*_NO_DEPRECATED are from cmake's generate_export_header function.<br>
> > > Going forward, which is considered to be the correct way to have<br>
> > > deprecated pieces of code excluded from the build?<br>
> > ><br>
> > > And: If generate_export_header is used, should all frameworks be extended<br>
> > > with a switch to easily enable/disable its deprecation exclusion defines?<br>
> ><br>
> > I suggested this a couple of months ago - you can pass an argument to<br>
> > generate_export_header to do it (which you would make dependent on an<br>
> > option). I think the general view was that it wasn't worth it<br>
> > (especially for frameworks where deprecated code is minimal or mostly<br>
> > header-only). Applications can always put the *_NO_DEPRECATED defines in<br>
> > their build scripts if they want, I guess.<br>
><br>
> Not sure I even understand the question; but looking at *_export.h, it seems<br>
> that apps can remove all deprecated APIs by setting DEFINE_NO_DEPRECATED?<br>
> Strange name (not namespaced in any way), and is it documented anywhere?<br>
><br>
> --<br>
> David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr">http://www.davidfaure.fr</a><br>
> Working on KDE Frameworks 5<br>
><br>
> _______________________________________________<br>
> Kde-frameworks-devel mailing list<br>
> <a href="mailto:Kde-frameworks-devel@kde.org">Kde-frameworks-devel@kde.org</a><br>
> <a href="https://mail.kde.org/mailman/listinfo/kde-frameworks-devel">https://mail.kde.org/mailman/listinfo/kde-frameworks-devel</a><br>
</p>