[KConfig] port away from deprecated methods in Qt 5.14
Needs ReviewPublic

Authored by dfaure on Tue, Sep 10, 7:47 AM.

Details

Summary

In kconf_update, the ctime usage used to be about metadata change time
(buff.st_ctime, before it got ported to the misnamed created()).
I ported it to birthTime, because I think
date of birth is a more useful way to identify a file than
date of permission change which doesn't really matter to us.
But in practice, I can't help but wonder if mtime alone wouldn't be
enough.

For the QStringLiteral("%%1").arg(i) bit, I tested it in tst_qstring,
the first % is left untouched.

Test Plan

make && ctest

Diff Detail

Repository
R237 KConfig
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 16301
Build 16319: arc lint + arc unit
dfaure created this revision.Tue, Sep 10, 7:47 AM
Restricted Application added a project: Frameworks. · View Herald TranscriptTue, Sep 10, 7:47 AM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
dfaure requested review of this revision.Tue, Sep 10, 7:47 AM

Why you don't add add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0x060000) in cmake toplevel ?
or 5.14 value ? so we can be sure that it builds without deprecated method until it.

(I prefere QT_DISABLE_DEPRECATED_BEFORE=0x060000 so we can fix it each time that we increase qt and not just waiting that we port to qt6) :)

arojas added a subscriber: arojas.Tue, Sep 10, 9:42 AM

Why you don't add add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0x060000) in cmake toplevel ?
or 5.14 value ? so we can be sure that it builds without deprecated method until it.

(I prefere QT_DISABLE_DEPRECATED_BEFORE=0x060000 so we can fix it each time that we increase qt and not just waiting that we port to qt6) :)

Please don't. This should never, ever, be in released code (it's the same kind of evil as -Werror). You're artificially imposing an expiration date on the code, and effectively reverting Qt5 binary compatibility commitment. You don't know which Qt version the distributions shipping your application will be using, it may be newer than the one available at release time. -DQT_DISABLE_DEPRECATED_BEFORE should not be set to anything higher than the latest release, Qt is known to change their API even at the RC stage.

This kind of thing should only be added to the developer's personal build flags, or to CI.

"This kind of thing should only be added to the developer's personal build flags, or to CI."
on CI without this flags in module is just not a good idea.

After that I use in pim* and it's not a problem. If a people wants to use new qt (as David :) ) he will fix it and it"s good for me :)

I actually think it's a mistake to set this define unconditionally in PIM.

If a user of the last PIM release (as in, a person or a distro) wants to use Qt 5.14, they'll get compilation errors, unnecessarily.

If we want to enable this flag (to "punish" the first KDE developer who upgrades Qt, like me currently), then at least we should only do so in git checkouts, not in release tarballs.
This is easy to do: if (EXISTS "${CMAKE_SOURCE_DIR}/.git").
I'm actually thinking of doing that (in KDEFrameworkCompilerSettings), once everything builds again (I obviously can't push that just yet).

"If a user of the last PIM release (as in, a person or a distro) wants to use Qt 5.14, they'll get compilation errors, unnecessarily." and he will fix it :) not a bad idea :)

"if (EXISTS "${CMAKE_SOURCE_DIR}/.git")" I like this idea.

Laurent: I'm talking about release tarballs. People don't fix those, that would be pointless.