Deprecation Defines

[Matthew Dawson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3885 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140707/3f3bc754/attachment.p7s>