Commit f67fd89c authored by David Faure's avatar David Faure
Browse files

Fix compilation after KContacts::Addressee::insertEmail was deprecated

KF 5.88 hasn't been released yet, please don't set
KF_DISABLE_DEPRECATED_BEFORE_AND_AT to 5.88 before it's known what
exactly will be deprecated in that version.

CCMAIL: montel@kde.org
parent 775ba9e9
Pipeline #90886 failed with stage
in 25 minutes and 9 seconds
......@@ -158,7 +158,7 @@ set_package_properties(Qt5Keychain PROPERTIES
option(KDEPIM_RUN_ISOLATED_TESTS "Run the isolated tests." FALSE)
add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0x050f02)
add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x055800)
add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x055700)
option(USE_UNITY_CMAKE_SUPPORT "Use UNITY cmake support (speedup compile time)" OFF)
......
  • hi, Not I am not agree with it. If it doesn't compile it because we need to adapt code. So you can create a patch as you can use addEmail directly with a check version. Or you wait that someone creates it. (there is some MR for it at the moment) (And I didn't think that you used master as branch for kde).

    (adding 0x055800 allows to see when we use new deprecated method in new framework.)

    Regards.

  • mentioned in commit 1f2f62d9

    Toggle commit list
  • I just wanted to build kdepim-runtime to work on something there (merging the pop3 slave into the pop3 resource, which is something for master, not stable), and I ended up having to dig into a build error in libkgapi (before hitting the same issue in kdepim-runtime). I was surprised that things didn't build and suspected my setup (wrong version of some library) for quite some time -- because the error message didn't even say Addresse but some subclass that lives in kdepim, so it really wasn't obvious that the problem came from KF5. And then I wasn't sure that porting to addEmail right away, before it's released, would be a good idea (this would then break compilation for kdepim contributors not fully up-to-date with KF5 master). It makes more sense to me to wait a little bit before using new KF API...

    On the other hand, if you set this var to 0x055800 after 5.88 is released, then you still achieve the same purpose (porting away from deprecated methods) but without creating surprising build breakages for other people. (And it's a lot easier to find out that the breakage is related to KF5 deprecations when it happens as a result of bumping the version number.)

  • "On the other hand, if you set this var to 0x055800 after 5.88 is released, then you still achieve the same purpose (porting away from deprecated methods) but without creating surprising build breakages for other people. (And it's a lot easier to find out that the breakage is related to KF5 deprecations when it happens as a result of bumping the version number.)" I will not the same result as I will necessary to fix X deprecation in same time and not fixing deprecation when it adds in framework repro. it's more easy to fix 1 deprecation by week as 4 deprecations when we release framework.

  • Then set 0x555800 locally, without committing it yet, until 5.88 is released.

    Breaking compilation is never a good way to work as a group and allow external contributions.

Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment