Hack 44. Run KDE on the Bleeding Edge

Of all the free and open source projects, KDE is possibly the fastest-growing, as evidenced by the large and active community of developers, features that go from the drawing board to computer in record time, and the constant stream of additions being committed to the KDE source code. The rapid pace of development means something new or interesting is always in the development code. This hack shows you how to compile and run all the newest code in advance of official binary releases.

The first thing to be aware of when you are going to play with development software is that most likely it will not work the first time you try it. Some things will work, and some things won't, and you might even lose data and information to crashes, bugs, and other nasties that are part and parcel of development code. In this hack, you will download some code and compile it, but I recommend you back up any important data first.

To get a basic desktop up and running, you need to compile the following KDE CVS modules, in this order:

• qt-copy (you need this only if you do not have the latest copy of Qt installed on your system)

• arts

• kdelibs

• kdebase

Details on getting code via CVS are discussed in [Hack #86] . The anonymous CVSROOT for the KDE code is:

:pserver:anonymous@kde.org:/home/kde

You need to grab the qt-copy, arts, kdelibs, and kdebase modules from CVS. Compile the modules in the order in which they appear in the earlier list.

5.11.1. Compiling the Code

When you have checked out the code for each module, you need to go into each module directory, and issue a number of commands to configure and compile the software. The first command is:

foo@bar:~$ make -f Makefile.cvs

This performs some special logic on the files in the module so that it is suitable for compiling. You need to use this command only with a CVS copy of KDE and not normal, stable, packaged versions. Next, you need to configure the module. This means running a special script called configure, which checks that you have everything needed to compile the code (such as a compiler, linker, etc.) and finalizes the code and makes it ready for compilation. You can normally run configure like this:

foo@bar:~$ ./configure

Although this is fine, configure has a few options that can be useful. The first is the --prefix option that can be used to specify where the compiled software will be stored. As an example, to store your CVS version of KDE in /opt/kde, use the following command:

foo@bar:~$ ./configure --prefix=/opt/kde

If you do use --prefix on your configure command, you also need to add your prefix to your PATH environment variable so that your system can find the compiled software. You can set your path to PATH=$PATH:/opt/kde/bin, for example. One other note to make is that the qt-copy module needs quite a few arguments to be passed to its configure script. You can find information on this in the INSTALL.qt-copy file in the module. If you get any errors while configuring a module, you need to fix them before you can continue.

With a module configured, it is time to compile it by running:

foo@bar:~$ make

Now grab some coffee and eat some flapjacks; your module will take quite a while to compile. When it has finished you are returned to the prompt. At this point you can install it with:

foo@bar:~$ make install

You might need to be root to run this command when you are installing it to a normal system binaries directory, such as /usr/bin. If you used the --prefix command in the configure script, your files are installed to that directory instead. Remember that you will need to run each command for each module you want to compile.

5.11.2. Running KDE

With your new development version compiled, it is advised that you back up your existing KDE configuration before you run the new version; it is not uncommon for new development code to eat previous configuration files. KDE stores its configuration in the .kde directory within your home directory. A simple way to back up this directory is to rename it to another name. When you start your new development KDE version, the .kde directory will be re-created with the new configuration files.

To run KDE, set your PATH environment variable to include the path where KDE is installed (as discussed earlier), and then edit your .xinitrc file and add exec startkde to it. This will load KDE when you run startx.