[KDE/Mac] Developing KDE on Mac

John Layt johnlayt at googlemail.com
Fri Aug 13 23:21:00 CEST 2010


On Friday 13 August 2010 08:51:22 Mike McQuaid wrote:
> 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.
> 
> Thoughts?

Having read all the thread so far, and last night looked at the MacPorts 
patches and wondered "Why???" here's my thoughts as a 'core' KDE developer.

If we claim to support a platform, then the KDE modules should build and run 
out of the box on that platform, no extra patches required.  For the Mac 
project to eventually make that claim means _all_ patches need to be in 
mainline, there should never be patches required by MacPorts or Fink.  People 
shouldn't have to go looking in other repositories just to get things to build 
and run, svn.kde.org is the canonical source.  This may mean some parts of KDE 
are just not built or certain features are disabled until such time as a 
'good-enough' solution is coded, but release branch should always build and 
run.  If a crude hack is required short-term, then so be it so long as we know 
there's a more correct solution coming and the hack is not actually causing 
harm.  Patches in Macports/Fink are OK as a short term fix or experiment, but 
should never be seen as a long-term or permanent solution for anything.

This is as much about visibility as anything, if something is ifdef'ed out and 
marked as not working on Mac, then it is more likely the maintainer (or any 
other interested party with the ability to do so) will pay attention and help 
fix the issue.

Reviewboard now makes submitting patches even easier to do, and really easy to 
track what has been accepted and merged and what still needs work.

I would suggest your first course of action would be to progressively feed all 
the outstanding patches into mainline.

As for packaging, I'll leave that to you the platform experts to sort out, but 
personally I do agree with the general principle that we should at least 
appear to the user to be using the standard platform installation method they 
are most familiar with, or failing that the simplest method possible.  The 
Windows installer is a great tool, but far too complex for the average user.  
My other point is telling people to wait 48 hours while MacPorts/Fink compiles 
all the dependencies is just a no-go, binary installs are the only option.

Cheers!

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-mac/attachments/20100813/658f2b6c/attachment.htm 


More information about the kde-mac mailing list