Difference between revisions of "Guidelines and HOWTOs/Build from source"
|Line 23:||Line 23:|
== Git remote prefix ==
== Git remote prefix ==
== kdesrc-build ==
== kdesrc-build ==
Revision as of 19:59, 7 April 2019
- 1 Build KDE Frameworks and Applications
- 2 Testing
- 3 Troubleshooting
- 4 Alternative building methods
Build KDE Frameworks and Applications
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.
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.
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.
Follow this page to install the required dependencies.
Git remote prefix
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>
The following page details how to test Plasma.
Compilation: how to quickly solve build problems
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.
- You may not have all dependencies installed. Read the output to see what missing dependency it is complaining about, search for the corresponding package for your distro, and install it.
- Check the list of currently broken modules on the KDE build server.
- If you get a build failure, simple fix might be to delete the build folder for that module and try building it again.
- See Analyse and fix build errors.
- Delete ~/kde/build and ~/kde/usr. Run
- Ask for help on IRC or some mailing list, see Communicating with the team.
- Check if there are changes in the build instructions: see History of this wiki page.
- Start over from scratch.
Runtime: Segfault when a sound is about to play (e.g. for a message box)
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`
Runtime: kded5 crashes because of some component
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 files using
locate bluedevil, for example.
- 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.
- Search through the
dev/kf5/src/extragear/utils/kdesrc-build/*-build-includefiles to find the component. In this case, it was found in kf5-workspace-build-include.
- 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 (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.
The docker container keeps the target KDE separate from the working installation, so no "contamination" with unstable code can occur.