Anatomy of a standalone KDE Mac package

Posted by illogic-al on September 11, 2008
Read time: about 3 minutes

Allow me to start off by stating that there is no such thing. The standalone package is a myth which we (or at least I) aspire to here in KDE/Mac land. Installation of KDE software is wholly geared towards non-proprietary *nix platforms. Whilst the I’m a PC crowd might be willing to overlook the inconvenience of installing 1 GB of tangentially related packages to get that one program they desire, members of the Cult-of-Mac are far less forgiving. This leaves us, i.e. me, in the unenviable position of trying to tease out what is necessary for an app, from what is not, and trying to package it all together. Most of the time this results in less than stellar, um, results. Let’s discuss why this is, for the time being, necessarily so.

A KDE application requires kdelibs, in itself a misnomer as it does not only contain libraries. One need look no further than kdelibs’ bin directory to see how true this is.

orville@cubic:local$ l ~/Desktop/packages/kdelibs4/opt/local/bin/
checkXML*             kdeinit4_shutdown*    kwrapper4*
kbuildsycoca4*        kdeinit4_wrapper*     makekdewidgets*
kconfig_compiler*     kjs*                  meinproc4*
kcookiejar4*          kjscmd.app/           nepomuk-rcgen.app/
kde4-config*          kross.app/            preparetips*
kded4.app/            kshell4*              start-session-bus.sh*
kdeinit4.app/         kunittestmodrunner*
orville@cubic:local$ 

And therein lies our, or rather, my problem. It becomes immediately apparent that to install any KDE program, one needs to provide, not just dynamic libraries but other binaries as well. Why is this a problem, you ask? sigh Where do I begin?

OS X has, what might appear to some, a curious method of installing applications. A user drags a specially named directory (known as a bundle) to anywhere they please on their filesystem. The app is now installed and registered with the system. This means that in an ideal world, a bundle for a KDE application, like say - oh I don’t know - Amarok, would look something like this:

Amarok.app/
-- Contents/
----- Info.plist

----- Frameworks/
-------- Kdecore.framework/
-------- Kdeui.framework/
-------- Kio.framework
-------- Nepomuk.framework/
-------- Threadweaver.framework/
-------- etc.framework/

----- Resources/
-------- amarok.icns
-------- apps/
-------- config/
-------- dbus-1/
-------- mime/
-------- etc/

---- MacOS/
------- Amarok
------- amarokcollectionscanner
------- amarok_afttagger

Aaaaaaaand we’d be done. Life is always looking to throw us curveballs though isn’t it? As stated earlier, kdelibs isn’t just a set of libraries which all KDE programs depend upon, it’s also a set of binaries which all KDE programs depend upon. Those binaries depend on dynamic libraries. Those dynamic libraries depend on .so files (wth are those anyway?). The result of splitting all this functionality across so many files is a wonderful little scavenger hunt whenever we need to package things up for OS X.

We can throw virtually everything into a bundle we need and it’ll almost work; except for those enigmatic .so’s. The ones we need the most, like kio_file (and kio anything else) never get found. This isn’t so bad after all though. Things like dbus prevent us from providing everything we need in the bundle anyway. kdelibs also depends on other libraries which aren’t provided by default on OS X. That means our frameworks (were they present) would have to link to them statically. Otherwsie we’d have to install these libraries when we install our frameworks. Instead of the preferable, ubiquitous bundle, another solution presents itself.

Enter the package, hereinafter referred to by its extension, pkg. Apple software engineers anticipated the possibility that sometimes we wouldn’t be able to provide everything we need in a bundle. This is especially true of programs not designed for OS X like KDE’s. Apple provides an installer pkg for those special occasions. It also provides the preternaturally designed PackageMaker with which to create them (Interpret that however you desire, as many times as you desire. You’ll still be right.)

The pkg allows us to grab all the files we need and place them where necessary. But kdelibs, as previously stated, is not just a bunch of libraries. It is so much more. That so much more isn’t necessary for all programs though. Amarok has no need of libkde3support or libkhtml; even more so the emoticonstheme .so files. It needs even less of kdebase. Verily, it requires none of kdepimlibs. So the scavenger hunt begins, culling until you can cull no more. Eventually you’re left with a pkg weighing in at a respectable 130 MB. Certainly better than the 300 MB you’d have if you’d left in all of Qt, kdelibs and kdebase. Infinitely better than the 1.4 GB you’d have if you just provided all of the dependencies for kdebase and then just added MySql and Amarok.

Unfortunately when you install and run it you realize that Amarok’s QtScript bindings won’t load. Three days and a full installation of kdelibs, Qt and kdebase later it still doesn’t work. Perhaps you forgot a symbolic link for one of the libraries. Perhaps. You’ll never find out though because the weekend is over and it’s time to go to work again. Then you think to yourself, if only those nice boys and girls in KDE-land had a native solution for installing their software, perhaps you wouldn’t have to do this and could spend time attempting to figure out other things. Oh well. Here’s to hoping next week’s scavenger fares better.

If we’re lucky the resultant post will be infinitely more readable. As with the appearance of a standalone KDE Mac package however, I wouldn’t hold my breath. Hmm, I wonder if now’s a bad time to say help wanted.