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

[Jonathan Schultz]

Hi René,

OK I think we can almost put this thread away, and start a new one. :)

With your latest fixes I am now able to build kf5-okular-devel and run 
it both natively and using X11. As you predicted, the PDF rendering 
worked fine when using xcb but not when running natively. I have to 
confess this does surprise me - I was under the impression that 
Virtualbox provided OSX with virtual hardware that was indistinguishable 
from real hardware. But when I get a chance I'll do some experimentation 
with display settings and see what I come up with.

Best,
Jonathan

On 10/04/16 19:39, René J.V. Bertin wrote:
> On Sunday April 10 2016 10:44:28 Jonathan Schultz wrote:
>
>
>> What exactly is the difference between the basic port and the
>> -devel subport? Should I be trying to install the kf5-okular-devel
>> subport rather than just kf5-okular?
>
> The -devel ports are typically used for pre-release versions, of the
> software or the port implementation. For instance, qt5-kde-devel
> currently contains Qt 5.6.0 (vs. 5.5.1 in qt5-kde) but is also used
> as a test-bed for new patches or build options.
>
> If you look at `port info kf5-okular` you'll see the message that
> Okular doesn't have a KF5 release version yet (to my knowledge). Once
> you get to the point where MacPorts is actually going to fetch the
> tarball you'll get an error instead. It's a bit unfortunate that this
> doesn't happen immediately, but since the -devel port has the same
> dependencies the preparatory efforts will not have been wasted.
>
>> OK so while installing gtk3 (I have no idea why it tries to
>> install gtk3!) I see:
>
> Interesting, I don't see gtk3 as a recursive dependency of
> kf5-okular, but `port rdeps` doesn't necessarily show all kinds of
> dependencies (not the build nor the runtime deps, IIRC).
>
> ...
>> How does this work? Is not version @1.40.0 clearly more recent
>> than @1.36.8_1?
>
> Yes, but MacPorts will simply take the preferred port, where
> preference is a priority consideration that depends solely on the
> order in which you define sources in sources.conf .
>
>> And as for transparently ignoring an explicit request to install a
>> particular version, I don't know what to make of it. Surely at
>> least a warning that for whatever reason it cannot install the
>> version I requested is called for?
>
> No. MacPorts does not currently provide any means for ports to depend
> on specific versions of other ports, nor on specific variants (other
> than potentially raising an error). This is more or less by design as
> the opposite wouldn't (easily) allow for another very useful feature,
> that of de/activation. In other words, you can keep multiple versions
> or variants of a port installed, and decide which one to activate.
>
> There's another side-effect: variants (user-requested and "default"
> ones) percolate down the dependency tree even if they aren't
> required. That in turn can cause additional dependencies to be pulled
> in. For instance, a port depending on Qt may have a dependency on
> some X11-related port B which has a X11 variant that is active by
> default (because the port is mostly used for X11 software). Of course
> you can install B with `port install B -X11` to get the version that
> doesn't contain the X11-specific bits. Of course that Qt port cannot
> declare a dependency on "B -X11", so the automatic dependency
> resolver will pull in "B [+X11]" (B with the default X11 dep) and
> thus also everything required to build and use that X11
> functionality. If you don't want that, you need to install "B -X11"
> manually before installing the desired port ... or afterwards (and
> then uninstall the unneeded stuff).
>
>> I have no idea. I didn't it to build okular for either Linux or
>> Windows so it's not clear why it should be needed under OSX. Does
>> this help you at all:
>
> I found it
>
>>> --->  Dependencies to be installed: mobipocket
>
> Yep. `port rdeps kf5-okular` also showed that kdelibs4 is needed by
> mobipocket (kdegraphics-mobipocket). It doesn't look that there's a
> way to build that without depending on kdelibs4 . Strange in fact,
> because libqmobipocket would depend on Qt4, and one is not supposed
> to mingle Qt4 and Qt5 in a single application?!
>
> Maybe you have some idea about this little problem?
>
>> I have no such file, but I do find a file
>> /opt/local/lib/cmake/KDE4/grantlee.
>
> Ah, stupid me. That's port:grantlee we're talking about, the Qt4/KDE4
> version. I'm not sure why you'd need to install that one either, what
> does `port dependents grantlee` tell you?
>
>> Sorry to be such a noob but don't know how to determine this. I
>> can
>
> `port dir grantlee`
>
> Cheers, René
>