One of the important parts of getting-started in an project is setting up
a developer environment (if you want to do code contributions; other kinds
of contributions need different setup). Calamares has a thing called
deploycala.py which mangles the system it is run in (recommended only in
VMs or live-ISO) while the KDE project has a
on getting involved as a developer and a
build tool that can do initial
system setup and help with builds.
As a most-of-the-time-FreeBSD developer, I’m somewhat spoiled for a developer environment: a compiler (clang) is included, and installing package something also installs all the development tooling required for something. In other words: chasing development dependencies is pretty much trivial.
Many Linux distro’s support split dev-packages, and the names of those
vary per-distro. My own
deploycala.py script handles a half-dozen
common variants. The
kdesrc-build tool from KDE does something similar,
with known-dependencies lists for Alpine, Arch, Debian, Fedora, Gentoo,
Mageia and openSUSE (presumably “and derivatives”). So I decided to put this
to the test by turning my recently-installed Plasma Mobile on Desktop
into a development VM. Should be simple: the base is KDE neon User Edition,
which is (kind of like) Ubuntu, which is (kind of like) Debian, so it
ought to be straightforward.
The instructions on the wiki page go like this:
- Install basic tools (downloads 31.9MB)
- Configure git
- Clone kdesrc-build (downloads 4.07MiB)
- Run an initial setup as
kdesrc-build --initial-setup; this tells me it is installing packages for debian/20.04 (downloads 23.4MB) and finishes successfully
It is at this point that the instructions and what kdesrc-build has done diverge a little. Some non-KDE (build) dependencies have been installed, but not a lot of them. I tried to build a tier-1 framework, kwidgetsaddons which fails at CMake time: the Qt5UiPlugin package is not found.
After much futzing around (see below, Improving Things), I tried building dolphin, which is KDE’s file manager, and that failed too with missing KDE dependencies.
So there are things that can be improved, and – this being Open Source – I did.
The initial-setup code lives in a module called
FirstRun.pm – kdesrc-build is a perl program,
and it’s some of the nicer perl I’ve ever read.
Part of the file in
FirstRun.pm is a list of packages that
should be installed; a glance at the file told me that
the Fedora and openSUSE and Alpine (presumably thanks to Bart) package lists
were quite extensive, while Debian was really spartan.
That means that
kdesrc-build --initial-setup delivers a very
different developer experience on Debian as it does on
Fedora – there’s a lot more stuff to sort out, think through,
and do by hand on Debian. And hence, also on KDE neon.
My approach was simple:
kdesrc-build --stop-on-failure dolphin
- once it stops, figure out what’s the matter:
~/kde/build/and the subdirectory that failed, run
cmake .and read the output
- install likely packages for missing dependencies
- repeat until cmake succeeds, then go back to running
For each missing bunch of dependency packages, I added lines to the list of initial packages to install; after a bit of thought – I don’t know if Debian carries all the same package names as KDE neon – I split out KDE neon as a separate case, which means that Debian still has a limited package set, and KDE neon gets a much bigger one.
Once I had all the build-dependencies installed up to dolphin, I sent in a merge request to add the packages to the initial-setup phase. If it saves anybody else on KDE neon from having to chase package names, it’ll be worth it.
Note that I could do the same for FreeBSD in kdesrc-build; I just haven’t, because I don’t use kdesrc-build in a clean FreeBSD environment.
The dependencies between KDE frameworks – and between KDE software
products in general – are described in several places:
the CMakeLists.txt of each project is the definitive description,
but there is an echo of that information in the
repo-metadata repository which documents
the intra-project dependencies in a flat text format.
This is the file
kdesrc-build uses to figure out what order to build
In this repository the goal is not 100% fidelity, but some reasonable
set of build-dependencies. Since I think dolphin is a common
first-thing-to-build when starting KDE development (it is in the examples,
after all) I wanted to make sure that its dependency chain is complete.
So, here too I started with a fresh install and did nothing but
kdesrc-build dolphin until the automatic dependency resolution
did all the right things; that merge request (along with some
tidying up in the file) was submitted as well.
I started the week deeply disappointed in Linux as a development environment – that’s the way I put it on Twitter, anyway, where there’s no space for nuance. Point is, getting from an installed KDE neon to a usable developer experience was way harder than necessary – way harder than it is on Fedora or openSUSE. I think it’s worthwhile going over the getting-started instructions every now and then with a naive or grumpy person, to check that things are still accurate.
After spending some time on it, I understand the tools better, and the merge-requests I’ve sent upstream will hopefully,just maybe, make things better for everyone.
There is also a KDE neon developer edition which avoids a lot of this by providing all the frameworks development bits pre-installed; that avoids a lot of faffing about.