From kde-frameworks-devel Tue Mar 17 06:01:54 2020 From: laurent Montel Date: Tue, 17 Mar 2020 06:01:54 +0000 To: kde-frameworks-devel Subject: Re: KDE CI: Applications =?UTF-8?B?wrsga3JldmVyc2kgwrs=?= kf5-qt5 FreeBSDQt5.13 - Build # 26 - Still Message-Id: <20581663.EfDdHjke4D () linux-zym0> X-MARC-Message: https://marc.info/?l=kde-frameworks-devel&m=158442494521919 Le lundi 16 mars 2020, 15:43:29 CET Friedrich W. H. Kossebau a =E9crit : > Am Montag, 16. M=E4rz 2020, 10:39:39 CET schrieb Ben Cooksley: > > On Mon, Mar 16, 2020 at 10:24 PM David Edmundson > >=20 > > wrote: > > > There is not a SIC. KIO is fine > > >=20 > > > It's merely this crap again: > > >=20 > > > if (EXISTS "${CMAKE_SOURCE_DIR}/.git") > > >=20 > > > add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=3D0x060000) > > > add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=3D0x060000) > > >=20 > > > endif() > >=20 > > 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). >=20 > Instead we should finally create the policy everywhere to use > QT_DISABLE_DEPRECATED_BEFORE & KF_DISABLE_DEPRECATED_BEFORE_AND_AT only w= ith > 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. >=20 > Some thought doing 0x060000 would be still acceptable with master branche= s. > 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 i= nto > 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. >=20 > 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 th= en, > no longer being needed, and to also ensure released tarballs are built wi= th > 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= =20 method used at the moment for fixing compile error. I liked the Volker's work about deprecated method, he ported all code befor= e=20 to deprecate API. It was a good method as he knew how to port code, so he=20 ported and after deprecated. =46or other devs they deprecated API but no port KDE code and didn't write = info=20 how to port it, and it's too sad because for sure we will port this code la= ter=20 perhaps when we will port to Qt6, all this port will we do quickly perhaps= =20 with bugs (ok I already made some errors but I make the porting on several= =20 release so we can see problem on a long time.). As Friedrich wrote the people/maintainer will port code when they will see= =20 compile warning, I will trust him but when I look at git commit I don't see= a=20 lot of commit about it, but I see some commit which removed this=20 DISABLE_DEPRECATED_BEFORE_AND_AT macro. Ok before when we increased kf5 or qt version sometimes it didn't build so = the=20 solution was to fixing 1 compile error or two, sometime no very hard to fix= ,=20 without theses macros we will accumulate a lot of compile warning and it wi= ll=20 harder to port at the end when we will migrate at qt6, and not sure that we= =20 will have more dev at this moment. To conclude I will remove theses lines in all modules (but in pim* and some= =20 apps as I maintains them) and "wait and see" how devs will make porting. Regards=20 >=20 > 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=3Ddeprecated-declarations" to the build configurations v= ia > env vars is not targeted only at Qt & KF, so might have undesired > sideeffects. >=20 > Cheers > Friedrich =2D-=20 Laurent Montel | laurent.montel@kdab.com | KDE/Qt Senior Software Engineer= =20 KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53= ,=20 www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent=20 software solutions=20