[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:       David Faure <faure () kde ! org>
Date:       2019-10-25 8:00:47
Message-ID: 1853284.CrzyxZ31qj () asterixp50
[Download RAW message or body]

On vendredi 25 octobre 2019 08:39:24 CEST Volker Krause wrote:
> On Thursday, 24 October 2019 21:59:02 CEST David Faure wrote:
> > On jeudi 24 octobre 2019 18:49:02 CEST Volker Krause wrote:
> > > On Thursday, 24 October 2019 16:41:58 CEST David Faure wrote:
> > > 
> > > > No such separation in KF5 itself though, there the question remains.
> > > > But we have the task in our KF6 dashboard, so hopefully we won't
> > > > forget
> > > > to
> > > > regularly increase the number and fix compilation. We as in, any KF6
> > > > volunteer, not necessarily Laurent.
> > > 
> > > There's two things to look at for Frameworks I think:
> > > - Qt: only two more version updates remaining for 5, or at most two per
> > > year. Doing this as an explicit/script-assisted bump is probably
> > > acceptable, and to to be sure we don't forget this it could maybe
> > > automatically be determined as max(explicitly deprecated qt version,
> > > minimum required qt version).
> > 
> > I like the overall idea. Looking at implementing it though, it doesn't
> > seem
> > trivial to do the max() as CMakeLists.txt logic. But it doesn't have to
> > be,
> > this is static at any given point in time, so I'll just do that in
> > release-tools/increase_qt_version.sh
> > 
> > > - other KF5 dependencies: it might be worth setting this to the current
> > > KF5
> > > version. At least at the point where we are deprecated-clean once, and
> > > accept a deprecation policy that requires Frameworks to be ported before
> > > the deprecation is executed. In such a scenario this would never
> > > trigger,
> > > but provide a safe guard we follow our own rules.
> > 
> > Very clever. Yep, this makes a lot of sense. I'll do this too.
> 
> In case this ends up being activated in production builds, this would
> however require our ABI isn't changing by deactivating deprecated bits.
> Enum values and vtable layouts look particularly in danger for this. I'm
> not sure this was considered by deprecations predating the new
> possibilities.

I think Friedrich took care of that when porting everything to the new macros.
ABI-changing things are marked with *_BUILD_DEPRECATED_SINCE which is 
controlled by EXCLUDE_DEPRECATED_BEFORE_AND_AT which I'm not setting.

But yeah, maybe something slipped by. Once my KF5 build with 
KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x053f00 is done
[which requires porting 13 modules, apparently), I'll see if the rest of my 
Plasma session and KDE Applications (which I'm not recompiling) suffer from 
BIC changes :-)

-- 
David Faure, faure@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5



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