kossebau added a comment.
Hi. When introducing the deprecation macros to a lib with `ecm_generate_export_header`, one also needs to help kapidox & ecm_add_qch. Sadly this was only discovered later, so it is also missing from the first set of such commits introducing the use of `ecm_generate_export_header`which you might have taken as template :) bdd8930cca99d81a5a5d4714b267419576e30ede <https://phabricator.kde.org/R289:bdd8930cca99d81a5a5d4714b267419576e30ede> fixes this. Teaching the documentation tools is meanwhile also documented at https://community.kde.org/Policies/Library_Code_Policy#Deprecation_of_API so hopefully future additions of ecm_generate_export_header will have all things set as needed from the start. Yes, all these duplications are hell. In a perfect world all this depreaction support would be part of the language specification, and tools would handle things be default... for now this is the best someone came up with. INLINE COMMENTS > CMakeLists.txt:95 > + DEPRECATION_VERSIONS 5.67 > + EXCLUDE_DEPRECATED_BEFORE_AND_AT ${EXCLUDE_DEPRECATED_BEFORE_AND_AT} > +) This also needs the definition as option in the toplevel file. Fixed by 191078e9387b3b591c46d68f884a18ad96b4f2f6 <https://phabricator.kde.org/R289:191078e9387b3b591c46d68f884a18ad96b4f2f6> REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D26594 To: nicolasfella, #frameworks, broulik, apol Cc: kossebau, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
