[KDE/Mac] kde-mac Digest, Vol 76, Issue 7

[Jonathan Schultz]

> That ought to be fine. I suppose you installed the MacPorts release
> version (2.3.4), not a development version from SVN?

Yes that is correct. Is it worth trying a development version?

> Maybe it might help if you executed the portindex command once more
> (`(cd /opt/local/site-ports ; portindex)`).

I tried that (after pulling your changes). What I got was a number of 
failures, including qt5-kde-x11:

> Error: You cannot install a Qt5-KDE port with port:qt5 or one of its
> subports installed!

so I looked around for the source of that error message and made it go
away by removing the (empty) directory /opt/local/libexec/qt5/plugins. 
But then I got a different set of error messages like the following:

> Failed to parse file audio/phonon/Portfile with subport 'phonon-qt5':
> could not read "/opt/local/libexec/qt5/plugins": no such file or
> directory

OK so I figured my installation was all messed up so I saved it for
future reference, reverted to a virgin Mavericks and started again.
But even now I get the same issue, ie some ports require the directory 
/opt/local/libexec/qt5/plugins to be present, and others
fail if it is present. That is, if I just follow the normal procedure I get:

> Failed to parse file aqua/qt5-kde-devel/Portfile: could not read "/opt/local/libexec/qt5/plugins": no such file or directory

but if I manually create /opt/local/libexec/qt5/plugins I get:

> Failed to parse file aqua/qt5-kde-devel/Portfile: Qt5 PortGroup mismatch

> Which brings me to another potential explanation: you already
> have/had port:qt5 or a number of its subports installed. That's an
> error situation I didn't yet handle; the update I pushed does that
> too.

Having restarted with a fresh mavericks installation I can rule out that 
as a source of the original problem.

> I'd add that you'll be getting a Qt5 that's patched to ensures that
> KF5 applications expect (and find) their shared resources in
> XDG-compliant locations like /opt/local/share, ~/.local/share,
> ~/.conf etc.

Yes I can see that will become quite important down the track.

> I would advise using my cmake PortGroup file too as it contains a
> number of modifications that are optional but IMHO convenient for
> (port) developers.

Plus the help desk! :)

>> be trying. Would it be worth testing under El Capitan for example?
>
> I would appreciate testers on 10.11 to have a better idea what works
> or breaks on that version, but I'd guess you have different
> priorities. OTOH, if you really aim to develop your application for
> OS X too, it'll be up to you to decide whether you want to support
> older OS versions, or only the current version and beyond. In the
> latter case you'd be better off starting with 10.11 immediately.

I'm happy to try it on a few different versions. Though my first 
priority is to get it to work on any version!

>> just prefer Mavericks because it does a better job of handling
>> non-standard screen dimensions
>
> Oh? That surprises me (though a lot less than it would have a few
> years ago). How so?

I'm not really clear on the underlying reasons, but from what I can 
determine with when running El Capitan, Virtualbox is only able to 
provide a series of predefined screen resolutions, whereas with 
Mavericks it is possible to set a custom resolution. Actually come to 
think of it that might be because you can't run vanilla Mavericks at all 
but need to use some Hackintosh version. I've never worried about it too 
much, but since I have a slightly unusual screen (1680x1050) I found 
that with El Capitan I had to choose between undersize (1440x900) or 
oversize (1920x1200).

> It would have been just as easy on "real silicon" if Apple had made
> good on their idea of using ZFS ;)

Just fork it ;)

>
> Cheers, René
>
Cheers Jonathan