D23815: [KConfig] port away from deprecated methods in Qt 5.14

[David Faure]

dfaure closed this revision.

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D23815

To: dfaure, mdawson, arichardson, vkrause
Cc: pino, arojas, mlaurent, kde-frameworks-devel, LeGast00n, GB_2, michaelh, 
ngraham, bruns

D23815: [KConfig] port away from deprecated methods in Qt 5.14

[David Faure]

dfaure added a comment.


  I'm going to adopt a different strategy for Frameworks after all, because:
  
  - setting this in KDEFrameworksCompilerSettings.cmake would affect much more 
than frameworks (this stricter set of flags has been adopted by many many 
applications)
  - setting this in kdesrc-build's kf5-frameworks-build-include for all of 
frameworks would also affect deprecated modules like kdelibs4support which I'm 
too lazy to port since they'll disappear
  
  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 0x06 (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 :)

REPOSITORY
  R237 KConfig

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D23815

To: dfaure, mdawson, arichardson, vkrause
Cc: pino, arojas, mlaurent, kde-frameworks-devel, LeGast00n, GB_2, michaelh, 
ngraham, bruns

D23815: [KConfig] port away from deprecated methods in Qt 5.14

[Volker Krause]

vkrause accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R237 KConfig

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D23815

To: dfaure, mdawson, arichardson, vkrause
Cc: pino, arojas, mlaurent, kde-frameworks-devel, LeGast00n, GB_2, michaelh, 
ngraham, bruns

D23815: [KConfig] port away from deprecated methods in Qt 5.14

[Pino Toscano]

pino added a comment.


  In D23815#528543 , @dfaure wrote:
  
  > 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")`.
  
  
  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.
  
  [1] https://wiki.debian.org/PackagingWithGit

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D23815

To: dfaure, mdawson, arichardson, vkrause
Cc: pino, arojas, mlaurent, kde-frameworks-devel, LeGast00n, GB_2, michaelh, 
ngraham, bruns

D23815: [KConfig] port away from deprecated methods in Qt 5.14

[David Faure]

dfaure added a reviewer: vkrause.

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D23815

To: dfaure, mdawson, arichardson, vkrause
Cc: arojas, mlaurent, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns

D23815: [KConfig] port away from deprecated methods in Qt 5.14

[David Faure]

dfaure added a comment.


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

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D23815

To: dfaure, mdawson, arichardson
Cc: arojas, mlaurent, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns

D23815: [KConfig] port away from deprecated methods in Qt 5.14

[Laurent Montel]

mlaurent added a comment.


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

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D23815

To: dfaure, mdawson, arichardson
Cc: arojas, mlaurent, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns

D23815: [KConfig] port away from deprecated methods in Qt 5.14

[David Faure]

dfaure added a comment.


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

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D23815

To: dfaure, mdawson, arichardson
Cc: arojas, mlaurent, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns

D23815: [KConfig] port away from deprecated methods in Qt 5.14

[Laurent Montel]

mlaurent added a comment.


  "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 :)

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D23815

To: dfaure, mdawson, arichardson
Cc: arojas, mlaurent, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns

D23815: [KConfig] port away from deprecated methods in Qt 5.14

[Antonio Rojas]

arojas added a comment.


  In D23815#528369 , @mlaurent wrote:
  
  > Why you don't add add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0x06) 
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=0x06 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.

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D23815

To: dfaure, mdawson, arichardson
Cc: arojas, mlaurent, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, 
bruns

D23815: [KConfig] port away from deprecated methods in Qt 5.14

[Laurent Montel]

mlaurent added a comment.


  Why you don't add add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0x06) 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=0x06 so we can fix it each time 
that we increase qt and not just waiting that we port to qt6) :)

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D23815

To: dfaure, mdawson, arichardson
Cc: mlaurent, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns