chehrlic added a comment.
In D23789#536338 <https://phabricator.kde.org/D23789#536338>, @kossebau wrote: > Actual questions I have: > > - why is QT_DEPRECATED_WARNINGS_SINCE not officially documented? like, any plans to change that macro to something else? Just forgot it (and also the reviewers) I would guess. There is no plan to change it, at least none I'm aware of. I'm looking for an automatic generation of this macro. Since Qt6 switches to CMake I can maybe borrow some stuff from you ;) > - why has all Qt code not yet been adapted to QT_DEPRECATED_VERSION/QT_DEPRECATED_VERSION_X, are there places where those macros should not be used, but the version-less ones? Because noone wanted to do the work and it was added late in the Qt5 lifetime -> A lot of stuff was deprecated for a long time already (in Qt4 times) and there is was a replacement since Qt5.0.0 so the macro was not needed (even though a lot of people got very angry about it). I added it for some new signals which created a lot of discussion since the old ones are widely used. > - why did you go for both QT_DEPRECATED_VERSION & QT_DEPRECATED_VERSION_X, are there places where no message will be wanted? Just for consistency - we've QT_DEPRECATED and QT_DEPRECATED_X but I think QT_DEPRECATED should be deprecated by itself. I hope no reviewer will accept a QT_DEPRECATED anymore. The main problem with the macro is that you have to create a new one for each version so it will become lengthy. But I could not find a better solution somewhere - in the end it's only macro magic from the 80s... :( But for a library such a macro should be mandatory - your blog post explains the problem very good. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D23789 To: kossebau Cc: chehrlic, dfaure, cgiboudeaux, kde-frameworks-devel, kde-buildsystem, LeGast00n, GB_2, bencreasy, michaelh, ngraham, bruns
