D23789: RFC: Add ECMGenerateExportHeaders, for improved handling of deprecated API

[Christian Ehrlicher]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190927/d0a05960/attachment.html>