Illegitimi non carborundum


How to develop on KDE & Amarok without trashing your System

This is just a mixed back of info I've picked up along the way on how to develop with relative ease on KDE applications/libraries without totally trashing your system provided versions.

As a packager, it's important for me to be able to test the packages I produce so having a system that is solely running the latest and greatest upstream versions is not desirable. In order to do this I don't maintain two separate installations (that's too complicated and too much effort), rather I build all the upstream stuff into it's own prefix and then run it from there. It's totally separate from my system binaries (and shouldn't ever need root). Cleaning up is as simple as an rm -rf.So when you have a fresh checkout (git clone or svn checkout) of the code in question, I typically run the following:

[colin@jimmy kdemultimedia4]$ mkdir build
[colin@jimmy kdemultimedia4]$ cd build
[colin@jimmy build]$ kdecmake ..
[colin@jimmy build]$ make install

Nothing too magic there... but what is this strange "kdecmake" command? Well it's a simple little script I wrote to handle the options I need. This is the contents of that script::


if [ "$(uname -m)" = "x86_64" ]; then


Nothing too exciting there, just a few options etc. The "prefix" I choose is $HOME/Development/Personal/KDE/prefix. This is the one and only folder I need to kill when I want to trash my "install" and start again. There is a little cmake hack there for Phonon development - this is due to the FindPhonon.cmake always finding the system Phonon and not my custom one. The hack in there is just to make a FindPhonon.cmake that forces the detected version to my custom prefix. It's the ugliest bit of the whole setup, so don't worry too much about it if you don't hack on Phonon!

So this will build and install the applications but how about running them? Well I have another little script for that which is sourced into the current environment and then used to run the applications itself:

[colin@jimmy ~]$ .

[KDE: colin@jimmy ~]$ which kmix
[KDE: colin@jimmy ~]$ kmix --nofork

So this is how the application can be run, it finds the right version and the libraries etc. are all loaded from the right place too. Quite handy all in all 🙂 Here are the contents of the file:

# To be sourced

if [ "$(uname -m)" = "x86_64" ]; then

export PKG_CONFIG_DIRS=$PREFIX/$LIB/pkgconfig
export PATH=$PREFIX/bin:$PATH
export KDEDIRS=$PREFIX:/usr

kbuildsycoca4 --noincremental

export PS1="$(echo -n "$PS1" | sed "s|\\\u@|KDE: \\\u@|")"

Now one warning. This approach uses your existing home and thus settings. If you're running a newer version of the app in question it may upgrade it's data along the way and subsequently prevent it working with the system version. To get around this, you can set the KDEHOME environment variable in the file and keep things totally separate.

Now, for some specific debug info concerning Amarok and perhaps Akonadi. Both these applications use an embedded or private version of MySQL to store their data. This is great but it can complicate issues when trying to debug the data in the database itself. Here is a very simple script I wrote (with helpful guidance from Leo on the Amarok team):


cd ~/.kde4/share/apps/amarok
trap 'kill $(jobs -p)' EXIT
/usr/sbin/mysqld --defaults-file=`pwd`/my.cnf --default-storage-engine=MyISAM --datadir=`pwd`/mysqle --socket=`pwd`/sock --skip-grant-tables --skip-networking&
sleep 1
mysql --socket=`pwd`/sock amarok --prompt="Amarok> "

This little script will start a version of mysqld specifically for the files/data in the Amarok data folder. It then starts a mysql client that connects to that daemon. When the client exits the mysqld process used is automatically killed. It's probably not a good idea to run this command at the same time as Amarok itself runs, but it's excellent for debugging and checking the data after a change etc.

Nothing in this article is particularly new or ground breaking, but hopefully it helps some people in some of their tasks and makes contributing that bit easier!

Share and Enjoy:
  • Digg
  • StumbleUpon
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Slashdot
Tagged as: Leave a comment
  • Kevin Krammer

    Your should probably check if $XDG_DATA_DIRS is empty before extending it so it can add the default paths which are assumed by applications when they encounter the variable empty or unset.

    Otherwise you will lose those two search paths when running applications inside this environment (unless this is the intent of course)