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 wiki page 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

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.

Improving Things

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:

  • run kdesrc-build --stop-on-failure dolphin
  • once it stops, figure out what’s the matter: go to ~/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 kdesrc-build

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 things in.

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 run 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.

Lessons

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.