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.
make && ctest
| No Linters Available |
| No Unit Test Coverage |
| Buildable 16301 | |
| Build 16319: arc lint + arc unit |
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.
Note that "being in git" does not imply "this is the development repository": there are distributions that maintain the sources expanded in git repositories [1], so the check would be mistakenly triggered in those cases.
I'm going to adopt a different strategy for Frameworks after all, because:
So what I'm going to do instead is set it in the toplevel CMakeLists.txt of each framework, after writing a script to do that.
And instead of setting it to 0x060000 (which indeed breaks compilation whenever Qt changes, until 6.0) I'll set it to 5.13 (0x050d00) for now, then 5.14 (0x050e00) once 5.14 is released (not before, they might still deprecate more methods by then), and so on. If I'm the one doing the porting, I might as well trigger the breakage only when I have time to fix it.
Laurent, I think you should do the same in KDEPIM. If you want others to help, create a phabricator task (like we did with T11553). At least the one doing the porting will have decided to do that, rather than being forced to do it because he's the first one to upgrade Qt :)