Deprecation Defines

[David Faure]

On Monday 07 July 2014 15:48:26 Matthew Dawson wrote:
> 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.

What's the RR number? I can't see it in my k-f-d folder.

> 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.

Well, IMHO apps should be able to turn it on/off - so virtuals can't be marked 
with such a macro, that would be BIC. But more below.

> 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!  

No, it is defined to 0. But you're right, apps can't control it.

I see, DEFINE_NO_DEPRECATED is set by cmake if DEFINE_NO_DEPRECATED is passed 
to GENERATE_EXPORT_HEADER().

(or maybe you meant KSERVICE_NO_DEPRECATED itself is undefined, but that's 
fine, it's always tested with #ifndef -- I would have preferred this to be 
#if ! to ensure the export header is included, but we can't change that in 
cmake).

OK, I see two ways in which this could work:

1) someone wants to compile KF5 itself without deprecated stuff, to ensure 
their own apps don't use any deprecated methods. That's how cmake's 
GenerateExportHeader.cmake was written. And in that case, even virtual methods 
could be excluded. But for this we need to provide a way to pass 
DEFINE_NO_DEPRECATED to generate_export_header (like the docu suggests, with 
an option). ECM could define that option for all frameworks.

2) someone installs a "normal" KF5 (maybe even from a distro) and wants to 
ensure their app doesn't use any deprecated method. They will have to add 
things like add_definitions(-DKCONFIGCORE_NO_DEPRECATED). This sounds 
cumbersome, if one wants to set this for each and every framework they are 
using.

Historically in KDE we were doing something like solution 2 with 
KDE_NO_DEPRECATED. At some point we had something more like solution 1 with 
the "bic feature reduction and no deprecated stuff" defines in kdelibs. I tend 
to think option 2 is easier to use for app developers who don't compile their 
own KF5; but of course they can also just watch for deprecation warnings.
On the other hand, solution 1 is the one cmake provides, and is more geared 
towards "making KF5 smaller for specific use cases (e.g. mobile devices)", so 
it's potentially more useful.

As it is right now, this doesn't seem usable to me. We need to choose one of 
the two solutions and then make it work :)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5