Am Samstag, 5. Juni 2021, 22:39:15 CEST schrieb Alexander Lohnau: > Or could we use the BUILD_DEPRECATED_SINCE variant in this case? Like we > already have to do with virtual methods. > > This way one would still be able to test it when compiling the framework > without deprecations. Existing API users will still be informed about the > deprecations by the compiler warnings.
Using BUILD_DEPRECATED_SINCE with what will become the KF6 Beta version (i.e. the version where something will disappear in preparation for KF6) should be possible as well. The current way of testing that no hidden dependency by usages of deprecated-with-already-present-replacement API still exists, by building all KF libraries with DISABLE_DEPRECATED_BEFORE_AND_AT=CURRENT (or explicit version) should not be affected by this, as after all the macro should yield true for bigger versions. And the version-controlled deprecation warning macros could also be used with that BETA version (though we should then adapt any current usages of KF_DEPRECATED_WARNINGS_SINCE to not use 0x060000, but the respective KF6 Beta version, to silence warnings for the stuff only deprecated without parallel replacement and replaced/dropped for the KF5 beta. Think e.g. as negative exapmple for what to avoid the useless warnings for QNetworkConfigurationManager, where we cannot do anything about while using Qt5 and have to do that extra work to tell the compiler to not warn for that class on our side. E.g. by the (broken) example I linked before: #if KPARTS_VERSION <= QT_VERSION_CHECK(5, 900, 0) # the 900 is broken #include <KMimeTypeTrader> #include <KPluginInfo> #include <QMimeDatabase> #include <QMimeType> #endif could instead be #if KPARTS_BUILD_DEPRECATED_SINCE(5, 190) # or whatever if KF6 Beta #include <KMimeTypeTrader> #include <KPluginInfo> #include <QMimeDatabase> #include <QMimeType> #endif On the other hand the term DEPRECATED could be confusing here, as nothing is really deprecated in the traditional sense., where something is tagged to be removed either because being unused or in favour of another now available approach. So this could be considered an abuse of those macros rather, and where things are already complex now they might get even more complex by that additional meaning. The BUILD_DEPRECATED_SINCE are there for being able to configure a build with or without, with a filter level by version even. Will that be needed for things which get fully replaced? I.e. will there be a transition time where both old & new are available? If not, I would make this rather a simple hard condition against the foreseen version where something will be replaced. Also, if X gets replaced by Y, that X is right now also used by other things often in the same module, so being able to completely build without X might not be doable. So the macro usage cannot even be tested properly. And things will only be found out when actually replacing X by Y (and Y might only be created in the process), so any wrapping beforehand does not really prepare anything for someone? Is there an example where things could be demoed/tested/experimented with? Cheers Friedrich
