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

List:       kde-devel
Subject:    QT_DEPRECATED_BEFORE/KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000 considered harmful
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2019-10-24 0:26:15
Message-ID: 1676740.uattmWGv2s () klux
[Download RAW message or body]

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


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