Am Montag, 16. März 2020, 10:39:39 CET schrieb Ben Cooksley:
> On Mon, Mar 16, 2020 at 10:24 PM David Edmundson
>
> <da...@davidedmundson.co.uk> wrote:
> > There is not a SIC. KIO is fine
> >
> > It's merely this crap again:
> >
> > if (EXISTS "${CMAKE_SOURCE_DIR}/.git")
> >
> > add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0x060000)
> > add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x060000)
> >
> > endif()
>
> May I suggest that we tweak this macro so that passing 0x060000 makes
> it no-op and fail open (disabling nothing)?
We could only tweak the macros handling K*_DISABLE_DEPRECATED_BEFORE_AND_AT,
though those are complicated enough and this would also just be a work-around
for a usage currently not favoured by many (it will be wanted at KF6
preparation/porting times though).
Instead we should finally create the policy everywhere to use
QT_DISABLE_DEPRECATED_BEFORE & KF_DISABLE_DEPRECATED_BEFORE_AND_AT only with
numbers of released versions that have been checked against. And not use those
with version numbers of the future to trigger failing builds for developers
once further API in use is deprecated, to force people into working on usage
of deprecated API instantly.
Some thought doing 0x060000 would be still acceptable with master branches.
Though this would need active avoiding to have this setup on creating new
stable branches being copied into those. Which seems not cared for though.
And myself I am among the people who think also for master being forced into
deprecated API work is overdoing - it is good to do things as early as
possible, to "flatten the curve" of Qt6/KF6 porting work. But that is what
warnings are for.
Laurent,
could you do the favour to change all the usages of
*DISABLE_DEPRECATED_BEFORE_AND_AT you introduced to a version matching to the
latest released version you are sure works fine? (or organize such a change by
people working on those repos). And this should be done for stable as well
(sadly 20.04 was just branched :/ ).
The "if (EXISTS "${CMAKE_SOURCE_DIR}/.git")" should be removed as well then,
no longer being needed, and to also ensure released tarballs are built with
same flags as developer builds (might e.g. affect overloaded methods).
Yes, this will break your personal workflow of your deprecated API usage work
(which IMHO is very valuable, sadly of the kind nobody will really notice due
to Qt6/KF6 porting life being easier for them without knowing how bad it would
have been, you will stay an unsung hero).
I have no simple idea yet how to enable a similar approach yet again. Passing
"-Werror=deprecated-declarations" to the build configurations via env vars is
not targeted only at Qt & KF, so might have undesired sideeffects.
Cheers
Friedrich
