[KDE/Mac] No luck with building KF5/Frameworks

[René J.V. Bertin]

On Sunday March 22 2015 15:32:20 Ian Wadham wrote:

morning
>
>Q2. Was adding -force-pkg-config OK?  It does not seem to have done any harm.

I also found I had to use that option, so I guess it's OK (in the sense we'll have to live with it ;))

>Then I had a hunch.  On examining all the cmake and build logs carefully, I found
>that occasionally a Qt4 header from MacPorts was getting into the act, even though
>I was pointing kdesrc-build at <my-prefix>/qt5/qtbase.

I saw a statement from Boudewijn Rempt on the Calligra ML that 
> you cannot have both a kde4 and a kf5 development system unless
> you do some weird stuff

which *could* be the explanation of what you're seeing. Except that I'd be very surprised if KF5 doesn't build with Qt4 headers present. My only experience with building KF5 applications to date is using Ubuntu's Project Neon 5 (RIP), but that has all of KF5 in a separate tree. Yet the compiler would still see headers in /usr/include (I guess). I do have a Kubuntu  "Vivid Vervet" VM but I'm using that as little as possible because frankly it only gives me an increasing aversion of KF5.

I'm CC'ing David in hope he can shed some light on this particular aspect. It'd evidently be a real stopper if Boudewijn's statement were true in its most literal and basic interpretation.

>So I ran "sudo port deactivate" on qt4-mac and all of its direct and indirect dependents,
>which is to say a large part of the software I use day-to-day, including kmymoney4

Are you still using the stock/standard/"exclusive" port:qt4-mac? I cannot remember where it put the header files, but if that was directly into /opt/local/include it'd be a likely explanation for the mix-up.
And in that case I'd advise you to grab the port dir tarball for the concurrent qt4-mac I refreshed on trac yesterday and install it as well as qt4-mac-transitional (so you don't have to rebuild everything depending on Qt4 at once).

>Q4. Is there some way I can avoid having to deactivate all my regular KDE4/Qt4
>       software?  I am not at all comfortable doing that… :-( … my tax return is due.

First of all, you're not obliged to deactivate all Qt4 ports. You can just force-deactivate qt4-mac. Depending on how KMyMoney works you might even get away with doing that while it runs (given how Unix file "unlink" works).
Alternatively, just remove the Qt4 headers. By the time you get to building KDE4 software again you just force-deactive qt4-mac and activate it again. Or you extract just the headers from the tarball in /opt/local/var/macports/software/qt4-mac.

>Q9. Is that the correct version of libepoxy?  Can it be mentioned in the kdesrc-build scripts
>       or https://community.kde.org/Frameworks/Building?  Libepoxy on MacPorts has
>       dependencies mesa and xorg-xproto, but isn't Frameworks/KF5 supposed to be
>       free of X11 and other graphics systems?

I had a similar question yesterday when I saw that kde4-workspace would pull in GTk2 and GTk3.
Turns out those are not direct dependencies, but come in through (IIRC) port:ffmpeg and port:ImageMagick.
This is the reason why Debian (and company) split packages.

>Our old friend QSP made a brief appearance in some of my build attempts.  It appears
>that the Frameworks/KF5 build installs some files in application data directories, as you
>might expect, but then the building of later modules (in the same run) invokes programs
>that call QSP to find some of the files installed earlier.  I got around errors by forcing the
>install dirs and QSP dirs to "line up", using Jeremy's QSP patch and $XDG_DATA_DIRS.
>
>Q10. Is the Frameworks/KF5 build inherently biased towards an XDG setup or can it
>       actually be made to work with "native" QSP on non-Linux platforms?

As I've said earlier, I think that's a question to be put off until we have a working KF5 build with some version of the QSP patch (read, the QSP patch patched until building KF5 works, with XGD/Linuxy locations).

>For some reason, the phonon part of the build requires both the VLC and the GStreamer
>backends to be built in Frameworks/KF5.  Phonon succeeds, but both backends fail to
>build, in my setup.  One reason is that I have a downloaded VLC installed, not the
>MacPorts one.  I am reluctant to change that, because I use VLC for presentations, etc.
>And I do not really want to install GStreamer just to please Phonon.
>
>Q11. Any ideas on a workaround for building Phonon?  Do we really need it anyway?

Does "it" actually find your "downloaded VLC"? I'm guessing even if it does it would be useless, as VLC's internal "QSP" code has the hardcoded assumption that the executable lives in VLC's Contents/MacOS directory.
I uploaded a port for VLC 2.2 that also allows you to build just libVLC, and I can build the Phonon VLC backend against that; both the Qt4 and the Qt5 versions.

There is however an issue currently in KF5 with the VLC backend, on Linux at least. It appears you cannot have both the Qt4 and the Qt5 VLC backends installed, because it apparently gets loaded dynamically and (braindead?) applications can load the wrong one. It took me a while to find the explanation, but that's why KF5 Konsole crashes when you hit Tab ...
This could be an explanation why the GStreamer backend is compulsory?

>Finally, networkmanager-qt fails in CMake because there is no Network Manager.

Nor will there ever be, I think?

>I am getting awfully sick of trying to build Frameworks… :-(

I hear you. I'm already rather sick from just trying to use the stuff. It reminds me too much of OS X 10.1 and 10.2 ... but those at least were full of good intentions (and replaced an obsolete OS with a modern Unix-based one). If I didn't know that Qt4 was more or less doomed I'd leave KF5 to the same audience that gloats over the latest and supposedly greatest Gnome3 stuff and that knows nothing more orgasmic than installing yet another new desktop. It took me a while to learn (I was young too, once), but "better is the enemy of good", "if it ain't broke don't fix it" etc. ...
I know that sounds harsh, but my main interest is not the development of all kinds of new features (I didn't knew I wanted) in KF5. My interest, and of a lot of us on here I think, is to be sure that at some point in the future we can use the KF5 versions of the KDE4 applications we now use - and in my case at least, with as little visible/UI change as possible. Continuity is good ;)

R