D25589: ECMGenerateExportHeader: add NO_BUILD_SET_DEPRECATED_WARNINGS_SINCE flag

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D25589#570375 <https://phabricator.kde.org/D25589#570375>, @dfaure wrote:
  
  > My head hurts a bit but I think I understand this now ;)
  
  
  Indeed, this gets more & more complex, I hope in time for ECM6 there are enough samples collected from real-world usage to trim down things a bit again, to match known usage pattern with some simple setup options again. For now it's still try & error phase I guess, at least I still meet new constellations every week I had not thought of when initially designing this.
  
  > I'm not sure what's the use case for disabling this though? (I'm wondering the same about the existing NO_DEFINITION_EXPORT_TO_BUILD_INTERFACE)
  
  With some non-KDE projects I experimented this with, having control to disable the setting or build-internal export of these flags was needed.
  E.g. in  some the examples wanted to have all deprecated API be invisible, to make sure examples only demonstrate latest non-deprecated API. So the exported flags were not wanted, instead are explicitly set per tests & examples.
  In others deprecated API was more separate and should not be used from other parts, so having a global deprecation warning/visibility flag by default got in the way, where instead deprecation warnings/visibility trigger is individually configured per file (warnings vs. visibiity to allow smooth porting in the library).

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  NO_BUILD_SET_DEPRECATED_WARNINGS_SINCE

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

To: kossebau, #build_system, #frameworks, dfaure
Cc: 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/20191201/876ee1d7/attachment.html>