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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
