Running KDE apps out of tree

I’ve tried a couple of times over the last few weeks to build amaroK out of subversion so that I can help with their GStreamer 0.10 powered backend.

My usual method of developing stuff is to have a checkout somewhere under ~/devel. If the project supports running uninstalled, I’ll just work with it there. If it requires installation (as amaroK seems to), I like to install to ~/install.

Under no circumstances will I install to /usr, because it puts the package management system into weird states and it’s always a PITA to recover later. Plus, it makes thomasvs haemorrhage nastily.

How is this relevant? Well, I was given the impression that KDE apps absolutely need to be installed in the same prefix – unless I felt like building ALL of KDE in another prefix, I would need to install amaroK into /usr.

Armed with this knowledge, I tried building packages of an SVN snapshot. For some reason (again, I’m told) creating a snapshot tarball of amaroK’s SVN requires an active svn account, which I don’t have because I’m not a KDE developer. Hence, I would have to rely on someone else’s SVN snapshot tarballs to build packages from. In addition, building a package and installing it takes a relatively long time and would severely hamper my speed. I gave it up as a bad approach after spending around an hour to get a build package of amaroK 1.4.0-RC1 , and went off to do something productive.

About a week later, I tackled the problem again. This time, markey mentioned a variable called KDEDIRS. It turns out that by doing:

KDEDIRS=$HOME/install

all my problems magically go away – I can run ‘amarokapp’ manually, debug it etc, and it correctly finds all its resources and whatnot in my preferred prefix.

So now, I have that exported from my ~/.xsession-vars file, along with all my normal PATH, LD_LIBRARY_PATH, PYTHONPATH and friends and everything just works.

argh, the pain

I’d love it just one time when I tried editing a configure.ac I didn’t end up with this sort of thing:

configure.ac:1: error: possibly undefined macro: dnl

The actual problem? In the middle of the file, I had something like:

AC_CHECK_HEADER (blah, [

dnl ** OK, found it ***

])

Note the extra space between the macro name and the parenthesis. Because of the extra space character, autoconf couldn’t expand the entry correctly and misinterpreted the ‘dnl’ comment and then proceeded to tell me THE FIRST PLACE IT SAW THAT STRING, which happened to be line 1 of the file.

I hate you, autotools.

Back

When we moved the server to Tamworth in June, I lost my ability to write blog entries. After nearly 7 months, I’ve finally gotten around to bringing it back online.

It’s been a busy time for us – we moved from Australia to Spain, went back to .au, got married, returned to Spain, rented a new apartment, had quite a few parties and generally had a ball.

I won’t write much more than that to fill you all in – if you’re interested, you can check it all out in Jaime’s diary, which has been kept up to date much better.

Writing stuff down, where it can't hurt anyone