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

[Christian Ehrlicher]

chehrlic added a comment.


  In D23789#538985 <https://phabricator.kde.org/D23789#538985>, @kossebau wrote:
  
  > >> - 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.
  >
  > Can you point to those discussions? Would be curious to learn what people's thought are.
  
  
  https://lists.qt-project.org/pipermail/development/2019-March/035343.html
  
  It's most likely a discussion when a deprecated / replaced function should really create a warning (esp. when the replacement was just recently added) and when the function should be removed completely - should a function deprecated in Qt5 really be removed in Qt6 or wait for Qt7 or don't remove it at all.
  
  > 
  > 
  >>> - 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.
  > 
  > So you would also think that message-less variants will not be needed I understand. Okay. From what I tested with experimentally deploying the macros on some KF modules I almost always could add a useful message, so running short of reasons for keeping a message-less variant :)
  
  I think it should be enough to have one macro nowadays :)

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-buildsystem/attachments/20190928/da0ef00e/attachment.html>