<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div name="quoted-content">In KService (KPluginInfo) the BUILD macro variant is used for non-virtual<br/>
methods, because it is used in public API of other frameworks. Though that does not seem to be used consistently.</div>
<div name="quoted-content">A good argument against using the BUILD variant in the header is that consumers/devs are not at all able to</div>
<div name="quoted-content">test the build when excluding deprecated API completely.</div>
<div name="quoted-content"> </div>
</div>
<div>
<div>My primary concern is that we need to keep using the classes/method, because<br/>
of compatibility, like KServiceTypeTrader they should all have a viable alternative.</div>
<div>But this means that in large parts of frameworks and plasma we can not utilize the macros that much.</div>
<div> </div>
<div>PS: Forgot about this thread and had this mail lying around as a draft for quite some time.</div>
<div>
<div> </div>
<div>Regards</div>
<div>Alex</div>
<div data-darkreader-inline-border-left="" name="quote" style="margin: 10px 5px 5px 10px; padding: 10px 0px 10px 10px; border-left: 2px solid rgb(195, 217, 229); overflow-wrap: break-word; --darkreader-inline-border-left: #274759;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Sonntag, 06. Juni 2021 um 00:46 Uhr<br/>
<b>Von:</b> "Friedrich W. H. Kossebau" <kossebau@kde.org><br/>
<b>An:</b> kde-frameworks-devel@kde.org<br/>
<b>Betreff:</b> Re: Deprecation wrappers for pre-KF6 time (was: Re: KF6 meeting notes 2021-06-05)</div>
<div name="quoted-content">Am Samstag, 5. Juni 2021, 22:39:15 CEST schrieb Alexander Lohnau:<br/>
> Or could we use the BUILD_DEPRECATED_SINCE variant in this case? Like we<br/>
> already have to do with virtual methods.<br/>
><br/>
> This way one would still be able to test it when compiling the framework<br/>
> without deprecations. Existing API users will still be informed about the<br/>
> deprecations by the compiler warnings.<br/>
<br/>
Using BUILD_DEPRECATED_SINCE with what will become the KF6 Beta version (i.e.<br/>
the version where something will disappear in preparation for KF6) should be<br/>
possible as well. The current way of testing that no hidden dependency by<br/>
usages of deprecated-with-already-present-replacement API still exists, by<br/>
building all KF libraries with DISABLE_DEPRECATED_BEFORE_AND_AT=CURRENT (or<br/>
explicit version) should not be affected by this, as after all the macro<br/>
should yield true for bigger versions.</div>
<div name="quoted-content"><br/>
And the version-controlled deprecation warning macros could also be used with<br/>
that BETA version (though we should then adapt any current usages of<br/>
KF_DEPRECATED_WARNINGS_SINCE to not use 0x060000, but the respective KF6 Beta<br/>
version, to silence warnings for the stuff only deprecated without parallel<br/>
replacement and replaced/dropped for the KF5 beta.<br/>
Think e.g. as negative exapmple for what to avoid the useless warnings for<br/>
QNetworkConfigurationManager, where we cannot do anything about while using<br/>
Qt5 and have to do that extra work to tell the compiler to not warn for that<br/>
class on our side.</div>
<div name="quoted-content"><br/>
E.g. by the (broken) example I linked before:<br/>
<br/>
#if KPARTS_VERSION <= QT_VERSION_CHECK(5, 900, 0) # the 900 is broken<br/>
#include <KMimeTypeTrader><br/>
#include <KPluginInfo><br/>
#include <QMimeDatabase><br/>
#include <QMimeType><br/>
#endif<br/>
<br/>
could instead be<br/>
<br/>
#if KPARTS_BUILD_DEPRECATED_SINCE(5, 190) # or whatever if KF6 Beta<br/>
#include <KMimeTypeTrader><br/>
#include <KPluginInfo><br/>
#include <QMimeDatabase><br/>
#include <QMimeType><br/>
#endif<br/>
<br/>
On the other hand the term DEPRECATED could be confusing here, as nothing is<br/>
really deprecated in the traditional sense., where something is tagged to be<br/>
removed either because being unused or in favour of another now available<br/>
approach. So this could be considered an abuse of those macros rather, and<br/>
where things are already complex now they might get even more complex by that<br/>
additional meaning.<br/>
<br/>
The BUILD_DEPRECATED_SINCE are there for being able to configure a build with<br/>
or without, with a filter level by version even. Will that be needed for<br/>
things which get fully replaced? I.e. will there be a transition time where<br/>
both old & new are available? If not, I would make this rather a simple hard<br/>
condition against the foreseen version where something will be replaced.<br/>
<br/>
Also, if X gets replaced by Y, that X is right now also used by other things<br/>
often in the same module, so being able to completely build without X might<br/>
not be doable. So the macro usage cannot even be tested properly. And things<br/>
will only be found out when actually replacing X by Y (and Y might only be<br/>
created in the process), so any wrapping beforehand does not really prepare<br/>
anything for someone?<br/>
<br/>
Is there an example where things could be demoed/tested/experimented with?<br/>
<br/>
Cheers<br/>
Friedrich<br/>
</div>
<div name="quoted-content"> </div>
<div name="quoted-content"> </div>
<div name="quoted-content"> </div>
</div>
</div>
</div></div></body></html>