KCoreAddons is missing in the Packaged Building page

KCoreAddons is missing in the page even though it's required since https://github.com/telegramdesktop/tdesktop/commit/e20840b4d4c828d930b55a93995ded9eb2784c2d

Yeah, I don't know what would be the best way to explain its building at it's tricky to have the Qt 6 version along with the Qt 5 version. Would be really nice to hear anyone's practical experience on this. I see two options at least: telling it to install to a custom libdir (-DCMAKE_INSTALL_LIBDIR) or set the installation prefix to a subdirectory in building tree and build it along with tdesktop (-DCMAKE_INSTALL_PREFIX, -DBUILD_SHARED_LIBS=OFF), not sure what would be better. Either way it's possible to help cmake find the library with -DKF5CoreAddons_DIR. Basic build paramters could be found in snapcraft.yaml: https://github.com/telegramdesktop/tdesktop/blob/b36063e0862b82f783b1a1adbec5b25f1c20fe3c/snap/snapcraft.yaml#L236-L240

KCoreAddons must be bundled just like KF5KWayland, because the packaged version built against Qt 5 in all distributions.

No, it definitely not 'must', there are other options, see my previous message

No, it definitely not 'must', there are other options, see my previous message

Maybe it should be done automatically with ExternalProject_Add?

I'd like to avoid that due to two reasons:

1. It's not possible to use extra-cmake-modules without installation (and I don't like that hack I made the previous time for that, having extra-cmake-modules in Docker image is also not an option as KDE frameworks require ECM of the same version)
2. kcoreaddons requires qttools for build and I don't want to have it in final Docker image. It's especially a pity given that it's needed only to generate translations that are discarded anyway.

Context: I'm the maintainer for telegram-desktop in Alpine Linux and am a Qt/CMake noob. I ended up making a separate kcoreaddons-qt6 package. It seems to have built fine although I haven't tested it. Is this wrong?

And it doesn't conflict with the qt5 one? The idea is to set e.g. -DCMAKE_INSTALL_LIBDIR=lib/kf5qt6, so it won't conflict with the qt5 build. That's how e.g. ffmpeg 4.4 is built to be installed along with ffmpeg 5.0 in Arch: https://github.com/archlinux/svntogit-packages/blob/930ca4335cc72b7badab2b278790d23ca42d7031/trunk/PKGBUILD#L118. KDE frameworks install include headers to KF6 folder when building with Qt 6, so it shouldn't conflict, but maybe you'd need to remove the content of share directory from the qt6 package and add suffix to binaries (e.g. -qt6) to avoid conflict (if you need them at all). The content of the share directory from the qt5 package could be separated to make it a dependency of both the qt5 and qt6 packages.

Then you set -DKF5CoreAddons_DIR=/usr/lib/kf5qt6/cmake/KF5CoreAddons when building tdesktop and cmake will find the library

I ended up making a separate kcoreaddons-qt6 package. It seems to have built fine although I haven't tested it. Is this wrong?

Not an option. It will conflict with kf5-kcoreaddons, which is unacceptable.

Yes, they do conflict, which is probably bad.

I see only one acceptable option - build KF6CoreAddons before the telegram-desktop in its build manifest as a static library and then use -DKF5CoreAddons_DIR.

It's the simplest option if you can't contact kcoreaddons maintainers, yeah

It's the simplest option if you can't contact kcoreaddons maintainers, yeah

kcoreaddons maintainers won't build it against Qt 6, because all other KF5 packages built against Qt 5.

I don't see why not. It's a matter of need. If a package starts depending on Qt 6 version of the package, I don't see a reason to not to add it. Especially given that all its dependencies (qtbase, qttools, extra-cmake-modules) are in place.

It looks to me that kcoreaddons is at the very least being built with Qt6 in their CI.

I don't see why not. It's a matter of need. If a package starts depending on Qt 6 version of the package, I don't see a reason to not to add it.

Because all other KDE frameworks, apps and KDE itself built against Qt 5.

It looks to me that kcoreaddons is at the very least being built with Qt6 in their CI.

We're talking about distro maintainers :) But I guess contacting upstream for more convenient options is an option, too.

Because all other KDE frameworks, apps and KDE itself built against Qt 5.

Well, I don't see any barrier here. Now you have the first Qt 6 one, the time has come.

I don't see why not. It's a matter of need. If a package starts depending on Qt 6 version of the package, I don't see a reason to not to add it.

Major distribution won't do this in a foreseen future due to potential bugs until KDE upstream switches to Qt 6.

contacting upstream for more convenient options is an option, too.

Yeah, installing in different paths isn't a huge deal, but it'd be nice to get a new pkgconfig filename for upstreams to build against either.

Major distribution won't do this in a foreseen future due to potential bugs until KDE upstream switches to Qt 6.

I wouldn't speak on behalf of them if I were you

Major distribution won't do this in a foreseen future due to potential bugs until KDE upstream switches to Qt 6.

Again, you're missing the part where you can do this in a way that doesn't replace or conflict with the existing qt5-based framework libraries. If people start depending on them there will be no choice.

Again, you're missing the part where you can do this in a way that doesn't replace or conflict with the existing qt5-based framework libraries. If people start depending on them there will be no choice.

Then all KF5 should be built against Qt 6. Mixing Qt 5 and Qt 6 in one project is a very bad idea.

Btw, KDE still doesn't support theming for Qt 6. All Qt 6 dialogs looks too ugly:

Then all KF5 should be built against Qt 6. Mixing Qt 5 and Qt 6 in one project is a very bad idea.

Nobody is doing this. Having the libraries installed side-by-side doesn't mean one program will load both.

KDE still doesn't support theming for Qt 6

Then build tdesktop for Qt 5 I guess.

Then build tdesktop for Qt 5 I guess.

@ilya-fedin said that Qt 5 is not supported in telegram-desktop anymore.

I'm not ilya, but Qt 6 doesn't support windows 7, so as long as tdesktop supports win7 there'll be some sort of support for it. (I'm sure it'll be dropped soon enough however)

Gentoo currently defaults to building with Qt 5 since Qt 6 was introduced to the distro very late and is still considered unstable, as well as reasons like the one you mentioned. Users have the option to unmask the flag and configure it to build with qt6, though, providing us with a way to test it for the time being. The only point of contention is wayland, where some integrations don't work with qt5 anymore, but I have no idea what that affects if anything. Anyway all I'm saying is using qt5 is still an option for the time being if you're having problems with qt6.

@xvitaly is right, Qt 5 is not supported on Linux in fact, it builds just because it builds, but no one tests it and it can break at any time.

Then build tdesktop for Qt 5 I guess.

IMO that's not a reason to build with Qt 5. gtk applications have different dialogs yet people use them.

Then all KF5 should be built against Qt 6. Mixing Qt 5 and Qt 6 in one project is a very bad idea.

I think you overcomplicate it, it shouldn't. And no one talks about mixing Qt 5 and Qt 6.