[KDE/Mac] Developing KDE on Mac

Fri Aug 13 16:18:21 CEST 2010

On Fri, Aug 13, 2010 at 8:46 AM, Mike McQuaid <mike at mikemcquaid.com> wrote:
>
> On 13 Aug 2010, at 12:46, Sjors Gielen wrote:
>
>> 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.)
>>
We install the deps. We update the deps required.
That's how dad did it, that's how his dad did it, and it's worked out
fine for me.

>> 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.
>
> When doesn't it make sense to share patches upstream? If Fink and Macports are sharing them and you don't recommend people install from source these patches should all be upstream.
+1

> I agree with Fink/Macports being better for most developers. Most people don't install all their dependencies from scratch on Linux either but people do install Qt and KDE and, currently, this isn't possible on OSX without patches which are in Fink or Macports. This is a bad situation. I don't think the solution is sharing patches, I think it is for Fink/Macports to try and be a bit more responsible open-source citizens: actually push patches back upstream. Yes, it takes effort but that's kind of the point of open-source.

Speaking as an ex-macports packager, I have to say it takes
practically no extra effort to push patches upstream. I email them to
a dev list and the developers either accept it or not. Therein lies
the rub however. If the patch is "poor" it won't be accepted and
unless I get help I'm not going to try to fix it as it works for me.
"Extra effort" on my part would be learning (more of) a programming
language on my time, which AFAIC is a no-go (some will, some won't).
However, there are actual programmers who do use both
kde-mac/fink/macports/homebrew.
If they would take a look at the patches and fix the hacks the
packagers put in (or work with them on fixing them) this seems
something which would be worth doing. I'm just speaking personally on
what would work for me though ...

> I'm trying hard to push the launchd patches upstream to D-Bus but it's a huge pain and it's taking time. However, though, it will be worth it as it means we get closer to the situation of sensible binary distribution. More on that later.

I'll hold my tongue.

>> 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.
>
> This is exactly what I'm trying to avoid. On Windows their "installer" is a package manager that they wrote from scratch. If we want KDE on Mac (or indeed KDE on Windows, quite frankly) to ever catch on with non-technical and non-Linux users who have to use Mac/Windows on occasion, then we need to start bundling our software the way people expect it to be distributed.
I recommended the package manager to a relatively techie windows
friend of mine to install amarok. He never got it working. If it's not
using the native installer framework of the system (or something far
better/intuitive) I think it's going to fail.

> Fink/Macports/Homebrew are great tools. However, no non-developers I know that use a Mac use them. Hell, most developers on OSX who aren't doing open-source development don't even use them.
>
> What our end-goal should be is a nice DMG with a PKG or droppable .app file with autoupdate support and all the trimmings people expect. On Windows, in my opinion, it should be a MSI or NSIS installer that doesn't force the user to worry about dependencies.
>
Uh, yes. I should read the entire message before I write things I suppose.

> I think a reasonable intermediate step would be to have a DMG which installed the basic dependencies for KDE applications (e.g. D-Bus, Qt, KDELibs, KDESupport) and then .app bundles for individual applications.
Which is a > 1 man job.

>
> I did a talk on using CPack to do this at Akademy the year before last. I really think this is something that we should seek to do a) as a group/team and b) properly rather than just the easiest way possible.
As of Camp KDE 2009 the instructions on using CPack for Mac OS X,
whether in book form, or online documentation sucked (which is to say
I couldn't find out how to make it do what I wanted it to do on the
mac). Has this improved?

What I was attempting btw was
1. Compile program A.
2. Have certain files from program A relocated within the .app bundle
3. Make pkg.

#2 proved problematic.

Now while I believe it is possible, as others have claimed to do it, I
have yet to see step by step instructions on how to do so.

> --
> Cheers,
> Mike McQuaid
> http://mikemcquaid.com
>
> _______________________________________________
> kde-mac at kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X
>