KDEFrameworkCompilerSettings: enable all Qt % KF deprecation warnings
ClosedPublic

Authored by kossebau on Oct 27 2019, 7:41 PM.

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
kossebau created this revision.Oct 27 2019, 7:41 PM
Restricted Application added projects: Frameworks, Build System. · View Herald TranscriptOct 27 2019, 7:41 PM
Restricted Application added subscribers: kde-buildsystem, kde-frameworks-devel. · View Herald Transcript
kossebau requested review of this revision.Oct 27 2019, 7:41 PM
apol accepted this revision.Oct 28 2019, 11:54 AM
This revision is now accepted and ready to land.Oct 28 2019, 11:54 AM
kossebau added a subscriber: dfaure.Nov 3 2019, 7:58 PM

@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

dfaure accepted this revision.Nov 3 2019, 8:11 PM

Done (in the process of being pushed), you can push this.

Merci, will land later tonight. Bonnes vacances :)

This revision was automatically updated to reflect the committed changes.

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...

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 :)

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.

D25589 is now up as proposal to fix that.