libkdeedu & kde4-runtime: qt4-mac upgrade causes problems for some KDE4 ports on Mavericks

[mkae (Marko Käning)]

After upgrading a qt4-mac-based MacPorts installation I ran during rev-upgrade into this:

$ sudo port rev-upgrade
.
.
.
--->  Computing dependencies for libkdeedu
--->  Fetching archive for libkdeedu
--->  Attempting to fetch libkdeedu-4.14.1_0.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/libkdeedu
--->  Attempting to fetch libkdeedu-4.14.1_0.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/libkdeedu
--->  Attempting to fetch libkdeedu-4.14.1_0.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/libkdeedu
--->  Fetching distfiles for libkdeedu
--->  Verifying checksums for libkdeedu
--->  Extracting libkdeedu
--->  Configuring libkdeedu
Error: org.macports.configure for port libkdeedu returned: configure failure: command execution failed
Please see the log file for port libkdeedu for details:
    /opt/local/var/macports/logs/_Users_marko_WC_SVN_MacPorts_dports_kde_libkdeedu/libkdeedu/main.log
Error: Unable to upgrade port: 1

which was caused by this:

.
.
.
:info:configure CMake Error at /opt/local/share/cmake-3.3/Modules/FindKDE4.cmake:111 (message):
:info:configure   ERROR: cmake/modules/FindKDE4Internal.cmake not found in
:info:configure Call Stack (most recent call first):
:info:configure   CMakeLists.txt:5 (find_package)
:info:configure
:info:configure
:info:configure -- Configuring incomplete, errors occurred!

Looks like rev-upgrade doesn't respect the correct order of dependencies, which is why I did this to resolve the hangup:

$ sudo port uninstall --follow-dependents kdelibs4
$ sudo port install kmymoney4-devel

which finally installs some of the required dependencies

- kdelibs4
- kfilemetadata
- mobipocket
- nepomuk-core
- kactivities
- kdepimlibs4

just fine, but lets kde4-runtime quit with the same error message as libkdeedu before!

So, I think, this is what had to be expected with such a major change to qt4-mac (concurrent install) and needs clean-up in the respective KDE4 ports now.

[mkae (Marko Käning)]

Update: This seems to happen for all KDE4 ports which my machine has to rebuild itself. All binary ports installed are just fine.

Like when trying to install kdevelop just now kate and kdevplatform were installed no problem via their tbz2's, but kdevelop (since it doesn't might not be distributable) fails when trying to build...

Here's the file in question:

$ port contents kdelibs4 | grep FindKDE4Internal.cmake
  /opt/local/share/apps/cmake/modules/FindKDE4Internal.cmake

which is the location where it always lived up to now

So the KDE builds do not look up /opt/local/share/apps anymore, as I saw this in the build command:

-DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules

i.e. the subfolder apps is missing in between!

I wonder why this hasn't bitten the buildbots up to now.

[RJVB (René Bertin)]

Do the build bots even work still? They still haven't built the updated clang-3.6 and python-xy ports, at least not for OS X 10.9 ...

Anyway, ${prefix}/share/apps/cmake/modules has never been added explicitly to CMAKE_MODULE_PATH , at least it's not the case on my system running a more delicately concurrent Qt4 (and Qt5). I haven't traced what exactly goes on here, but it appears that KDE's CMake scripts have internal logic that adds components to the CMAKE_MODULE_PATH, including share/apps/cmake/modules. If those fail with Qt's change of install layout it is well possible that FindKDE4Internal.cmake is expected in a path that is derived from one of Qt's install paths, and thus now looked for in ${prefix}/libexec/qt/share/apps/cmake/modules.

Could you try to have a look what value KDE4_INSTALL_DIR has for you?

This may actually be one of the issues I ran into when I did try the simple blunt-force concurrency recipe of putting all of Qt in its own prefix (they were certainly KDE related), and it certainly does seem to support my argument against such an install layout that MacPort's Qt is used by software following Freedesktop/XDG conventions.

It may be that this particular issue is easy enough to correct by adding a component to CMAKE_MODULE_PATH in the kde4 PortGroup, but I wouldn't advise to do that as it may have side-effects. Looking at KDE's cmake script, I see cases where CMAKE_MODULE_PATH is modified temporarily, and restored to its previous value afterwards.

(I could have gotten to say "told ya" but this one I actually didn't expect =) )

[mkae (Marko Käning)]

Replying to rjvbertin@…:

Do the build bots even work still? They still haven't built the updated clang-3.6 and python-xy ports, at least not for OS X 10.9 ...

You're right! The Mavericks buildbot is not working ATM, i.e. rather say since quite a bit already, with more than 1000 builds pending... :-(

Could you try to have a look what value KDE4_INSTALL_DIR has for you?

Well, work/build/CMakeCache.txt does not contain that specific variable for kdevelop...

But there is this:

//Path to CMake installation.
CMAKE_ROOT:INTERNAL=/opt/local/share/cmake-3.3

//No help, variable specified on the command line.
CMAKE_MODULE_PATH:UNINITIALIZED=/opt/local/share/cmake/Modules

[RJVB (René Bertin)]

Which probably means it's an internal variable that is unset after it's been used (I have no idea how CMake decides what variables to cache in CMakeCache.txt).

For kdevelop, my CMakeCache.txt has

CMAKE_MODULE_PATH:UNINITIALIZED=/opt/local/share/cmake/Modules
KDE4_DATA_DIR:PATH=/opt/local/share/apps

So you have been able to install binary KDE4 packages, but do they run correctly? kbuildsycoca4 might be a good test, and /Applications/MacPorts/KDE4/kded4.app/Contents/MacOS/kded4 too.

[mkae (Marko Käning)]

I have this:

//Path to a file.
KDE4_DATA_DIR:PATH=KDE4_DATA_DIR-NOTFOUND

Replying to rjvbertin@…:

So you have been able to install binary KDE4 packages, but do they run correctly? kbuildsycoca4 might be a good test, and /Applications/MacPorts/KDE4/kded4.app/Contents/MacOS/kded4 too.

As had to be expected:

$ kbuildsycoca4 
dyld: Library not loaded: /opt/local/Library/Frameworks/QtDBus.framework/Versions/4/QtDBus
  Referenced from: /opt/local/bin/kbuildsycoca4
  Reason: image not found
Trace/BPT trap: 5

;-) (Nothing is working, due to invalid binary installs.)

---

I guess the way to go is to build kdelibs4 from the sources and forbid using binary port installs.

[RJVB (René Bertin)]

KDE4_DATA_DIR:PATH=KDE4_DATA_DIR-NOTFOUND

There you go, that can hardly be anything but a related issue.

dyld: Library not loaded: /opt/local/Library/Frameworks/QtDBus.framework....

That means you've downloaded an old binary package, which was built against "exclusive" Qt4.

It'd be interesting to see what happens when you build and install kdelibs4 from source, but somewhere I doubt that it'll correct the /opt/local/share/apps/cmake/module issue.

(Whew, finally got my reply in!)

For the record: you've been very kind giving me ownership of this ticket, and I'll try to help figuring out what is going wrong, but I'm not inclined to jump through all kinds of hoops to debug and fix a situation that should never have arisen in the first place.

I'm also convinced that there's a good reason why ${prefix}/share/apps/cmake/modules exists and FindKDE4Internal.cmake lives in there; I wouldn't meddle with that.

[michaelld (Michael Dickens)]

If this is a qt4-mac switch-a-roo issue, then I'll take ownership of it & work on fixing it. I didn't have KDE4 installed; am doing so right now, though of course in MP it has so many dependencies it'll take a while. Once I get dependencies installed I'll work on figuring out what's up -- you & René haven't already. I hate playing catch-up ... but, there it is. I'm building on 10.11.1 beta, so everything is from source for me!

[mkae (Marko Käning)]

Replying to rjvbertin@…:

There you go, that can hardly be anything but a related issue.

OK

That means you've downloaded an old binary package, which was built against "exclusive" Qt4.

Yes, the borked Mavericks buildbot is to blame for that.

It'd be interesting to see what happens when you build and install kdelibs4 from source, but somewhere I doubt that it'll correct the /opt/local/share/apps/cmake/module issue.

We'll see. Will report back once it has finished.

(Whew, finally got my reply in!)

Yeah, I also wonder what's going on with MacPorts' trac. I switched from Safari to Mozilla now, as it behaves better so far. Safari often couldn't submit or even show trac's pages in the last hour or two. :/

For the record: you've been very kind giving me ownership of this ticket, and I'll try to help figuring out what is going wrong, but I'm not inclined to jump through all kinds of hoops to debug and fix a situation that should never have arisen in the first place.

Well, I'm grateful for your feedback, but I can move you to CC, if you prefer so. When I filed the ticket I was completely lost and so will all KDE4 users on MacPorts feel when they upgrade their system, which is why I filed the ticket.

I'm also convinced that there's a good reason why ${prefix}/share/apps/cmake/modules exists and FindKDE4Internal.cmake lives in there; I wouldn't meddle with that.

I don't intend to meddle with anything. :)

[mkae (Marko Käning)]

Replying to michaelld@…:

If this is a qt4-mac switch-a-roo issue, then I'll take ownership of it & work on fixing it.

OK, thanks.

I didn't have KDE4 installed; am doing so right now, though of course in MP it has so many dependencies it'll take a while. Once I get dependencies installed I'll work on figuring out what's up -- you & René haven't already. I hate playing catch-up ... but, there it is. I'm building on 10.11.1 beta, so everything is from source for me!

Good, since I am on Mavericks.

kdelibs4 is destrooting just now for me.

[mkae (Marko Käning)]

So, after building kdelibs4 from source I have said cmake file at the expected location:

$ port contents kdelibs4 | grep FindKDE4Internal.cmake
  /opt/local/share/apps/cmake/modules/FindKDE4Internal.cmake

These also build fine from source:

- kfilemetadata
- mobipocket

but turns out that nepomuk-core already fails:

:info:configure -- Detecting CXX compile features - done
:info:configure CMake Error at /opt/local/share/apps/cmake/modules/FindQt4.cmake:1239 (MESSAGE):
:info:configure   Qt qmake not found!
:info:configure Call Stack (most recent call first):
:info:configure   /opt/local/share/apps/cmake/modules/FindKDE4Internal.cmake:425 (find_package)
:info:configure   /opt/local/share/cmake-3.3/Modules/FindKDE4.cmake:108 (find_package)
:info:configure   CMakeLists.txt:14 (find_package)
:info:configure
:info:configure
:info:configure -- Configuring incomplete, errors occurred!

[RJVB (René Bertin)]

In other words, kdelibs4 does not alter its paths as a function of the local environment, and installed FindKDE4Internal.cmake to the same location as where it was.

What about KDE4_DATA_DIR?

And what about kbuildsycoca4, does it run now (the dyld error should be gone, but will it find everything it looks for...)?

[mkae (Marko Käning)]

Replying to rjvbertin@…:

What about KDE4_DATA_DIR?

No change compared to comment:5.

And what about kbuildsycoca4, does it run now (the dyld error should be gone, but will it find everything it looks for...)?

Yep, that runs now - as had to be expected.

[michaelld (Michael Dickens)]

I'm finally building kdelibs4 right now.

[michaelld (Michael Dickens)]

kdelibs4 installed fine. Moving on to kde4-runtime, and its dependencies.

[RJVB (René Bertin)]

For the record, ${prefix}/share/apps/cmake/modules contains a lot of CMake files. My port provides command is dysfunctional, but it's clear that they're far from belonging all to KDE4 or Qt.