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

[René J.V. Bertin]

On Tuesday March 24 2015 20:48:54 Ian Wadham wrote:

Hi Ian,

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

The good news with installing the now-concurrent version of port:qt4-mac plus qt4-mac-transitional is that nothing changes from the point of view of all your installed Qt4 and KDE4 applications. They only need the Qt4 libraries, and they'll find them (just through an additional symlink).

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

We're talking about header files here. They're used only when you build software, and that bite in your bum will be very easy to diagnose and remedy (= reinstall the headers). Linux systems do this systematically nowadays: you only install the headers for things like Qt when you're going to do development.

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

I'm not sure we need XDG*_HOME? I thought I'd compared the locations generated with my latest patch with the ones I get on KUbuntu 15.05RC (with the Plasma5 desktop), and they match.


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

And I've learned to prefer NOS in many contexts :))

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

That's one with a nice (seeming?) contradiction inside ...

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

Which is what I'm continuing to do.

The real alternative I see (but too formidable a task maybe even for "the all of us") is to make a new Trinity desktop. FYI, Trinity is KDE3 continued. In this case we'd be talking about porting KDE4 from Qt4 to Qt5 as an alternative to KF5. I'm a bit surprised that I haven't yet caught wind of others considering this, but that might only begin to happen once enough people who don't like living on the bleeding edge find themselves putting up with a desktop environment they no longer feel at home in.

>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

No, eventually we'd have too many issues building Qt 4, and that might happen sooner on OS X than elsewhere.

>be "cool" will be dying for lack of maintenance and being replaced by new "cool" apps,
>as with Konqueror and Kopete today IMO.

What's with Konqueror?

> > Yes, it should be, but sooner or later you again run into dependency on
> > some X11 thing. With libepoxy-devel I tried to get KF5 again X11-free,
> > though, successfully! :-) Yet, when I came to have to install opencv for
> > libkface, all X11 stuff came back for me. :(> 
> Sounds like that is a problem in MacPorts, bringing in excess dependencies.

I think I already mentioned this in this thread, but those are indirect dependencies. Build dependencies if you like, like the dependency on GTk2 and GTk3 I noticed in some KDE4 ports because they depend on (X11 independent) libraries from things like ImageMagick which also provide X11 functionality. It doesn't mean you have to have X11 running when you run your KDE application.
It does mean that users will potentially have to sit through the build of huge packages if they cannot be distributed in binary form.

R.