[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: QT_DEPRECATED_BEFORE/KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000 considered harmful
From:       Allan Sandfeld Jensen <kde () carewolf ! com>
Date:       2019-10-24 19:44:30
Message-ID: 2503932.mvXUDI8C0e () twilight
[Download RAW message or body]

On Thursday, 24 October 2019 02:26:15 CEST Friedrich W. H. Kossebau wrote:
> 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?
> 
I completely agree it is silly abuse of the deprecated macros that doesn't 
belong anywhere. They should never be set higher than what you have tested 
last.

'Allan


[prev in list] [next in list] [prev in thread] [next in thread]