[KDE/Mac] KF5 on OSX

[René J.V. Bertin]

On Wednesday September 16 2015 02:54:49 Marko Käning wrote:

Hi,

Well, as I said, I'll be starting to sniff around your efforts these days. If there's a portfile that already takes care of pulling in a good number of KF5 dependencies that's good; I'll just have to look at the order in which that's done.

One thing that I'll apparently have to do myself since no one has stepped up to offer help is to figure out how to activate the "XDG-ish" mode of my QSP (QStandardPaths) patch. Remember that in its current implementation, this patch just adds the possibility to toggle QSP behaviour by creating a global/static instance of a special object that flips the QSP mode switch in its ctor. The reason for that is that we are (or at least, *we* were at some point, *I* still am) aiming to have a single Qt5 install that can do both OS X QSPs and XDG-ish QSPs, without requiring a run-time toggle.
In other words, in absence of a preexisting common module, I'll have to find a way to add a common link-time module (that just flips that switch) to all applications. Or if that's not feasible, another way to flip that switch :-/
Thinking aloud, that might actually be possible with a dedicated Qt mkspec that adds something to Qt's CONFIG.

>… you could just try to start with “frameworkintegration”:
>---
>  $ sudo port install kf5-frameworkintegration

       ^^^ that I won't be doing. You may recall I have the MacPorts build user set to myself, but even with that I prefer to decompose the installation of ports I'm working on. Anyway, you mentioned certain issues with where things are installed, so I plan to look port-by-port at the destroot before installing them.

About that: do you know if all your ports at least install things more or less correctly in the destroot phase (i.e. somewhere under `port work foo` and not under ${prefix})?

>Well, all 62 frameworks are pre-defined and thus you shouldn’t run into trouble if
>you try to build KF5 applications now, as long as you set the correct dependencies.

I agree that ultimately we'd want the smallest set of dependencies per application in an ideal world, but for starting one can use a few meta/umbrella ports for that and figure out afterwards what the real dependencies are, once things work.
That said, we'll probably also want to avoid having to adapt unknown numbers of Portfiles each time something changes in the KF5 frameworks; it could be a good idea to come up with a manageable set of categories that each "contain" a reasonable number of frameworks.

>Alternatively you could make sure that *everything* is built (almost) in the right
>order by using the tier-install.sh script like this:
...
>which will re-generate all the Portfiles though, but also initiate their installs. :)

Is there a reason to stick with auto-generated Portfiles, or can we start polishing the current set of Portfiles (with the accompanying PortGroup)?
It would probably be good though to have a script that can re-do the auto-generation; is it possible to do that *without* building and installing?

>>> - I don’t think kate failed. It simply did. ;-)
>> Smartpants, you know what I meant!
>
>No, honestly, I didn’t inspect the reason for this. =) Had no nerves for that!
>  $ open /Applications/MacPorts/KF5/kate.app/Contents/MacOS/kate
       ^^^^ no need for open when you're launching the appbundle executable.
In fact, you'd better NOT use it, because it means all output goes to system.log . It's not unlikely at all that your crash is in fact an abort that first prints a message (i.e. a call to qFatal()).
(which also reminds me I have to check my patch that's supposed to let that message appear in a popup message, but doesn't always.)


>That would be sad. A systemsettings5 would be a nice thing to have, as it is essential
>for KDE4 on MacPorts.

I agree, but my impression is that the workspace framework has been "composed" without (much) consideration for non-X11ish platforms. I hope I'm wrong there.

>> Hmm, is that enforced in ways other than that there can only be 1 kate/kdevelop/kbamboolah
>> in the same binder?
>
>You ask me? ;)

No, well, not *just* you ;)

>> Under MacPorts most applications will end up in /Applications/MacPorts/KF5 (or maybe
>> we'll call it KDE5 :)) so as long as shared libraries and plugins/kparts/etc are
>> coinstallable the applications might be too.
>
>Testing required, yes.

We'll notice soon enough. Port will complain when installing something that already belongs to an installed port, and if that doesn't happen we'll see how well co-installed KDE4 and KF5 versions run...

>clearly defined, it shouldn’t be a problem to get them easily into Portfiles of dependent
>ports.

As long as they don't require whole lists of patches and other adaptations, yes.


>For “kf5umbrella” I haven’t yet created a meta-port “kf5-kf5umbrella” enclosing all KF5.

I'd vote for kf5-foo instead of kf5-kf5foo. Maybe too much work for your portfile generator script? ;)

In any case, a port like that would need to be able to do all those steps (at least patch, configure, build, destroot) separately. You'd have to be able to have an extract step that prepares the ensemble of frameworks to install, and then be able to apply the appropriate patches [stop], configure that ensemble [stop], build it [stop], destroot it [stop] and finally install it. I guess that it might be acceptable to have a portfile invoking a script that does a whole bunch of things that lead to an install in the destroot (which is compulsory), but how are you going to apply patches in that case?

>Got far too late tonight… :-(

Doesn't it always? :)

>As you can see such a Portfile is rather small, since all functionality is hidden in
>the kf5 PortGroup, making use of these variables:
>
>	kf5.project
>	kf5.framework
>	kf5.portingAid
>
>	kf5.virtualPath
>	kf5.release
>
>which control the setting of various internals needed for a correct Portfile definition.

I don't think the (any!) PortGroup should contain anything but definitions, i.e. no {pre-,,post-}{extract,patch,configure,build,destroot} steps. I guess I'll see whether that's the case or not ... and whether all those variables are sufficiently documented ;)

Cheers,
R.