Difference between revisions of "Guidelines and HOWTOs/Build from source"

Jump to: navigation, search
(updating qt5)
(Make the Testing Plasma link go do the main Development page)
 
(391 intermediate revisions by 79 users not shown)
Line 1: Line 1:
= Build requirements =
+
= Build KDE Frameworks and Applications =
This section provides information about '''hard''' (required) and '''optional''' software packages needed to build the KDE Framework.
 
  
=== kdelibs dependencies ===
+
== Design features ==
*'''deb-based distributions (Debian, Ubuntu...):''' All the dependencies used for the packages can be installed by running
+
Qt and most KDE software are written in C++ whereas its "competitor" GTK is written in C making it very portable and easy to produce language bindings for (for Ruby, Python, Bash etc.). So it is possible to write a complete GTK GUI app in Bash script, but so far that has not been done for Qt.
$ apt-get build-dep {packagename}
 
*for instance on Ubuntu:
 
$ sudo apt-get build-dep kdelibs5
 
  
*'''OpenSuSE:''' All the dependencies used for building kdelibs can be installed by running:
+
== Safety Precautions ==
$ zypper si -d kdelibs5
+
Configuring your build environment is the single most important step in building KDE software.  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 Plasma 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.
  
*'''Fedora:''' All the dependencies used for building kdelibs can be installed by running:
+
However, to permanently alter your 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 <code>sudo make install</code> '''can not always be undone by''' a simple <code>sudo make uninstall</code>  . 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. Another option is to use snapshots of a BTRfs formatted system harddisk and use snapper-GUI to roll back in case of an error. 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.
  $ yum-builddep kdelibs5
 
  
=== CMake 2.8.10.1 ===
+
== Configuration scripts  ==
You need CMake 2.8.10.1 for KDE Frameworks 5. If you are already using 2.8.10.1 you can move on to next step
+
A set of configuration scripts and bash commands are provided as a recommended configuration when building KDE software manually. If you use these as provided then your 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.
else download it from http://www.cmake.org/cmake/resources/software.html.
 
  
Alternative for CMake 2.8.10.1 using Git.
+
If you want to do the work by hand you can follow the [[/Details|detailed instructions]] else continue here on.
  
* Choose an install prefix, for instance
+
== Install required devel packages ==
  $ export KF5=$HOME/kf5
 
  
To avoid repetition of command you can append ~/.bashrc file with above line and execute,
+
This section provides information about '''required''' and '''optional''' software packages needed to build the KDE applications.
  $ source ~/.bashrc 
 
* Checkout and install Latest version of CMake using Git.
 
  $ git clone git://cmake.org/cmake.git
 
  $ cd cmake
 
  $ ./configure --prefix=$KF5
 
  $ make
 
  $ make install
 
  
=== Extra CMake Modules ===
+
[https://www.qt.io/ Qt5] is the base of KDE software. Your distro provides suitable devel packages containing prominently the Qt C++ header files below /usr/include/****'''.h''' . Optionally, you can [[/OwnQt5| build your own Qt5]].
  
* Checkout and build extra-cmake-modules
+
Follow this page to [[/Install the dependencies|install the required dependencies]].
  $ git clone git://anongit.kde.org/extra-cmake-modules
 
  $ cd extra-cmake-modules
 
  $ cmake -DCMAKE_INSTALL_PREFIX=$KF5 .  
 
  $ make
 
  $ make install
 
  
=== Qt 5 ===
+
== Git remote prefix ==
 +
See [[Get Involved/development#Configure Git]]
  
To build all of qt5 execute:
+
== kdesrc-build ==
  $ git clone git://gitorious.org/qt/qt5.git --branch dev
+
See [[Get Involved/development#Set up kdesrc-build]]
  $ cd qt5
 
  $ git checkout dev
 
  $ ./init-repository
 
  $ mkdir build
 
  $ cd build
 
  $ ../configure -prefix $KF5 -opensource -confirm-license -nomake tests -nomake demos -nomake examples -xcb -qpa xcb -no-gtkstyle
 
  $ make
 
  $ make install
 
  
To update qt5 later:
+
= Testing =
  $ git pull
+
== Running unit tests ==
  $ git submodule update
+
Unit tests are ran from the build dir of each framework; you should first <code>cd</code> into it.
  
If you don't have enough time and disk space for all of qt5, you could restrict yourself to separate checkouts of qtbase.git, qtsvg.git and qtx11extras.git, this is enough to build kdelibs frameworks (but not enough for plasma-framework). NOTE: this solution is currently broken until the next qt5.git update. You'll have to use "git checkout 90361fd" in qtbase.
+
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).
 +
 
 +
<syntaxhighlight lang="bash">
 +
$ eval `dbus-launch`
 +
$ kdeinit5
 +
$ make test
 +
</syntaxhighlight>
 +
 
 +
'''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:''' <tt>KDE_FULL_SESSION=true</tt> 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
 +
 
 +
<syntaxhighlight lang="bash">
 +
$ xvfb-run -s '-screen 0 1024x768x24' make test
 +
</syntaxhighlight>
  
<b>NOTE for ArchLinux users</b>: qtwebkit uses python to generate some files, but it uses python2 syntax. So if you have installed python3, you'll get a compilation error on the file itab.py bevause print is no longer a statement, but a function. So, you would like to make /usr/bin/python to point to /usr/bin/python2. See also https://wiki.archlinux.org/index.php/Python
+
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 <tt>DBUS_SESSION_BUS_ADDRESS</tt> is not set, the tests should not find your existing DBus session, and instead launch a new DBus instance.
  
=== Qt5-based dependencies ===
+
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 [http://awesome.naquadah.org/ awesome] installed, you could create a script called <tt>awesome-run</tt> as follows:
  
First, let's setup a "kde:" prefix for git commands. Add the following text to your ~/.gitconfig:
+
<syntaxhighlight lang="bash">
  [url "git://anongit.kde.org/"]
+
#!/bin/sh
    insteadOf = kde:
+
awesome &
  [url "ssh://git@git.kde.org/"]
+
exec "$@"
    pushInsteadOf = kde:
+
</syntaxhighlight>
  
At this point you can continue building things by hand, or download http://www.davidfaure.fr/kde/kf5-qt5-kdesrc-buildrc into your source dir, adjust the paths and run kdesrc-build.
+
and then run the tests as
  
To build phonon by hand execute:
+
<syntaxhighlight lang="bash">
  $ git clone kde:phonon --branch phonon4qt5
+
$ xvfb-run -s '-screen 0 1024x768x24' /path/to/awesome-run make test
  $ mkdir phonon/build
+
</syntaxhighlight>
  $ cd phonon/build
 
  $ cmake -DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5 ..
 
  $ make
 
  $ make install
 
  
Then build attica (branch master), and strigi (branch master, with submodules) and install them into the same prefix.
+
If you want to publish your test results, instead of "make test" run
  
To check out and build libdbusmenu-qt execute:
+
<syntaxhighlight lang="bash">
  $ bzr branch lp:libdbusmenu-qt
+
$ make Experimental
  $ cd libdbusmenu-qt
+
</syntaxhighlight>
  $ mkdir build
 
  $ cd build
 
  $ cmake -DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5 ..
 
  $ make
 
  $ make install
 
  
= Build KDE frameworks =
+
The test results will appear on http://my.cdash.org/index.php?project=&lt;projectname&gt;
Current state of KDE framework exist in frameworks branch of kdelibs.
 
  
Execute:
+
== Testing Plasma ==
  $ git clone kde:kdelibs --branch frameworks
 
  $ mkdir  kdelibs/build
 
  $ cd kdelibs/build
 
  $ cmake -DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5 ..
 
  $ make
 
  $ make install
 
  
'''Debugging options''':
+
See [[Get Involved/development#Plasma]]
The default debug setting is RelWithDebInfo which is suitable for most developers. If you are debugging frameworks and cannot trace the code, you can set CMAKE_BUILD_TYPE to "DebugFull" to get a slower build but with even more verbose debugging (backtrace) information. For this replace -DCMAKE_BUILD_TYPE=RelWithDebInfo in the above cmake command with -DCMAKE_BUILD_TYPE=DebugFull.
 
  
'''Updating the already built framework''':
+
= Troubleshooting =
If the source code has been checked from a branch, it is possible to update the source code with newly added changes and build again. Usually only changing parts will be built, so this operation would be faster than building the source code from scratch.
 
  
Go to your source directory and execute following commands.
+
== Compilation: how to quickly solve build problems ==
  $ git pull --rebase
+
See [[Get Involved/development#How to solve build problems]]
  $ cd build
 
  $ make
 
  $ make install
 
  
== plasma-framework ==
+
== Runtime: Segfault when a sound is about to play (e.g. for a message box) ==
The Plasma libraries and runtime components have moved into a new repository: plasma-framework. To get libplasma and the QML support for Plasma, after building kdelibs as shown above, execute the following commands:
+
(added: 2015-02-27)
  
  $ git clone kde:plasma-framework
+
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:
  $ mkdir  plasma-framework/build
 
  $ cd plasma-framework/build
 
  $ cmake -DCMAKE_INSTALL_PREFIX=$KF5 -DCMAKE_PREFIX_PATH=$KF5 ..
 
  $ make
 
  $ make install
 
  
= Runtime setup =
 
To use your new KF5 install prefix (let's call it $KF5) :
 
 
<pre>
 
<pre>
export XDG_DATA_DIRS=$KF5/share:$XDG_DATA_DIRS
+
kate(9037)/default KNotificationManager::notify: Calling notify on "Sound"
export XDG_CONFIG_DIRS=$KF5/etc/xdg:$XDG_CONFIG_DIRS
+
Segmentation fault
export PATH=$KF5/bin:$PATH
 
export LD_LIBRARY_PATH=$KF5/lib:$QTDIR/lib:$LD_LIBRARY_PATH
 
  (lib64 instead of lib, on OpenSUSE and similar)
 
export QT_PLUGIN_PATH=$KF5/lib/plugins:$QTDIR/plugins:$QT_PLUGIN_PATH
 
  (lib64 instead of lib, on OpenSUSE and similar)
 
export QML2_IMPORT_PATH=$KF5/lib/qml
 
 
</pre>
 
</pre>
  
To use separate user settings for KF5:
+
This command can solve the problem:
 +
 
 +
<syntaxhighlight lang="bash">
 +
$ sudo /usr/lib64/vlc/vlc-cache-gen -f /usr/lib64/vlc/plugins
 +
</syntaxhighlight>
 +
 
 +
See also:
 +
* [[Plasma/5.1_Errata]]
 +
* https://forum.kde.org/viewtopic.php?f=289&t=122996
 +
 
 +
Alternative: go to kf5/build/kdesupport/phonon/phonon-vlc/ and exec `make uninstall`
 +
 
 +
== Runtime: kded5 crashes because of some component ==
 +
(added: 2015-Jan)
 +
 
 +
'''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.'''
 +
 
 +
Steps:
 +
 
 +
# Locate bluedevil files using <code>locate bluedevil</code>, for example.
 +
# Among the files there is <tt>kde/usr/share/kservices5/kded/bluedevil.desktop</code>. Remove it. If it was the cause, kded should stop crashing
 +
 
 +
'''Goal 2: Remove bluedevil from kdesrcbuild until it gets fixed.'''
 +
 
 +
Steps:
 +
 
 +
# Search through the <code>dev/kf5/src/extragear/utils/kdesrc-build/*-build-include</code> files to find the component. In this case, it was found in kf5-workspace-build-include.
 +
# Comment it out:
 
<pre>
 
<pre>
export XDG_DATA_HOME=$HOME/.local5
+
# module-set kf5-bluetooth-management
export XDG_CONFIG_HOME=$HOME/.config5
+
#    repository kde-projects
export XDG_CACHE_HOME=$HOME/.cache5
+
#    use-modules libbluedevil bluedevil
 +
# end module-set
 
</pre>
 
</pre>
  
To be able to compile other stuff on top of KF5:
+
Further calls of <code>kdesrc-build</code> will not include the component.
<pre>
+
 
export CMAKE_PREFIX_PATH=$KF5:$CMAKE_PREFIX_PATH
+
== Get more help ==
</pre>
+
 
 +
If you still have trouble with the building process or runtime setup, you can contact people as described in [[Get_Involved/development#Communicating_with_the_team|Communicating with the team]].
  
To get more information out of qDebug statements (i.e. make it more like kDebug) :
+
Feel free to join us by visiting [irc://irc.freenode.net/#kde-devel #kde-devel on Freenode]. A web-based client can be found at https://kiwiirc.com/client/irc.freenode.org/kde-devel
<pre>
 
export QT_MESSAGE_PATTERN='%{appname}(%{pid})/%{category} %{function}: %{message}'
 
</pre>
 
  
Don't bother with KDEDIR and KDEHOME etc.  this stuff isn't used anymore.
+
= Alternative building methods =
  
= Running unit tests =
+
== Kubuntu CI ==
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).
+
[[Kubuntu/PPAs#Kubuntu_Continuous_Integration_.28CI.29|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.
  
<pre>
+
== openSUSE Build Service ==
eval `dbus-launch`
+
[https://en.opensuse.org/SDB:KDE_repositories#Unstable_Frameworks.2C_Plasma_and_Applications 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.
kdeinit5
 
make test
 
</pre>
 
  
Warning: never start a KDE4 application in this separate DBus session, it would conflict with your running KDE4 desktop.
+
== Docker ==
 +
The docker container keeps the target KDE separate from the working installation, so no "contamination" with unstable code can occur.  
 +
* [[/Alternatives | Build with docker]]

Latest revision as of 15:38, 22 June 2019

Build KDE Frameworks and Applications

Design features

Qt and most KDE software are written in C++ whereas its "competitor" GTK is written in C making it very portable and easy to produce language bindings for (for Ruby, Python, Bash etc.). So it is possible to write a complete GTK GUI app in Bash script, but so far that has not been done for Qt.

Safety Precautions

Configuring your build environment is the single most important step in building KDE software. 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 Plasma 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 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. Another option is to use snapshots of a BTRfs formatted system harddisk and use snapper-GUI to roll back in case of an error. 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.

Configuration scripts

A set of configuration scripts and bash commands are provided as a recommended configuration when building KDE software manually. If you use these as provided then your 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.

Install required devel packages

This section provides information about required and optional software packages needed to build the KDE applications.

Qt5 is the base of KDE software. Your distro provides suitable devel packages containing prominently the Qt C++ header files below /usr/include/****.h . Optionally, you can build your own Qt5.

Follow this page to install the required dependencies.

Git remote prefix

See Get Involved/development#Configure Git

kdesrc-build

See Get Involved/development#Set up kdesrc-build

Testing

Running unit tests

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 "[email protected]"

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

$ make Experimental

The test results will appear on http://my.cdash.org/index.php?project=<projectname>

Testing Plasma

See Get Involved/development#Plasma

Troubleshooting

Compilation: how to quickly solve build problems

See Get Involved/development#How to solve build problems

Runtime: Segfault when a sound is about to play (e.g. for a message box)

(added: 2015-02-27)

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

See also:

Alternative: go to kf5/build/kdesupport/phonon/phonon-vlc/ and exec `make uninstall`

Runtime: kded5 crashes because of some component

(added: 2015-Jan)

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.

Steps:

  1. Locate bluedevil files using locate bluedevil, for example.
  2. Among the files there is kde/usr/share/kservices5/kded/bluedevil.desktop. Remove it. If it was the cause, kded should stop crashing

Goal 2: Remove bluedevil from kdesrcbuild until it gets fixed.

Steps:

  1. Search through the dev/kf5/src/extragear/utils/kdesrc-build/*-build-include files to find the component. In this case, it was found in kf5-workspace-build-include.
  2. Comment it out:
 # 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.

Get more help

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

Alternative building methods

Kubuntu CI

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.

openSUSE Build Service

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.

Docker

The docker container keeps the target KDE separate from the working installation, so no "contamination" with unstable code can occur.


This page was last edited on 22 June 2019, at 15:38. Content is available under Creative Commons License SA 4.0 unless otherwise noted.