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

[Ian Wadham]

Hi René,

On 22/03/2015, at 7:51 PM, René J.V. Bertin wrote:
> On Sunday March 22 2015 15:32:20 Ian Wadham wrote:
>> 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?

Yes, along with stock-standard KMyMoney… :-)  I am not going to mess with my livelihood.

> 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.

They are at /opt/local/include/Qt/q*.h and a few in /opt/local/include/Qt* (no .h, e.g.QtCore).

> 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).

As said in another email on this thread, I might try CMAKE_INCLUDE_PATH.  Also, it is
possible that the Qt4/5 mixup only occurs in the preliminary builds (polkit-qt-1, etc.) and
not the builds that are part of Frameworks itself.  I might test that hypothesis too.

>> 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.

Yes, something else to try…  I don't like fooling software unless there is no other way.
Inevitably the day comes when I forget I have done it and then it bites me in the bum.

>> 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).

I agree.  In fact I will probably patch the patched patch to add the XDG_*_HOME variables,
so that there is no risk of overwriting "live" user-data and user-config files.  But still, we need
to look ahead, to arrive at a definitive QSP solution.

>> 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?

Hmmmm.  More to explore… ;-)

>> Finally, networkmanager-qt fails in CMake because there is no Network Manager.
> 
> Nor will there ever be, I think?

Ah, good, one less thing to worry about on OS X… :-)

>> 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. …

LOL (gently, to myself).  I think the only wise thing I heard a politician say was, "There are
two kinds of fool in this world: one who says, 'This thing is old, therefore it is good', and the
other who says, 'This thing is new, therefore it is better'".  Harold Macmillan, former British
Conservative Prime Minister.

Fortunately, I heard that before I ever got into computers.  Otherwise my blood would have
have ended up on the "blade" or I would have over-specialised myself into obsolescence
several decades ago, like some Cobol and Algol programmers I used to know.  BTW I used
to write Cobol sometimes, but only because it helped to sell mini-computer applications and
systems to big businesses with loads of cash… :-)

> 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 ;)

Absolutely, my sediments precisely… :-)  I like this quote from
https://techbase.kde.org/Development/Tutorials/Services/Plugins

    'Before starting with the code let's see which advantages we can undertake developing
     a plugin structured application. First of all an application capable of managing plugins
     can extend its features with apparently no limits. Anyway, rather than developing a
     plugin structured application because "it's so coool!!" the developer should think about
     the real advantages of this kind of development.'

I wish more KDE developers would think that way.  Their code would be so much easier
to "port" to OS X if they did.

Regardless of that, we are stuck with Frameworks/KF5 and Qt5.

The alternative strategy would be to ignore KF5 and get the existing KDE 4 apps working
properly on MacPorts and OS X, whether or not we have support from the "cool" guys.

Eventually, after a year or two (or three), tempting new features might appear in the KF5
versions of those apps and we might be forced to change.  More likely, apps that used to
be "cool" will be dying for lack of maintenance and being replaced by new "cool" apps,
as with Konqueror and Kopete today IMO.

It's tempting...

Cheers, Ian W.