Hi.

I was just wondering as I had not tried it yet, but how far along is KDE master from building against QT 5?

I have QT5 built for running on Wayland on my Live CD, but I know some changes must be made to KDE for it to compile against QT5. ...I see there is a commit digest from the 2/5/2012 saying that that is being started.

Any ideas on this on how far it is, and will it compile?

Thanks.

KDE is not yet at the point in time where it is ready to be used with Qt 5. The only components which are being prepared for Qt 5 are kdelibs and kdepimlibs at this point - and their Qt 5 compatible incarnation will be known as KDE Frameworks.

The KDE Frameworks should have a slimmer dependency profile and be more usable to non-KDE Qt applications as well.

If you wish to help in KDE Frameworks development, I recommend you ask on #kde-devel on Freenode.

bcooksley wrote:KDE is not yet at the point in time where it is ready to be used with Qt 5. The only components which are being prepared for Qt 5 are kdelibs and kdepimlibs at this point - and their Qt 5 compatible incarnation will be known as KDE Frameworks.

The KDE Frameworks should have a slimmer dependency profile and be more usable to non-KDE Qt applications as well.

If you wish to help in KDE Frameworks development, I recommend you ask on #kde-devel on Freenode.

Thanks. I've found a 4.8 version of QT with backports for supporting Wayland, but it also has lighthouse, which does that require a recompile, or is it source incompatible?

Thanks.

I believe the Lighthouse backends are compiled into Qt itself - but the API shown by Qt is the same so it should have no source or binary compatibility problems.

bcooksley wrote:I believe the Lighthouse backends are compiled into Qt itself - but the API shown by Qt is the same so it should have no source or binary compatibility problems.

perhaps I am compiling wrong because I get a unresolved symbol error when running KDE apps (and installed QT apps). The names of the unresolved symbols have what seems to be random combonations of charachters in between them, and are different unresolved symbol errors for each app.

I'm doing this on a system with KDE 4.8, and KDE 4.8 has QT 4.8 if I'm right, and the QT GIT repo is 4.8 ( https://qt.gitorious.org/~thiago-intel/ ... pa-wayland ). So it would seem that a rebuild of QT requires a rebuild of KDE, unless if I am doing something wrong?

Hm, what I stated might only apply to Qt 5 maybe. You will likely have to rebuild KDE then - or at the very least kdelibs and the Oxygen style.

bcooksley wrote:Hm, what I stated might only apply to Qt 5 maybe. You will likely have to rebuild KDE then - or at the very least kdelibs and the Oxygen style.

It seems something in the source level changed, as I get errors containing KWindowSystem::* as kdelibs builds, and then it stops.

I suppose there isn't anything I can turn off?

I would recommend looking into the KDE Frameworks effort at this point - it is probable that Lighthouse involves more changes to Qt than I previously expected.

bcooksley wrote:I would recommend looking into the KDE Frameworks effort at this point - it is probable that Lighthouse involves more changes to Qt than I previously expected.

I suppose I can try to see what happens if I compile Frameworks...I'll tell you what happens when my buildscripts finish. I assume the frameworks branch is still using qt 4.8?

The Frameworks branch is still using Qt 4.8, but this is mainly to ease porting - it is being built against Qt 5 - and is targeted for Qt 5 in the end.

bcooksley wrote:The Frameworks branch is still using Qt 4.8, but this is mainly to ease porting - it is being built against Qt 5 - and is targeted for Qt 5 in the end.

OK. Cool. I have found a QT 4.8 lighthouse repository with the Wayland backports it needs. I'll let you know how it goes. Thanks!

I tried building it, but I don't know where to find extra-cmake-modules or Findextracmakemodules.cmake...

I believe there is documentation in regard to that on KDE Techbase. As to where to find extra-cmake-modules - it can be found on git.kde.org.

bcooksley wrote:I believe there is documentation in regard to that on KDE Techbase. As to where to find extra-cmake-modules - it can be found on git.kde.org.

That seems to have made it work. I had to put the -i argument to make, as it's trying to build kdewindowsystem.so or something (with KDEWindowSystem::). I imagine that will be fixed soon.

I have to try a rebuild to see if it works though, as I tried to make it build outside of my build scripts with all the variables.

but thanks so much for helping me get it to build!

It seems that I'm still getting an error, but during runtime, and looking at ldd, it seems it's not building libkdeui.so.5, I get lots of "*** No rule to make target 'lib/libkdeui.so.5.8.0', needed by..."'s lines in my buildlog, even though it seems other files build (and actually it appears for a few other libraries, but libkdeui.so.5 seems to be the most importaint)

Is there something I am doing wrong, or is this a bug?

EDIT: It seems its because it needs libkwindowsystem.so... which can't build because it's relying on stuff that's not in QT. ...Unless I try to make it build around QT embedded. It's probably a CMAKE option, and I'll try to find it. It's probably --enable-qt-embedded, but I can't test that just just now, until I redownload the source.

EDIT AGIAN: I'm finding -DKDE_NO_WINDOWSYSTEM . I'll try that too,