[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:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2020-03-17 15:06:35
Message-ID: 1745983.oqyEYj4Ezt () klux
[Download RAW message or body]

Am Dienstag, 17. März 2020, 07:01:54 CET schrieb laurent Montel:
> Le lundi 16 mars 2020, 15:43:29 CET Friedrich W. H. Kossebau a écrit :
> > 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.

Yes, that would be the perfect world.
Given the amount of KDE software that does not really scale though. And Qt 
developers deprecating API will not do us such favour in any case.

> For other devs they deprecated API but no port KDE code and didn't write
> info how to port it,

No info how to port should though be less a case these days, no? Do you have 
some examples where you would think there should be more info?
We should improve our KF policies then to make sure proper porting info is 
present, if that is not yet happening.

At least where I was involved, some "Deprecated since x.y, use foo() instead" 
was done, which usually was enough to do porting code (too bad we do not have 
a way to automate such simple porting yet, in a perfect world we could have 
fixit snippets for clazy/clang-tidy).

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

I think we all agree that doing work as early as possible is good. But forcing 
people into it, there we do not agree :)

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

Most will not port immediately, but when they get to it. Often bugs & features 
are more important. I would rather see builds failing as long as there are 
bugs reports with data-loss crashes open, to ensure people are forced to care 
for those ;)

> but I see some commit which removed this
> DISABLE_DEPRECATED_BEFORE_AND_AT macro.

The latter might have happened with macros set to 0x060000 versions, no? Which 
might have happened as people were just upset of getting their builds broken 
every now and then by this, when they actually had no time to care for 
deprecated API at that time. And did not understand things enough to know that 
just setting a proper limit would have been better.

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

Thanks for handling that so quickly.
Though, instead of removing all lines completely, I would have hoped just the 
numbers would be adapted and the in-git-checkout-only wrapper removed.
So we would have a compiler-supported guard to not add new usages of already 
deprecated API. As by the recommendation given in
https://marc.info/?l=kde-devel&m=157190321318565&w=2
the ideal setup would be like this:
--- 8< ---
add_definitions(
    # hide deprecated API of Qt <= 5.9
    -DQT_DISABLE_DEPRECATED_BEFORE=0x050900 
    # enable warnings for API up to Qt 6.0
    -DQT_DEPRECATED_WARNINGS_SINCE=0x060000
    # hide deprecated API of KF <= 5.48
    -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x053000
    # enable warnings for API up to KF 6.0
    -DKF_DEPRECATED_WARNINGS_SINCE=0x060000
)
--- 8< ---
((The *_DEPRECATED_WARNINGS_SINCE variants are needed, as explicitly set 
*_DISABLE_DEPRECATED_BEFORE* triggers a default of no warnings for 
deprecations in newer API, so this has to be overwritten.
Yes, in KDE Frameworks you do not see those, as they are done centrally in 
KDEFrameworkCompilerSettings.cmake))

Having none of those flags set results in warnings for all deprecated API, so 
still a setup that should allow developers to know what to work on.

Cheers
Friedrich


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