In KService (KPluginInfo) the BUILD macro variant is used for non-virtual
methods, because it is used in public API of other frameworks. Though that does not seem to be used consistently.
methods, because it is used in public API of other frameworks. Though that does not seem to be used consistently.
A good argument against using the BUILD variant in the header is that consumers/devs are not at all able to
test the build when excluding deprecated API completely.
My primary concern is that we need to keep using the classes/method, because
of compatibility, like KServiceTypeTrader they should all have a viable alternative.
of compatibility, like KServiceTypeTrader they should all have a viable alternative.
But this means that in large parts of frameworks and plasma we can not utilize the macros that much.
PS: Forgot about this thread and had this mail lying around as a draft for quite some time.
Regards
Alex
Gesendet: Sonntag, 06. Juni 2021 um 00:46 Uhr
Von: "Friedrich W. H. Kossebau" <kosse...@kde.org>
An: kde-frameworks-devel@kde.org
Betreff: Re: Deprecation wrappers for pre-KF6 time (was: Re: KF6 meeting notes 2021-06-05)
Von: "Friedrich W. H. Kossebau" <kosse...@kde.org>
An: kde-frameworks-devel@kde.org
Betreff: Re: Deprecation wrappers for pre-KF6 time (was: Re: KF6 meeting notes 2021-06-05)
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.
> 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
