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
