[KDE/Mac] Developing KDE on Mac

Sjors Gielen mailinglist at dazjorz.com
Fri Aug 13 13:46:16 CEST 2010


Op 13 aug 2010, om 09:51 heeft Mike McQuaid het volgende geschreven:

> 
> On 12 Aug 2010, at 18:19, Sjors Gielen wrote:
> 
>> You should probably report build errors in the MacPorts packages to the MacPorts packagers of KDE, not to the KDE-on-Mac lists. Their packages are, of course, meant to work right away.
>> 
>> KDE4 is, by the way, according to the #kde-mac topic, more up-to-date in Fink (4.4.0 versus 4.3.2). I actually even intend to write a script someday for KDE4 nightlies in Fink; this may or may not already exist in MacPorts.
> 
> 
> Sorry to slightly derail this thread but is no-one else irritated at the fact it's nearly impossible to get a working KDE on OSX build running without using MacPorts or Fink? Until recently (and possibly still is still the case) if you compile on 10.6, KDELibs will segfault immediately on startup. MacPorts and Fink have a patch for this (and I reluctantly added it to Homebrew) but this hasn't gone upstream (last time I checked) so anyone compiling from source will find KDELibs hasn't worked for a while.
> 
> It would be good, at some point, to try and do a roll call of KDE on Mac developers and see if we can't form more of a team effort to get the platform a bit easier for people to get started with. I keep trying to do stuff myself (and for Homebrew) but get frustrated and give up for a while.

I've been thinking about this and while it seems a good idea at start, I nowadays don't think it's the way to go. Of course it's true that the packages should be compilable and should work on first install, but when you consider the amount of work needed for dependencies, keeping everything up to date and all, installing a package manager like Fink or MacPorts is really *way* easier than compiling an installing KDE from source yourself. So much for the easiness factor, which is for most of us not the most important factor.

The second one is the dependencies I already named. Point is: when KDE needs dbus, who installs dbus? It's not shipped with the operating system. If the user has to compile and install that himself *too*, along with the ± hundred other dependencies of KDE, it makes the system dirtier with non-updated deps, and that could eventually also have negative effects on the quality of the system. (I'm not even talking, here, about dependencies which are by default uninstallable on Mac. Most projects care about that - but I've seen projects reject patches because they didn't want to have the additional maintaining burden of supporting another operating system.)

All in all I definitely think we should come together and improve the situation of "vanilla" KDE on Mac, but I think we should strongly advise against compiling and installing yourself, unless you really know what you're doing (for example, a KDE developer who has everything in Fink/MacPorts and simply wants to build kdewhatever for himself). We should then, in my opinion, have a policy of sharing patches between Fink and MacPorts and also submitting them upstream if that makes sense. First thing to do is update the horribly outdated set of pages at http://mac.kde.org/, by the way.

One thing that has been crossing my mind since aKademy is a KDE on Mac installer. The Windows dudes have done this and it's been working out great - but they don't have a package manager and we do. I've been thinking about creating an installer that, after some basic system checks and asking the user what he wants, installs Fink or MacPorts, configures that, then proceeds to tell the package manager to install KDE. It could become a KDE-oriented "front-end" to Fink and MacPorts, also alerting the user of updates now and then.

Does this make sense?

Sjors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2525 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-mac/attachments/20100813/1e917b26/attachment.p7s 


More information about the kde-mac mailing list