D24979: KRunner: port away from deprecated KF5 API

Friedrich W. H. Kossebau noreply at phabricator.kde.org
Sun Oct 27 18:05:13 GMT 2019


kossebau requested changes to this revision.
kossebau added a comment.
This revision now requires changes to proceed.


  One of the Interesting challenges with all the cross-library deprecation visibility control setup.
  
  Let me try to collect requirements:
  
  - Plasma::Package is part of ABI of Plasma API, cannot be removed in normal builds, only made optionally invisible in API when building against
  - Plasma::Package is part of ABI of KRunner API, cannot be removed in normal builds, only made optionally invisible in API when building against
  - if Plasma::Package is made invisible with Plasma API, it also needs to be invisible with KRunner API
  
  Current patch as proposed  has an issue for build time of KRunner itself, because KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x053f00 results in PLASMA_ENABLE_DEPRECATED_SINCE(5, 28) evaluating to FALSE during the build of KRunner. Which means,the symbol for AbstractRunner::package() will be missing and thus ABI being broken -> not allowed.
  
  At the same time #if PLASMA_ENABLE_DEPRECATED_SINCE(5, 28) with the declaration in the header is needed indeed, as Plasma::Package is only visible to the compiler with this condition, and given consumers of KRunner API have control over that we need to handle it.
  
  So, KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x053f00 is not possibly in total with KRunner, as its required implementation code has a hard dependency on Plasma API deprecated before that.
  Two options:
  a) set the module specific PLASMA_DISABLE_DEPRECATED_BEFORE_AND_AT=0x050500 to override the default from the group KF one
  b) remove visibility wrappers around  originalPlasma::Package API
  
  I personally favour a) here.
  
  Given we have officially deprecated API in KRunner, it should indeed also get ported to ecm_generate_export_header. I would have now done this myself, but actually would like to see other people are easily able to use that macro API, so it's not just something compatible to my state of brain ;)

REPOSITORY
  R308 KRunner

REVISION DETAIL
  https://phabricator.kde.org/D24979

To: dfaure, kossebau, mart, apol
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191027/cbcb1278/attachment.html>


More information about the Kde-frameworks-devel mailing list