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

[Ian Wadham]

Hello Nicolas,

Thank you for your prompt and helpful response.

On 10/05/2014, at 3:31 AM, Nicolas Pavillon wrote:
> 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.

Thank you very much.  I think I could handle that.  Please send me a copy
of the Portfiles as soon as is convenient.

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

Well I was close, but no cigar … :-)

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

That should be doable.  At some stage I may need to play with some of the KDE
library source code (e.g. to put in log messages when chasing a bug), but I think
I will be able cross that bridge when I come to it.  ATM I need a base to start from.

KDE 4.13 is preferable because, if I use 4.12 and find and report a bug, the first
thing the KDE developers will ask is if the bug also occurs on 4.13 … ;-)

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

I can't wait to get started!  Thanks again, Nicolas.

All the best, Ian W.