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

List:       kde-frameworks-devel
Subject:    Re: KDE CI: Applications =?UTF-8?B?wrsga3JldmVyc2kgwrs=?= kf5-qt5 FreeBSDQt5.13 - Build # 26 - Still
From:       laurent Montel <montel () kde ! org>
Date:       2020-03-17 6:01:54
Message-ID: 20581663.EfDdHjke4D () linux-zym0
[Download RAW message or body]

Le lundi 16 mars 2020, 15:43:29 CET Friedrich W. H. Kossebau a écrit :
> Am Montag, 16. März 2020, 10:39:39 CET schrieb Ben Cooksley:
> > On Mon, Mar 16, 2020 at 10:24 PM David Edmundson
> > 
> > <david@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)?

Hi,

> 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).

I vote indeed for removing all theses lines in CmakeLists.txt, as it's the 
method used at the moment for fixing compile error.

I liked the Volker's work about deprecated method, he ported all code before 
to deprecate API. It was a good method as he knew how to port code, so he 
ported and after deprecated.

For other devs they deprecated API but no port KDE code and didn't write info 
how to port it, and it's too sad because for sure we will port this code later 
perhaps when we will port to Qt6, all this port will we do quickly perhaps 
with bugs (ok I already made some errors but I make the porting on several 
release so we can see problem on a long time.).

As Friedrich wrote the people/maintainer will port code when they will see 
compile warning, I will trust him but when I look at git commit I don't see a 
lot of commit about it, but I see some commit which removed this 
DISABLE_DEPRECATED_BEFORE_AND_AT macro.

Ok before when we increased kf5 or qt version sometimes it didn't build so the 
solution was to fixing 1 compile error or two, sometime no very hard to fix, 
without theses macros we will accumulate a lot of compile warning and it will 
harder to port at the end when we will migrate at qt6, and not sure that we 
will have more dev at this moment.



To conclude I will remove theses lines in all modules (but in pim* and some 
apps as I maintains them) and "wait and see" how devs will make porting.

Regards 

> 
> 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


-- 
Laurent Montel | laurent.montel@kdab.com | 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 


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