Configuring your build environment is the single most important step in building KDE. Luckily, KDE frameworks development libraries are packaged by most major distributions. In general, building and installing user space programs such as Calligra can be done safely without altering any system files. Whenever possible, it is recommended that you build KDE using your normal user account. Unless you are interested in changing the behavior of your system, you should build with a normal account. Even if you are a a KWin or Plasma developer wishing to test a full KDE session with compositing effects, there are ways to construct the desired testing bed entirely within your normal user account, e.g. running Plasma through a nested X server using xypher.
However, to permanently alter your KDE/Plasma desktop environment through new System Configuration Modules and the like, you will often need to install shared libraries and other files in system folders. In these cases, bad installation can render your system unstable or your desktop environment unusable. Always take caution before executing any commands as root! A
sudo make install can not always be undone by a simple
sudo make uninstall. Technologies like containerization may help solve these problems in the future, but current distribution systems have no way to monitor the alterations you make to system shared libraries as the system administrator. Always keep records of what you are doing and make sure you know how to access the install logs to give yourself a better chance of reverting files by hand if necessary. And of course, please keep high quality, frequent backups of your data.
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. However the scripted and by-hand methods are completely interchangeable so once you are comfortable building KDE using the scripts you can learn more by doing everything yourself.
If you want to do the work by hand you can follow the detailed instructions else continue here on.
This section provides information about required and optional software packages needed to build the KDE applications.
Follow this page to install the required dependencies.
Let's setup a "kde:" prefix for git commands. Add the following text to your ~/.gitconfig:
[url "git://anongit.kde.org/"] insteadOf = kde: [url "ssh://email@example.com/"] pushInsteadOf = kde:
If you are behind a firewall, add the following text to your ~/.gitconfig :
[url "https://anongit.kde.org/"] insteadOf = kde: [url "ssh://firstname.lastname@example.org/"] pushInsteadOf = kde:
kdesrc-build is a user-space package manager. It is used to compile KDE-related projects from source, and to install them into a designated directory. (see current master here)
This guide assumes that
Make sure to adapt these steps to your needs.
Start off by installing kdesrc-build and creating a basic configuration file:
mkdir -p ~/kde/src cd ~/kde/src git clone kde:kdesrc-build cd kdesrc-build # Install a symlink of kdesrc-build to a location in PATH mkdir ~/bin ln -s "$PWD/kdesrc-build" ~/bin export PATH=~/bin:$PATH
You will need to append the line
export PATH=~/bin:$PATH to your ~/.bashrc so
kdesrc-build is available in PATH whenever you open a terminal. Also check that PATH variable is not set to anything by default in .bashrc file
The easiest way to prepare your system is to use the wizard to create the ~/.kdesrc-buildrc you will need, the default options should be ok
Note: do not quote or escape any file paths.
If you get an error saying "Unable to run the dialog(1) program" or similar, then install the "dialog" package, such as by running "sudo apt-get install dialog" on Debian / Ubuntu / KDE NEON.
2017-04-23: User question:
2018-01-21: Dev response:
kdesrc-build handle the compilation and installation of KDevelop (the dependencies should be already present if you use a recent distribution, like openSUSE Tumbleweed), type
$ kdesrc-build kdevelop
The path to the log files (cmake, build, install) will be shown at the end of the compilation.
Copy and use these commands to a new file called ~/kde/.setup-env (or a different name, but you need to adjust the "source" command below to match):
export KF5=$HOME/kde/usr export QTDIR=/usr export CMAKE_PREFIX_PATH=$KF5:$CMAKE_PREFIX_PATH export XDG_DATA_DIRS=$KF5/share:$XDG_DATA_DIRS:/usr/share export XDG_CONFIG_DIRS=$KF5/etc/xdg:$XDG_CONFIG_DIRS:/etc/xdg export PATH=$KF5/bin:$QTDIR/bin:$PATH export QT_PLUGIN_PATH=$KF5/lib/plugins:$KF5/lib64/plugins:$KF5/lib/x86_64-linux-gnu/plugins:$QTDIR/plugins:$QT_PLUGIN_PATH # (lib64 instead of lib on some systems, like openSUSE) export QML2_IMPORT_PATH=$KF5/lib/qml:$KF5/lib64/qml:$KF5/lib/x86_64-linux-gnu/qml:$QTDIR/qml export QML_IMPORT_PATH=$QML2_IMPORT_PATH export KDE_SESSION_VERSION=5 export KDE_FULL_SESSION=true export SASL_PATH=/usr/lib/sasl2:$KF5/lib/sasl2 # (lib64 instead of lib on some systems, like openSUSE) PS1="(kdesrc) $PS1"
A guide for building Plasma 5 specifically on Ubuntu 14.04 LTS can be found here.
Whenever you want to run a self-compiled KDevelop, you just have to do the following commands in terminal (remember to replace the name of the .setup-env script with the name you chose, if you picked a different name):
$ source ~/kde/.setup-env $ kdevelop
First and foremost check that you have installed the dependencies mentioned in the wiki at here
If kdesrc-build shows you red module names with messages like "Unable to configure plasma-mediacenter with CMake!" or "Unable to build kdepim!", you have to start troubleshooting.
<<< PACKAGES FAILED TO BUILD >>> libkomparediff2 - ~/kde/log/<build-date>/libkomparediff2/error.log :-(
Inspect that log to figure out what's going on:
$ cat ~/kde/log/<build-date>/libkomparediff2/error.log
CMake Error at CMakeLists.txt:5 (find_package): Could not find a package configuration file provided by "ECM" (requested version 0.0.9) with any of the following names: ECMConfig.cmake ecm-config.cmake Add the installation prefix of "ECM" to CMAKE_PREFIX_PATH or set "ECM_DIR" to a directory containing one of the above files. If "ECM" provides a separate development package or SDK, be sure it has been installed.
In this case, the ECM (extra cmake modules) package is missing. Since ECM is a KDE Framework, this error would have been avoided by the --include-dependencies parameter mentioned above.
However, this might also happen with dependencies that kdesrc-build is not able to handle itself. In such cases, you have to install additional packages via your system package manager. Most distribution offer ways to determine which package contains the missing files.
For Ubuntu, you would head over to http://packages.ubuntu.com and search for the distro package providing a particular file (ECMConfig.cmake in this case). The package search reveals extra-cmake-modules being a hot candidate; to fix above error we simply install the package and the restart the build:
$ sudo apt-get install extra-cmake-modules $ kdesrc-build ...
The error should be gone now.
CMake Error at CMakeLists.txt:45 (find_package): Could not find a package configuration file provided by "Qt5" (requested version 5.2.0) with any of the following names: Qt5Config.cmake qt5-config.cmake
It can be fixed by installing the dependeny
sudo apt-get install qtbase5-dev
Run again the kdesrc-build command, and it should be fine
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake:26 (find_package): Could not find a package configuration file provided by "Qt5WebKitWidgets" with any of the following names: Qt5WebKitWidgetsConfig.cmake qt5webkitwidgets-config.cmake
It can be fixed by installing the dependeny
sudo apt-get install libqt5webkit5-dev
Run again the kdesrc-build command, and it should be fine
At least arch linux has openssl 1.1 by default, but it seems like kdelibs4support/qca needs to be built against 1.0 for the time being.
Add this to your .kdesrc-buildrc to let it pick up the right headers (make sure to have openssl 1.0 and the header location is correct):
options kdelibs4support cmake-options -DOPENSSL_INCLUDE_DIR=/usr/include/openssl-1.0 end options options qca cmake-options -DOPENSSL_INCLUDE_DIR=/usr/include/openssl-1.0 end options
Unit tests are ran from the build dir of each framework; you should first
cd into it.
You need a separate DBus session because the dbus server needs to have the right value of XDG_DATA_DIRS, in order to find $KF5/share/dbus-1/services for starting services (e.g. kded5).
$ eval `dbus-launch` $ kdeinit5 $ make test
Note: Regular apps will start kdeinit5 automatically. The reason it has to be started by hand when running unit tests is some strange interaction with ctest.
Warning: never start a KDE 4 application in this separate DBus session. It would conflict with your running Plasma 4 desktop.
Note: KDE_FULL_SESSION=true is needed to make sure that the correct QPA will be loaded.
Many of the tests require an X server, and will pop up windows briefly. An easy way to allow these tests to run without interfering with your normal X session is to do
$ xvfb-run -s '-screen 0 1024x768x24' make test
The -s argument tells Xvfb to set the first screen to be 1024x768 pixels, with a depth of 24; at least one test requires a depth greater than 8. In this case, if you also ensure DBUS_SESSION_BUS_ADDRESS is not set, the tests should not find your existing DBus session, and instead launch a new DBus instance.
Note that the KWindowSystem tests require a NETWM-compatible window manager to be running. One way to do this is to create a script to run such a window manager, followed by whatever is passed to it. For example, if you have the window manager awesome installed, you could create a script called awesome-run as follows:
#!/bin/sh awesome & exec "$@"
and then run the tests as
xvfb-run -s '-screen 0 1024x768x24' /path/to/awesome-run make test
If you want to publish your test results, instead of "make test" run
The test results will appear on http://my.cdash.org/index.php?project=<projectname>
The following page details how to test Plasma.
One or more modules fail to build via
kdesrc-build (displayed in red font).
Steps to solve (in the given order):
The following steps assume the directory structure as proposed in the kdesrc-build guide above.
Example of the problem: open kate, edit some file without saving, Ctrl+W to close, a message box is about to appear and the then segfault:
kate(9037)/default KNotificationManager::notify: Calling notify on "Sound" Segmentation fault
This command can solve the problem:
$ sudo /usr/lib64/vlc/vlc-cache-gen -f /usr/lib64/vlc/plugins
Alternative: go to kf5/build/kdesupport/phonon/phonon-vlc/ and exec `make uninstall`
Situation: kded5 is started but crashes because of some dependency. Stacktraces show for example `bluedevil` as possible cause.
Goal 1: Disable the component to verify it as crash cause.
locate bluedevil, for example.
Goal 2: Remove bluedevil from kdesrcbuild until it gets fixed.
dev/kf5/src/extragear/utils/kdesrc-build/*-build-includefiles to find the component. In this case, it was found in kf5-workspace-build-include.
# module-set kf5-bluetooth-management # repository kde-projects # use-modules libbluedevil bluedevil # end module-set
Further calls of
kdesrc-build will not include the component.
If you still have trouble with the building process or runtime setup, you can contact people as described in Communicating with the team.
Feel free to join us by visiting #kde-devel on Freenode. A web-based client can be found at https://kiwiirc.com/client/irc.freenode.org/kde-devel
Kubuntu CI (replaces Project Neon 5) provides packages of KDE Git master for KDE Frameworks and Plasma 5. Install them on your Kubuntu system to work with KDE Git.
The openSUSE Build Service provides packages of KDE Git master for KDE Frameworks, Plasma, Applications and Extragear. It offers repositories for Tumbleweed and the latest stable (Leap) release.