ECMGenerateExportHeader: add NO_BUILD_SET_DEPRECATED_WARNINGS_SINCE flag
ClosedPublic

Authored by kossebau on Nov 28 2019, 12:49 PM.

Details

Summary

The original intention has been that by default during the build of a
library no warnings should be emitted on using own deprecated API,
as for one that has to be implemented as well as often deprecated API
is implemented using other deprecated API, so the warnings are not
helpful, and having to add lots of push/pop warnings instructions
in the code for the compiler harms readability more than it helps
ensuring to only use deprecated API where one has to.

The original intention was satisfied due to the default mechanism in the
generated export header code, where DEPRECATED_WARNINGS_SINCE if not set
defaults to DISABLE_DEPRECATED_BEFORE_AND_AT. That though breaks once
the group version of DEPRECATED_WARNINGS_SINCE is set in the build, as
this default has higher priority by design, even if the usage here only
wants to target dependency libs of the same group, not the current library.

To restore the intented default behaviour, by default
DEPRECATED_WARNINGS_SINCE is now explicitely set for the library build
itself to the EXCLUDE_DEPRECATED_BEFORE_AND_AT value, and a new macro
option allows to disable this.

Diff Detail

Repository
R240 Extra CMake Modules
Branch
NO_BUILD_SET_DEPRECATED_WARNINGS_SINCE
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 19245
Build 19263: arc lint + arc unit
kossebau created this revision.Nov 28 2019, 12:49 PM
Restricted Application added projects: Frameworks, Build System. · View Herald TranscriptNov 28 2019, 12:49 PM
Restricted Application added subscribers: kde-buildsystem, kde-frameworks-devel. · View Herald Transcript
kossebau requested review of this revision.Nov 28 2019, 12:49 PM
dfaure accepted this revision.Dec 1 2019, 7:27 PM

My head hurts a bit but I think I understand this now ;)

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)

This revision is now accepted and ready to land.Dec 1 2019, 7:27 PM

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

This revision was automatically updated to reflect the committed changes.