Get Involved/development: Difference between revisions
Polish it a bit |
|||
Line 22: | Line 22: | ||
* Arch/Antergos/Manjaro: <code>sudo pacman -S git cmake dialog</code> | * Arch/Antergos/Manjaro: <code>sudo pacman -S git cmake dialog</code> | ||
* Fedora: <code>sudo dnf install git cmake dialog</code> | * Fedora: <code>sudo dnf install git cmake dialog</code> | ||
* KDE Neon/Kubuntu/Ubuntu/Debian: <code>sudo apt install git cmake dialog</code> | * KDE Neon/Kubuntu/Ubuntu/Debian: <code>sudo apt install git cmake dialog</code> | ||
* openSUSE Leap & Tumbleweed: <code>sudo zypper install git cmake dialog</code> | * openSUSE Leap & Tumbleweed: <code>sudo zypper install git cmake dialog</code> | ||
<br /> | |||
Some operating systems also require that you turn on the source repositories before you can install build dependencies (more about that later). Do that now, if necessary: | |||
* Kubuntu/Ubuntu/Debian: https://askubuntu.com/questions/158871/how-do-i-enable-the-source-code-repositories | |||
* openSUSE Leap & Tumbleweed: <code>sudo zypper mr -e $(zypper repos | awk '/source/{print $5}'))</code> | |||
Line 101: | Line 105: | ||
* Fedora: <code>sudo dnf builddep extra-cmake-modules</code> | * Fedora: <code>sudo dnf builddep extra-cmake-modules</code> | ||
* KDE Neon/Kubuntu/Ubuntu/Debian <code>sudo apt build-dep extra-cmake-modules</code> | * KDE Neon/Kubuntu/Ubuntu/Debian <code>sudo apt build-dep extra-cmake-modules</code> | ||
* openSUSE Leap & Tumbleweed: <code>zypper - | * openSUSE Leap & Tumbleweed: <code>sudo zypper si -d extra-cmake-modules</code> | ||
<br /> | <br /> | ||
Now let's use <code>kdesrc-build</code> to download, compile, and install <tt>extra-cmake-modules</tt>: | Now let's use <code>kdesrc-build</code> to download, compile, and install <tt>extra-cmake-modules</tt>: |
Revision as of 18:05, 6 November 2018
By joining the ranks of KDE developers, you will get to implement new features and defeat bugs both daunting and simple, all while collaborating to make coherent and stable releases. Developers collaborate in teams based on what area they are working in. These can be small teams working on a single application, up to large teams working on a group of related pieces of software. Many developers are in more than one team.
KDE runs or participates in several mentoring programs to help new developers, including an informal list of people who are willing to help newcomers get started. See the Mentoring page for more details.
New to C++/Qt software development?
Most KDE software is written in C++ using the Qt toolkit and KDE Frameworks. Though prior experience with these technologies or other programming languages is helpful, you don't need to be a C++ programmer to get started! For example, no programming knowledge whatsoever is required to do things like improve text labels.
One-time setup: your development environment
To build software, you need a development environment: a set of tools that allows you to access and edit source code, compile it into a form that the computer can run, and deploy it to a safe location. We will now go through the process of setting one up. To accomplish these tasks, you will need to enter commands using a terminal program, such as KDE's Konsole (any terminal program will suffice though).
Everything in this section only needs to be done once. Once you've done it, your development environment is set up and you can use it to submit patches and develop KDE Software!
Install basic tools
First you will need to use your operating system's package manager to install some basic tools:
- Arch/Antergos/Manjaro:
sudo pacman -S git cmake dialog
- Fedora:
sudo dnf install git cmake dialog
- KDE Neon/Kubuntu/Ubuntu/Debian:
sudo apt install git cmake dialog
- openSUSE Leap & Tumbleweed:
sudo zypper install git cmake dialog
Some operating systems also require that you turn on the source repositories before you can install build dependencies (more about that later). Do that now, if necessary:
- Kubuntu/Ubuntu/Debian: https://askubuntu.com/questions/158871/how-do-i-enable-the-source-code-repositories
- openSUSE Leap & Tumbleweed:
sudo zypper mr -e $(zypper repos | awk '/source/{print $5}'))
Configure Git
We need to set your authorship information properly so that any changes you make can be properly attributed to you:
git config --global user.name "Your Name" git config --global user.email "[email protected]"
Now we will set up a Git prefix to make it easier to interact with KDE's remote Git repositories. Use a text editor to open the ~/.gitconfig file and add the following:
[url "https://anongit.kde.org/"]
insteadOf = kde:
[url "[email protected]:"]
pushInsteadOf = kde:
Then save the file and close it. This essentially tells Git to accept "kde:" in place of "https://anongit.kde.org/", which allows us to check out repositories more easily, as we will soon see.
Set up kdesrc-build
Next, we need a method of managing dependencies. All software has dependencies: other pieces of software that provide functionality they rely on. In order to compile any piece of software, its dependencies must be available.
Most Linux-based operating systems do not provide development packages that are up-to-date enough for working on KDE software, so we will compile all the KDE dependencies ourselves. To do this, we use a command-line tool called kdesrc-build
to download, manage, and build KDE source code repositories. Let's set it up now:
mkdir ~/kde cd ~/kde git clone kde:kdesrc-build cd kdesrc-build
Notice how we're using the "kde:" prefix in our git clone
command!
We want to add kdesrc-build
to your system's $PATH variable so you can access it from anywhere, not just when you're inside ~/kde/kdesrc-build. Use a text editor to open the ~/.bashrc file and add export PATH=~/kde/kdesrc-build:$PATH. Then save the file and close it.
Next, set up kdesrc-build
using its built-in wizard. The default options should be ok, but feel free to customize anything:
./kdesrc-build-setup
Set up a runtime environment
In order to run the software that you're going to compile and install, you need to set up your runtime environment: a method to run installed software from a particular location. The operating system sets one up automatically for any software installed to /usr, but since we've installed our custom-compiled software to ~/kde/usr, we'll need to set up a runtime environment to let us run software from there.
Create a new file called ~/kde/.setup-env and copy the following text into it:
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"
Now your development environment is set up and ready to build software! Let's take it for a spin and compile some software.
Build some software
Remember our earlier discussion about dependencies? We use kdesrc-build
to manage dependencies on other KDE software, but most pieces of KDE software also depend on system libraries that are not owned or controlled by KDE. We use the operating system's package manager to get these.
Let's now do this to fetch the dependencies for a simple test project: extra-cmake-modules
- Arch/Antergos/Manjaro:
sudo pacman -S extra-cmake-modules
- Fedora:
sudo dnf builddep extra-cmake-modules
- KDE Neon/Kubuntu/Ubuntu/Debian
sudo apt build-dep extra-cmake-modules
- openSUSE Leap & Tumbleweed:
sudo zypper si -d extra-cmake-modules
Now let's use kdesrc-build
to download, compile, and install extra-cmake-modules:
cd ~/kde kdesrc-build extra-cmake-modules
Did that work? Great! Now let's build the Dolphin file manager. First download the non-KDE dependencies:
- Arch/Antergos/Manjaro:
sudo pacman -S dolphin
- Fedora:
sudo dnf builddep dolphin
- KDE Neon/Kubuntu/Ubuntu/Debian
sudo apt build-dep dolphin
- openSUSE Leap & Tumbleweed:
sudo zypper si -d dolphin
...Then use kdesrc-build
to download and compile Dolphin's KDE dependencies and then finally Dolphin itself:
cd ~/kde kdesrc-build dolphin
Did everything work? Fantastic. As a part of this process, Dolphin was installed to ~/kde/usr/bin/dolphin. source the ~/kde/.setup-env file every time you want to run your custom-compiled KDE software:
source ~/kde/.setup-env ~/kde/usr/bin/dolphin
Did it run? If so, then congratulations, you just compiled your own version of Dolphin from source code!
Choose what to do
Now that you can compile and deploy custom versions of KDE software, you can open your editor and get hacking! The code for the version of Dolphin hat you just built is located at cd ~/kde/build/kde/applications/dolphin/; other projects you use kdesrc-build
to download will be in similar locations.
A good place to start is with a small bug or feature in an existing piece of software that affects you personally ("scratch your own itch"). Get in touch with the existing developers (see Communicating with the team, below) and they can help you out, by pointing you to the right place in the code and giving advice about how to tackle the problem
Try not to start by proposing or working on major features or significant design changes. These can be controversial, and the smoothest way to get going is by working on relatively non-controversial bug-fixes. Start slowly and build trust!
Here are some other ideas for starting points:
- Improve awkwardly-worded messages and labels that are written in English. This is a great way for non-programmers to contribute! If you can compile software and have a good grasp of English, you can make a big difference here.
- Work on Junior Jobs, which are small tasks that are suitable for beginners (both bugs and features).
- Work on Bugs related to KDE's Usability & Productivity initiative, many of which are small and easy.
- The English Breakfast Network searches out simple, common issues in code that should be fixed, and going through the problems on there can provide a good overview of the code.
Test your patch
At this point, you have a patch. Make sure the project still compiles and installs, and make sure the patch has the desired effect when you run the software. Now it's time to run the project's unit tests:
source ~/kde/.setup-env cd ~/kde/build/kde/applications/dolphin/<project> make test
If any test fails, that needs to be investigated and fixed before you can proceed. Once the tests pass, then run the software again to make sure it still behaves properly. If it doesn't, then go back and work on your patch some more, then re-compile and re-deploy, and test again, until the program does what you'd like it to do and all tests pass.
Submit your patch
Once you're happy with your patch and have verified that it does what you want, you need to send it to other KDE developers for review. KDE uses Phabricator for this. Learn how to submit a patch with Phabricator
Communicate with the team
There are several ways to get in touch with KDE developers, either generally or for a specific project. The two most important communications channels are:
- The #kde-devel freenode IRC channel, which is where KDE developers chat in real time about their work
- The kde-devel mailing list is the primary development mailing list. learn more about mailing lists.
Both of these are general KDE development communication channels, and you may get directed to a more appropriate place for the project you are interested in. There is a list of mailing lists if you want to find a mailing list for a specific team directly. Many teams have their own Telegram rooms, too.
You can also try looking for the team's section on the Main Page of this wiki. Many teams have information there for new contributors.
Next steps
After you have had several patches accepted, a KDE developer is likely to suggest you get a Developer account, which will allow you to commit directly to KDE projects. With very few limits on where you can commit, you will be expected to act responsibly. At this point, congratulations! You are officially a KDE developer!
You may also want to set up a more permanent or advanced development environment, which will be very handy to start working on KDE Frameworks or Plasma itself. See Guidelines and HOWTOs/Build from source