The $QTPATH environment variable defines where the KDE Build System can find the Qt library and include files to use when building KDE. Normally you will want to set this to your system Qt, but you may want to change this to point to a different version of Qt you have [[Getting_Started/Build/Qt|built yourself]].

+

The $QTDIR environment variable defines where the KDE Build System can find the Qt library and include files to use when building KDE. Normally you will want to set this to your system Qt, but you may want to change this to point to a different version of Qt you have [[Getting_Started/Build/Qt|built yourself]].

Introduction

Configuring your build environment is the single most important step in building KDE. A wrong decision or mistake here could at best mean you have to rebuild everything from scratch again, or at worst break your system KDE rendering your system unusable.

A lot of very important concepts will be discussed and it is important that you understand them before proceeding.

A set of configuration scripts and bash commands are provided as a recommended configuration when building KDE manually. If you use these as provided then your KDE build will be a lot easier and it will be easier for you to find support online. The one disadvantage to these scripts is that they hide important details from you which you may want to learn about, but the two methods are completely interchangeable so once you are comfortable building KDE using the scripts you can learn more by doing everything yourself.

It is recommended that you build KDE using your normal user account. In some circumstances you may want to build using a separate user account, such as if you are a KWin or Plasma developer wishing to test a full KDE session with compositing effects, but for most circumstances a simple way can be found for achieving the same aim while still running using your normal user account (e.g. Nested X using xypher).

Git Configuration

KDE uses Git as its main source repository and revision control software which you need to configure before you can use it in KDE. You can find the recommended Git configuration for KDE on the Git Configuration page.

Path Configuration

This section explains the different paths that need to be configured for building KDE. The following section will demonstrate a simple method for setting up the required paths.

Qt Path

The $QTDIR environment variable defines where the KDE Build System can find the Qt library and include files to use when building KDE. Normally you will want to set this to your system Qt, but you may want to change this to point to a different version of Qt you have built yourself.

Source Path

The $KDE_SRC path environment variable defines where the KDE Build System can find the source files.

By tradition this is usually saved in your home directory, but can be anywhere convenient or large enough to hold the source, build and install files:

~/kde/src/

Inside this directory you can clone all the required git and svn source code repositories, for example:

~/kde/src/kdelibs
~/kde/src/kdegames
~/kde/src/marble

If you plan to build multiple branches of KDE such as stable and unstable in parallel then you will need to add an extra level to the directory structure:

Build Path

The $KDE_BUILD path environment variable defines where the KDE Build System will create the build files.

The KDE build system requires that your source and build files be in different directories (aka out-of-source builds). This keeps your source directories clean and simplifies management of your different build files. :

It makes it very easy to rebuild from scratch, you just delete the build directory to remove all the generated files - even old ones that "make clean" wouldn't remove.

It is easier to look at the source files (grep, ls etc.).

It allows multiple build trees with different settings, e.g. debug and release.

While for some simple build scenarios you could just create a 'build' directory inside your 'source' directory (e.g. ~/kde/src/kdelibs/build), this negates many of the advantages when used with a full KDE build. Instead clearly separate paths are recommended.

Continuing the example given above, you will now need the following new directories:

~/kde/build/master/
~/kde/build/4.6/

Install Path

The $KDEDIR path environment variable defines where the KDE Build System will install KDE.

It is strongly recommended for a development build that you do a user based install and not a root install, i.e. install your KDE build into a user-owned directory and not into the system /usr directory. This provides a number of advantages:

Your root/system installed version of KDE is untouched, meaning your normal desktop and applications remain stable and usable even if your development build breaks

You can build and run multiple development versions of KDE at the same time, i.e. a stable branch for bug fixes and an unstable branch for new features

You can use a single alias or bash command to compile/link/install without having to do a su/sudo in the middle

Doing "make" and "make install" as the same user is a lot quicker as the Makefiles are only parsed once.

No root owned files in the build directory

No problems caused by root not having a correctly configured KDE build environment

It makes it very easy to reinstall from scratch, you just delete the install directory to remove all the installed files and rerun the build.

That said, the build instructions provided are completely generic and will work for building a root system install if you configure your environment to do so, i.e. for Linux from Scratch or doing a root install in a virtual machine for testing or packaging purposes.

Continuing the example given above, you will now need the following new directories:

Home Path

For the same reason as the Install Path, it is strongly recommended that you set your KDE Home Path to be different from your normal home folder.

Continuing the example given above, you will now need the following new directories:

~/kde/home/master/
~/kde/home/4.6/

XDG Paths

The Cross Desktop (XDG) Paths XDG_DATA_DIRS and XDG_CONFIG_DIRS are a standard set of paths used to find various shared cross-desktop standard data and config such as mimetypes. If you are building the KDE Development Platform yourself then it is recommended to unset these paths to prevent your build from seeing your system install (usually /usr) as this will cause problems. However, if you do so you must install the shared-mime-info data into your development install path. If you are not building your own KDE Development Platform then you should not unset the XDG Data Paths.

Other Paths

There are a number of other paths that are required, but these can all be automatically derived and created by the config script given below.

Summary

If you are only working on unstable, then you will end up with a directory hierarchy looking like:

~/kde/src/
~/kde/build/
~/kde/inst/
~/kde/home/

If you are working on both unstable and stable then you will end up with a directory hierarchy looking like:

Just remember that you do not have to put the directories in your home folder, they can be anywhere you like that has sufficient space. You can even have each directory in a different location.

Normally you would need to manually create all the directories yourself and set the KDE Path Environment Variables manually, but if you use the config scripts below then you only need to create the source directory, all the other directories will be created by the KDE Build System when required.

Environment Configuration

The example environment configuration script given below is for building KDE against your system Qt under your normal user account with an out-of-source build and installing into a user directory. By changing just four variables you can use the script to configure any KDE build environment you want.

It is recommended you create a separate script for each build environment you require. If you have separate source directories for each build then save the script into the root source directory with the name ".build-config" to allow the bash scripts in the next section to automatically load the config and create the required directories.

If you don't wish to use the bash scripts then you must manually create the required directories and manually execute the config script.

If you are building KDE using a dedicated user to run a full desktop session, then you should put this config into the users ~/.bashrc file.

Please see the notes above about the XDG Paths, the example config script below overrides the XDG Data Paths.

Sample .build-config file

KDE4 Build Environment configuration script

To configure your build environment set LIB_SUFFIX, BASEDIR, BUILDNAME and

QTDIR as appropriate

The default values provided are for a master/trunk/unstable build in your own

Useful Bash Scripts

This section provides a set of bash scripts to simplify setting up your build environment and managing the KDE build process. If you use these scripts, then you can use the 'Easy Recipe' option documented in these pages. If you do not want to use these scripts then you will need to use the 'Full Recipe' option documented in these pages.

You can find further details about using these scripts on the Build Recipes page.

The main commands provided are:

cs

Change to source directory

cb

Change to build directory

cmakekde

Configure, build and install the current KDE module

findup

Save this script in an executable file called "findup" somewhere in your path, usually ~/bin/findup.

!/bin/sh

arg="$1"
if test -z "$arg"; then exit 1; fi

while ! test -f "$arg"; do

cd ..
if test "$PWD" = "/"; then
exit 1
fi

done

echo $PWD/$arg

.bashrc

Add the following script to the end of your ~/.bashrc, or save as a separate ~/.kde-bashrc and add source .kde-bashrc to your ~/.bashrc.

A script to setup some needed variables and functions for KDE 4 development.

This should normally go in the ~/.bashrc file of your kde development user.

# Comment out the following two lines to stop builds waiting after
# the configuration step, so that the user can check configure output
echo "Press <ENTER> to continue..."
read userinput

# Note: To speed up compiling, change 'make -j2' to 'make -jx',
# where x is your number of processors +1
nice make -j2 && make install
#Use this line instead if using icecream
#nice make CC=icecc -j6 && make install
RETURN=$?
cs
return ${RETURN}