Deprecation Defines

[Matthew Dawson]

On July 8, 2014 11:20:37 AM David Faure wrote:
> > 
> > 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.
118489.  It already has comments on it, with the decision that policy needs to 
be figured out before it is pushed.

> 
> > 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 meant that if some libraries enable DEFINE_NO_DEPRECATED, and some do not, 
the compiler will complain about redefining DEFINE_NO_DEPRECATED.  I can't 
tell if that is actually legal either.

> 
> 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 :)
I agree.  I figured the first step was to come up with a draft policy and post 
to the list for comments, and as I said I'm trying to get a new contributer to 
help (they have lots of experience writing documents, and have a strong 
technical background).  Time, as always, limited our ability to get it 
written.


I don't see option 1) being usable without fixing cmake to avoid the 
redefining warnings (though I imagine that is a small task).  Also, I don't 
think any general purpose distribution would enable it, as that option would 
break SC and BC anytime new deprecated features are added.  For single purpose 
devices, it's not a problem.  But single purpose devices are rapidly 
shrinking.

Option 2 definitely has its uses, but as you say deprecation warning should 
take care of that.  Come to think of it, one problem with option 2 is that 
developers may enable that in their production build scripts, and thus with a 
new release of KF5 deprecating new behaviour, will break old applications.
-- 
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/20140708/5a3ddb56/attachment.p7s>