Guidelines and HOWTOs/Build from source: Difference between revisions

From KDE Community Wiki
(Everything on this page is now available on https://community.kde.org/Get_Involved/development, so make it a redirect to that page)
Tag: New redirect
 
(105 intermediate revisions by 23 users not shown)
Line 1: Line 1:
= Build KDE Frameworks and Applications =
#REDIRECT [[Get Involved/development]]
 
== Safety Precautions ==
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 <tt>sudo make install</tt> can ''not'' always be undone by a simple <tt>sudo make uninstall.</tt> 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.
 
== Configuration scripts  ==
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 [[/Details| detailed instructions]].
 
== Install required devel packages ==
 
This section provides information about '''required''' and '''optional''' software packages needed to build the KDE applications.
 
Qt 5 (http://qt.io/) is the base of KDE software. Your distro provides suitable devel packages. Optionally, you can [[/OwnQt5| build your own Qt5]].
 
Follow this page to [[/Install the dependencies | install the required dependencies]].
 
== Git remote prefix ==
Let's setup a "kde:" prefix for git commands. Add the following text to your ~/.gitconfig:
<syntaxhighlight lang="ini">
[url "git://anongit.kde.org/"]
  insteadOf = kde:
[url "ssh://[email protected]/"]
  pushInsteadOf = kde:
</syntaxhighlight>
 
== Install kdesrc-build ==
''kdesrc-build'' is,  a user-space package manager, it is used to compile KDE-related projects from source and installs them into a designated directory.
 
Follow the given steps to set up kdesrc-build to install KDevelop into our $HOME directory:
<pre>
mkdir ~/kdesrc 
cd ~/kdesrc 
git clone kde:kdesrc-build 
cd kdesrc-build 
cp kdesrc-buildrc-kf5-sample ~/.kdesrc-buildrc
 
# Install a symlink of kdesrc-build to a location in PATH
mkdir ~/bin 
ln -s $PWD/kdesrc-build ~/bin 
export PATH=~/bin:$PATH
</pre>
 
You will need to append the line <pre>export PATH=~/bin:$PATH</pre> to <pre>~/.bashrc</pre> so kdesrc-build is available in PATH whenever you open a terminal.
 
 
'''Configure kdesrc-build
'''
edit<pre>~/.kdesrc-buildrc</pre> 
Replace <pre>/path/to/kdesrc-build/kf5-qt5-build-include</pre> with <pre>~/kdesrc/kdesrc-build/kf5-qt5-build-include</pre> in ~/.kdesrc-buildrc file
 
Add <pre>ignore-kde-structure true</pre> and <pre>make-options -jN</pre> to the global section in ~/.kdesrc-buildrc
<pre>
global 
  ...
  ignore-kde-structure true
  make-options -j5 # NOTE: 5 is the number of jobs, this should usually be (number-of-cpu-cores + 1)
  #stop-on-failure        true        # Stop kdesrc-build
  ...
end global 
</pre>
 
== Run kdesrc-build ==
{{Note|Note that this script uses GIT and Bazaar to download the sources, so ensure you have both installed. }}
{{Note|Ensure that C++ compiler is g++. Building KDE with clang has linking errors.}}
Installing KDevelop and dependencies
 
Let kdesrc-build handle the compilation + installation of KDevelop and its (direct) dependencies
 
$ kdesrc-build --debug libkomparediff2 grantlee kdevplatform kdevelop-pg-qt kdevelop
The --debug parameter will give you the verbose output, all command invocations and compiler output. Helpful for trouble-shooting.
 
 
== Run Kdevelop ==
Whenever you feel to run a self-compiled KDevelop, you just have to do the following commands in terminal:
# $ source ~/.env-kf5
# $ kdevelop
 
== Analyse and fix build errors ==
 
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:
* The latest build log is written to <pre>src/log/latest/<module-name>/</pre>
* In case of error there will be an '''error.log''' file with useful information. You will often see that there is only a build dependency missing.
 
= Runtime setup =
To use your new KF5 install prefix (let's call it $KF5) :
<syntaxhighlight lang="bash">
export KF5=<path to your intended frameworks install directory>
export QTDIR=<path to your qt5 install dir, or qtbase build dir if using uninstalled>
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 OpenSUSE and similar)
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
 
# To use separate user settings for KF5:
#export XDG_DATA_HOME=$HOME/.local5/share
#export XDG_CONFIG_HOME=$HOME/.config5
#export XDG_CACHE_HOME=$HOME/.cache5
 
# To be able to compile other stuff on top of KF5:
#export CMAKE_PREFIX_PATH=$KF5:$CMAKE_PREFIX_PATH
</syntaxhighlight>
 
Note that LD_LIBRARY_PATH isn't set. You shouldn't set it, the builtin rpath works magic instead, and if you set it you'll have issues when running tools that use uninstalled libs while building frameworks (e.g. meinproc, kconfig_compiler...)
 
For what works on Debian Sid alongside with packaged KF5 nicely see:
[https://wiki.debian.org/KdeBuildingFromSource Using (parts of) self-built KF 5, Plasma 5 and/or KDE Applications on Debian] (note I do set LD_LIBRARY_PATH there and it still uses any libraries from system that are not available self-built, it may depend on whether you want to build all of KF5/Plasma or just parts of it and whether you want the system wide parts to use your newly compiled stuff)
 
To get more information out of qDebug statements (i.e. make it more like kDebug) :
<syntaxhighlight lang="bash">
export QT_MESSAGE_PATTERN='%{appname}(%{pid})/%{category} %{function}: %{message}'
</syntaxhighlight>
or even better, to get colors:
<syntaxhighlight lang="bash">
c=`echo -e "\033"`
export QT_MESSAGE_PATTERN="%{appname}(%{pid})/(%{category}) ${c}[31m%{if-debug}${c}[34m%{endif}\
%{function}${c}[0m: %{message}"
unset c
</syntaxhighlight>
 
To set a KDE5 default editor (for git and svn)
<syntaxhighlight lang="bash">
export EDITOR="kwrapper5 kwrite"
</syntaxhighlight>
 
Don't bother with KDEDIR and KDEHOME etc.  this stuff isn't used anymore.
 
$ which ksnapshot
 
should show you now the location of the built version, ''not'' the one in the system path /usr/bin/ if you setup the paths correctly.
 
To '''run an application''', e.g. ksnapshot, 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). (Only needed when working under KDE4?). Kded5 is not needed for every feature but everytime when kioexec (which is used by KRun) is involved.
 
$ eval `dbus-launch` # no console output expected, (kdeinit5 is started automatically when needed)
$ ksnapshot
 
= 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).
 
<pre>
eval `dbus-launch`
kdeinit5
make test
</pre>
 
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 <pre>
xvfb-run -s '-screen 0 1024x768x24' make test
</pre>
(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 D-Bus session, and instead launch a new D-Bus 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 [http://awesome.naquadah.org/ awesome] installed, you could create a script called <tt>awesome-run</tt> as follows: <syntaxhighlight lang="bash">
#!/bin/sh
awesome &
exec "$@"
</syntaxhighlight>
and then run the tests as <pre>
xvfb-run -s '-screen 0 1024x768x24' /path/to/awesome-run make test
</pre>
 
If you want to publish your test results, instead of "make test" run <pre>
make Experimental
</pre>
The test results will appear on http://my.cdash.org/index.php?project=&lt;projectname&gt;
 
== Testing Plasma ==
 
The following page details how to [[/Test plasma | test Plasma]].
 
= Troubleshooting =
 
== Compilation: how to quickly solve build problems ==
 
Situation:
 
One or more modules fail to build via kdesrcbuild (displayed in red font).
 
'''Steps to solve''' (in the given order):
1) 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.
 
2) Check KDE build server if the module is maybe currently broken: http://build.kde.org/view/FAILED/
 
For the next two steps we assume your kf5 development directory structure looks like this:
kf5
  `- build
  `- src
  `- usr
 
3) If you get a build failure, simple fix might be to delete the build folder for that module and try building it again.
 
4) see [[#Analyse_and_fix_build_errors | Analyse and fix build errors]]
 
5) Delete '''build''' and '''usr'''. Run kdesrcbuild again.
 
6a) Ask on IRC or mailing list (see [[Getinvolved/development#Communicating_with_the_team| Communicating with the team]])
 
6b) Check if there are changes in the build instructions: see History of this wiki page.
 
7) Start over from scratch.
 
== Runtime: generic runtime problem ==
 
Try to delete ~/.cache5, ~/.config5, ~/.local5
 
(WARN: make sure not accidently delete your own config, the directories without the 5)
 
== 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:
* https://community.kde.org/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:
 
1) locate bluedevil files using <code>locate bluedevil</code>, for example.
 
2) Among the files there is <code>dev/kf5/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:
 
1) 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.
 
2) Comment it out:
<pre>
# module-set kf5-bluetooth-management
#    repository kde-projects
#    use-modules libbluedevil bluedevil
# end module-set
</pre>
 
Further calls of <code>kdesrcbild</code> will not include the component.
 
== Runtime: Couldn't start kded5 (KDE4) ==
(added: 2014-Dec)
 
Situation: developing and executing KF5 apps under KDE 4.
 
Problem by example: error message on console when starting ksnapshot in KF5 environment
 
<pre  style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: normal;">
ksnapshot(26577)/default KSycocaPrivate::checkDatabase: Couldn't start kded5 from org.kde.kded5.service: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.kde.kded5 was not provided by any .service files") , falling back to running kbuildsycoca5
</pre>
 
Solution (not verified yet): as said in the article, run this command before starting the app itself:
. setup-kf5-env      # (or as your script is called)
eval `dbus-launch`    # no output expected
ksnapshot            # no kded5 error message expected
 
== Runtime: Icon theme was changed (KDE4) ==
(added: 2014-Oct, verified: 2015-Feb)
 
Situation: developing and executing KF5 apps under KDE 4.
 
Problem: After working a bit with KF5 applications your regular KDE icon theme might be changed from oxygen to breeze.
 
Solution: see https://forum.kde.org/viewtopic.php?f=67&t=25032: Open "Icons - KDE Control Module" and change the theme back to Oxygen.
 
== Get more help ==
 
If you still have trouble with the building process or runtime setup you can contact people as described in [https://community.kde.org/Getinvolved/development#Communicating_with_the_team Communicating with the team].
 
More specifically, here is a list of beginner people who have recently had built the project and would like to specifically help with build problems. Feel free to add them to the recipient list when writing to the mailing list:
 
= Alternative building methods =
 
== Kubuntu CI ==
[https://community.kde.org/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.
 
== Docker ==
* [[/Alternatives | Build with docker]]

Latest revision as of 21:00, 25 July 2020