[KDE/Mac] Fixes for Filelight utility and LSkat game

[Nicolas Pavillon]

Hello, 

On May9, 2014, at 22:42, Ian Wadham <iandw.au at gmail.com> wrote:

> Thanks for the offer, Nicolas.  But I don't think I would know what to do with
> the Portfiles.  I am a very run-of-the-mill MacPorts *user* - not in any sense
> a MacPorts developer.

I don’t think it would be really required to play around with Portfiles, as I think I 
should have them sorted to a major extent up to kde4-baseapps (so not the extension
packages *-utils, *-games and so on, but they are usually easier if the base is there).
It would essentially just require to set up a local repository, which is supposedly simple:
https://guide.macports.org/chunked/development.local-repositories.html
and then use the new Portfiles to install the ports while using the existing
Macports libraries, which may solve some of your issues.

> On Apple OS X, I keep running into this problem where the same library
> is in both /usr/ and /opt/local/ and some libraries are only in one or the other.
> I am relying on MacPorts to provide most of the dependencies and libraries.
> So I set -DCMAKE_PREFIX_PATH=/opt/local for CMake, but some KDE modules
> require -DCMAKE_PREFIX_PATH=/opt/local:/usr and even then CMake
> sometimes seems to pick up from /usr when the same thing is in MacPorts.

Yes, I am not completely sure about how CMake works on this matter, but I think
there are also default places where it looks for libraries. I experienced cases where
I found simpler to just hardcode the path of the libraries I wanted to use instead of 
trying to deactivate the unwanted paths in the find_* macros.

> There is also a non-portability in baloo, which I patched around (malloc_trim()
> is not in /usr/ - it is a GNU extension).

Yes, I had missed the reviewboard link you provided later in the mailing list, and also 
had filed a ticket about it: https://bugs.kde.org/show_bug.cgi?id=333874.

> Currently kde-runtime, kde-workspace and kde-baseapps fail to build.
> kde-runtime is getting a linker error in kglobalaccel (keystroke and shortcuts
> handler).
> 
> Linking CXX executable kglobalaccel
> Undefined symbols for architecture x86_64:
>  "GlobalShortcutsRegistry::keyPressed(int)", referenced from:
>      hotKeyEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) in kglobalaccel_mac.o
>      KGlobalAccelImpl::keyPressed(int) in kglobalaccel_mac.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)

This error is not KDE 4.13 specific, we had it for some time (I think it appeared at
4.12). There is a fix in Macports to circumvent it. However, it is not a simple patch, but 
a post-configure hack, which can be applied manually, although it may be cumbersome. 

> Note that I have a MacPorts installation that I use for everyday activity
> so I do not want to risk messing that up.

If you don’t need them simultaneously you could keep the two installation around,
and use activate/deactivate commands to have the one you want at a given time. 
For simultaneous use, having two separate Macports tree may also be possible, 
but it is signing for trouble in my experience.

> I also have KDE code which I develop in a special area and it is linking to
> MacPorts kdelibs4 for KDE 4.12 ATM.  The kdesrc-build thing is in yet
> another special area.
> 
> Is the problem with kde-runtime easily solved?  If not, is
> there some way I could set up a separate MacPorts and build
> KDE 4.13 stuff?  Where would MacPorts get the source from?

As Macports keeps the inactive ports around, you could surely have 
both, which could be just activated/deactivated depending on the need, 
which just implies some files copies. Portfiles also use various KDE
repositories to get the sources, and the Portfiles I have are set for the 
new sources tarballs. 

Cheers, 

Nicolas