Hi,
As discussed with David previously for QT_DEPRECATED, I am against it, because
if we fix a QT/KF_DEPRECATED version we can be sure that nobody will work for
fixing deprecated method until kf6.
If we can"t see that it breaks, everybody will wait for sure (otherwise it was
already fixed).
When a compilation is broken by a new deprecated method we will fix it.
Nobody fixes a warning by default.
I prefere to fix 1-2 deprecated methods between each new kf5 release as fixed
all deprecated method when we will port to kf6.
And last argument it's that only me which will port deprecated method.
Because if we need to increase version in CmakeLists.txt you can be sure that
nobody will do it and if I don't do increase it nobody will do.
So by default only me will port all deprecated method... And I don't want it.
Regards
Le jeudi 24 octobre 2019, 02:26:15 CEST Friedrich W. H. Kossebau a écrit :
> Hi,
>
> happy to see people starting to adapt the new deprecation macros available
> with KDE Frameworks (and any other library using ECMGenerateExportHeader,
> coming with ECM 5.64).
>
> Just, I see commits adding things like
> --- 8< ---
> add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000
> --- 8< ---
> or
> --- 8< ---
> if (EXISTS "${CMAKE_SOURCE_DIR}/.git")
> add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000)
> endif()
> --- 8< ---
> Like it also has been done before with the friend macro from Qt,
> QT_DISABLE_DEPRECATED_BEFORE.
>
> The issue is: this will result in broken builds once any future API of KF
> modules gets deprecated which is still used by the code where these
> definitions are set. Which creates hell for any distributions out there
> which combine released versions of not-yet-adapted-to-latest-KF-deprecation
> software as well as latest KF modules with those new deprecations. Suddenly
> their application/workspace builds will start to fail.
> Same as for the developers who look into fixing a bug and are running into a
> broken build. So the check for being a potential developer checkout looking
> for any .git directory seems nice, but still bring potential failed builds,
> increasing the contribution barrier.
>
> IMHO the QT_DISABLE_DEPRECATED_BEFORE & KF_DISABLE_DEPRECATED_BEFORE_AND_AT
> should be instead set only to a latest version which has been tested to
> build fine without any deprecated API. But not any unkown future one. It is
> potentially not forward-compatible. Even more as with KF6 preparations more
> deprecated API already in KF5 times is to be expected.
>
> Next to that then those other macros should/could be set to 0x060000 which
> control for which range of versions API deprecation warnings are emitted.
> Those should be wanted to have, and do not break the build by default, both
> for distributions and developers.
>
> So instead we should be doing something like that, to disable API first
> deprecated up to a given version and get warnings for any deprecated in
> newer versions:
> --- 8< ---
> add_definitions(
> -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x05c000
> -DKF_DEPRECATED_WARNINGS_SINCE=0x060000
> -DQT_DISABLE_DEPRECATED_BEFORE=0x050900
> -DQT_DEPRECATED_WARNINGS_SINCE=0x060000
> )
> --- 8< ---
>
> Your comments?
>
> Cheers
> Friedrich
--
Laurent Montel | [email protected] | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53,
www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent
software solutions
