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::
#!/bin/bash PREFIX=$HOME/Development/Personal/KDE/prefix LIB=lib if [ "$(uname -m)" = "x86_64" ]; then LIB=lib64 fi exec cmake -DCMAKE_MODULE_PATH=$HOME/Development/Personal/Phonon/cmake-hacks -DCMAKE_INSTALL_PREFIX=$PREFIX -DLIB_INSTALL_DIR=$PREFIX/$LIB -DCMAKE_BUILD_TYPE=debugfull $*
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 ~]$ . kde4env.sh
[KDE: colin@jimmy ~]$ which kmix /home/colin/Development/Personal/KDE/prefix/bin/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 kde4env.sh file:
# To be sourced PREFIX=$HOME/Development/Personal/KDE/prefix LIB=lib if [ "$(uname -m)" = "x86_64" ]; then LIB=lib64 fi export PKG_CONFIG_DIRS=$PREFIX/$LIB/pkgconfig export XDG_DATA_DIRS=$PREFIX/share:$XDG_DATA_DIRS export PATH=$PREFIX/bin:$PATH export LD_LIBRARY_PATH=$PREFIX/$LIB:$LD_LIBRARY_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 kde4env.sh 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):
#!/bin/bash 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!