|
|
| Line 1: |
Line 1: |
| = Build KDE Frameworks and Applications =
| | #REDIRECT [[Get Involved/development]] |
| | |
| == 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 <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.
| |
| | |
| == 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 [[/Details|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.
| |
| | |
| [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]].
| |
| | |
| Follow this page to [[/Install the dependencies|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 ==
| |
| See [[Guidelines and HOWTOs/UnitTests|Unit testing]]
| |
| | |
| == Testing Plasma ==
| |
| | |
| See [[Get Involved/development#Plasma]]
| |
| | |
| = Troubleshooting =
| |
| | |
| == Compilation: how to quickly solve build problems ==
| |
| See [[Get Involved/development#How to solve build problems]]
| |
| | |
| = Alternative building methods =
| |
| | |
| == Docker ==
| |
| The docker container keeps the target KDE separate from the working installation, so no "contamination" with unstable code can occur.
| |
| * [https://github.com/Wenzel/docker-kdesrc-build How to build with Docker]
| |
