Containerized KDE Development: Building the Mankala Engine with Distrobox

As part of my work on the Mancala for Season of KDE, I needed to compile the backend mankalaengine from source. Running Ubuntu 24.04 LTS on my host system, I wanted to keep it clean and avoid dependency conflicts while designing digital assets. I decided to build the C++ engine inside an isolated container using Distrobox.

What seemed like a straightforward compilation turned into a great learning experience in container troubleshooting and build systems. Here is how I got it working.

The False Start: openSUSE Tumbleweed

The KDE documentation highly recommends using Distrobox with a rolling-release distribution to ensure access to the latest KDE Frameworks. Naturally, I started with openSUSE Tumbleweed:

distrobox create --image docker.io/opensuse/tumbleweed --name kde-dev
distrobox enter kde-dev

However, the container instantly crashed on startup with this error:

sed: can't read /etc/zypp/zypp.conf: No such file or directory

The Fix: It turns out the default opensuse/tumbleweed image on Docker Hub is a highly stripped-down "micro" image. It lacks core configuration files that Distrobox expects during its initialization script. Rather than fighting the micro-image, I pivoted to an image guaranteed to have the standard toolchains out of the box.

The Solution: Arch Linux

Arch Linux is heavily used in the KDE development community and plays perfectly with Distrobox. I cleaned up the broken container and spun up an Arch environment:

distrobox stop kde-dev
distrobox rm kde-dev
distrobox create --image docker.io/archlinux:latest --name kde-dev
distrobox enter kde-dev

This time, the initialization was flawless. Once inside the container, I pulled down the required KDE build dependencies using pacman:

sudo pacman -Syu base-devel cmake extra-cmake-modules ki18n

The Build System Hiccup

With the dependencies installed, I navigated to my mankalaengine directory (which Distrobox automatically mounts from the host) to configure the build:

mkdir build
cd build
cmake ..

This immediately threw a CMake error:

The C++ compiler "/usr/bin/c++" is not able to compile a simple test program.

While the C++ compiler was installed, the underlying build automation tool was missing. In the KDE ecosystem, the standard is Ninja—a lightning-fast build system designed to replace traditional make.

I installed Ninja, cleared the broken build cache, and reconfigured CMake to use it:

sudo pacman -S ninja make
rm -rf *
cmake -G Ninja ..

Compiling and Running

With CMake successfully generating the Ninja blueprints, compiling the engine was just a single command away:

ninja

The build finished in seconds. To verify everything worked, I wanted to test out the Text User Interface (TUI) examples included in the repository.

In KDE projects, CMake is usually configured to place all compiled binaries into a central directory. I navigated to the bin folder and launched the Kalah variant:

cd bin/
./kalahtui

The terminal interface booted up perfectly, drawing the board and allowing me to play directly against the engine's AI.

Conclusion

Using Distrobox is a game-changer for KDE development. Even with a few initial hiccups regarding container images and build tools, having a disposable, bleeding-edge Arch Linux environment running seamlessly alongside my Ubuntu 24.04 LTS host makes compiling C++ projects incredibly efficient. I get the stability of an LTS release for my daily work while accessing the latest KDE Frameworks in an isolated container.