D25589: ECMGenerateExportHeader: add NO_BUILD_SET_DEPRECATED_WARNINGS_SINCE flag
Friedrich W. H. Kossebau
noreply at phabricator.kde.org
Sun Dec 1 23:04:15 GMT 2019
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-buildsystem/attachments/20191201/876ee1d7/attachment.html>
More information about the Kde-buildsystem
mailing list