Use ECMGenerateExportHeader to manage deprecated API better
ClosedPublic

Authored by kossebau on Sep 9 2019, 4:06 PM.

Details

Summary

Allows

  • projects linking to KCoreAddons to hide deprecated API up to a given version or silence deprecation warnings before a given version, using
    • -DKCOREADDONS_DISABLE_DEPRECATED_BEFORE_AND_AT
    • -DKCOREADDONS_DEPRECATED_WARNINGS_SINCE
    • -DKCOREADDONS_NO_DEPRECATED_WARNINGS
    • -DKCOREADDONS_NO_DEPRECATED

      or
    • -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT
    • -DKF_DEPRECATED_WARNINGS_SINCE
    • -DKF_NO_DEPRECATED_WARNINGS
    • -DKF_NO_DEPRECATED
  • to build KCoreAddons optionally with deprecated API excluded from the build, using "EXCLUDE_DEPRECATED_BEFORE_AND_AT" cmake argument.
Test Plan

Builds with EXCLUDE_DEPRECATED_BEFORE_AND_AT set to 0, 5.0.0, CURRENT and
all the versions where deprecations were done.

Diff Detail

Repository
R244 KCoreAddons
Branch
useECMGenerateExportHeader
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 17262
Build 17280: arc lint + arc unit
kossebau created this revision.Sep 9 2019, 4:06 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptSep 9 2019, 4:06 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
kossebau requested review of this revision.Sep 9 2019, 4:06 PM
kossebau edited the summary of this revision. (Show Details)Sep 9 2019, 5:06 PM
kossebau updated this revision to Diff 67221.Oct 2 2019, 8:29 PM
  • update to latest version of ecm_generate_export_header with deprecation text support
kossebau retitled this revision from RFC: Use ECMGenerateExportHeader to manage deprecated API better to Use ECMGenerateExportHeader to manage deprecated API better.Oct 5 2019, 4:10 PM
kossebau added reviewers: Frameworks, mpyne.
mpyne accepted this revision.Oct 5 2019, 11:46 PM

The change looks good and builds in various combinations of CMake options (after I installed the changeset from D23789). I encountered that excluding deprecated components from the build requires a version of x.y.z. (not just x.y) but other than that things were straightforward from a developer's perspective.

Once D23789 is in we can commit to kcoreaddons.

This revision is now accepted and ready to land.Oct 5 2019, 11:46 PM

@mpyne Thanks for the immediate review and testing

I encountered that excluding deprecated components from the build requires a version of x.y.z. (not just x.y) but other than that things were straightforward from a developer's perspective.

Yes, that version precision mismatch (which I copied over from the Qt pattern for consistency) also left me a bit unhappy, as the z of x.y.z will be used with 0 value usually, as other values will/cannot make a difference. The argument I gave to myself is: deprecating API at patch-level versions does not make sense/needs support, so staying with x.y in the C++ preprocessor macros makes sense, also results in less macro implementation code. While at consumer side people would be using the hex number version value, where the z part is needed for the correct number (0xXXYYZZ vs 0xXXYY), so enforcing consumers to think in x.y.z pattern here makes sense.

This revision was automatically updated to reflect the committed changes.