[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