Details
- Reviewers
apol dfaure - Group Reviewers
Frameworks Build System - Commits
- R240:879769daf047: KDEFrameworkCompilerSettings: enable all Qt % KF deprecation warnings
Diff Detail
- Repository
- R240 Extra CMake Modules
- Branch
- enableallqtkfdeprecationwarningsforframeworks
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 18238 Build 18256: arc lint + arc unit
@dfaure Hi. Any chance you you can sneak in before you are away (enjoy :) ) to remove the "-DQT_DEPRECATED_WARNINGS_SINCE=0x060000" from all the KF modules in the next days? Otherwise would land this here with just the -DKF_DEPRECATED_WARNINGS_SINCE=0x060000 for now, otherwise people do not see warnings in KF modules when they should.
I sadly have no setup for easy mass removal of "-DQT_DEPRECATED_WARNINGS_SINCE=0x060000" from all KF modules,otherwise I would have done that
Cmp. also https://mail.kde.org/pipermail/kde-frameworks-devel/2019-October/096307.html
Hm, only noticed now that this actually has an unwanted sideeffects: it triggers deprecation warnings for all deprecated warning also inside each library itself. Which is not what one wants.
Because so far FOO_DISABLE_DEPRECATED_BEFORE_AND_AT as set while building library FOO defaults FOO_DEPRECATED_WARNINGS_SINCE to the same version, which means, any calls of own deprecated API will be without warnings as well as also with the autotests (due to definitions being exported in the BUILD interface). But with the group variant of *_DEPRECATED_WARNINGS_SINCE now being set, FOO_DEPRECATED_WARNINGS_SINCE instead defaults to that value.
Reserved some time this week to give this some more thought, so far no satisfying proposal yet developed.
So we need to set FOO_DISABLE_DEPRECATED_BEFORE_AND_AT to N-1 while building FOO itself, right? Either magically here, or manually in every module...
Nono, FOO_DISABLE_DEPRECATED_BEFORE_AND_AT does not need to be touched, that works fine.
We want to rather have a new sane automatism for sane values of FOO_DEPRECATED_WARNINGS_SINCE in the build of FOO, despite group variables being set. While also still allowing full flexibility to other non-KF usage patterns.
I have a small set of approaches drafted/tested so far, but need to explore them in full details yet for all KDE & non-KDE usages I know about (& imagine). Just mentioning here that I am cooking up something :)