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

[Friedrich W. H. Kossebau]

kossebau added a comment.


  Thanks for your reply, Christian :)
  
  In D23789#538876 <https://phabricator.kde.org/D23789#538876>, @chehrlic wrote:
  
  > 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.
  
  
  Okay. So will keep it documented as part of public API here then.
  
  > Since Qt6 switches to CMake I can maybe borrow some stuff from you ;)
  
  Sure :) As others commented and what I think as well, this should be even candidate for being added to upstream in some variant, once it has proven to work out.
  
  >> - 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.
  
  >> - 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 :)
  
  > 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... :(
  
  Also had no better idea, but then I am also nowhere a C++ macro magician, I operate by manual mostly :) Thankfully with the proposed cmake-generated approach here it's more a matter of adding another version to the `DEPRECATION_VERSIONS` list, and nobody looks into generated code anyway.

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/936dbbf3/attachment.html>