Deprecation Defines

[Alex Merry]

On Tuesday 08 July 2014 14:03:31 Matthew Dawson wrote:
> On July 8, 2014 10:50:18 PM David Faure wrote:
> > But yeah, the Qt solution with version-specific deprecation
> > (QT_DEPRECATED_SINCE) is much better, we should adopt something like that.
> > This way, you can ensure your code keeps compiling "without the stuff that
> > was deprecated in 5.1", without getting a compilation error if someone
> > suddenly installs KF 5.2 which deprecated new stuff. This means not using
> > the stuff currently in cmake then, but something more evolved based on the
> > project's version number...
> 
> QT_DEPRECATED_SINCE would erase my complaint, as the new deprecations won't
> disappear on the application.

I like this DEPRECATED_SINCE idea. We could have two versions of the wrapping 
macro, one for stuff that's BC to hide (ie: no virtuals or class data members), 
and one for stuff that's BIC. The former could be controlled by an application-
set macro, while the latter would be controlled by the framework's build 
options.

Alex