Dev Log #5: Windows, Linux, macOS — eine Codebasis
Eine plattformübergreifende C++-Anwendung in 2026 zu bauen, ist immer noch schwerer als es sein sollte. Diese Woche haben wir die Windows- und Linux-Entwicklungsbranches in eine einzelne Codebasis zusammengeführt — und macOS baut aus derselben Quelle.
Das Build-System
CMake mit Presets. Eine CMakePresets.json handhabt:
- Linux: GCC/Clang mit System-Qt6, AppImage- oder .deb-Paketierung
- Windows: MSVC 2022 mit vcpkg-Abhängigkeiten und NSIS-Installer
- macOS: Homebrew Qt6, DMG-Bundling
Die build.sh (Linux/macOS) und build.bat (Windows) Skripte akzeptieren dieselben CLI-Argumente — --release, --debug, --clean — sodass CI und Entwickler denselben Workflow nutzen.
Statisches OpenSSL
TLS ist nicht verhandelbar für ein Tool, das Backup-Infrastruktur verwaltet. Onesimus linkt OpenSSL 3.6 statisch, kompiliert aus dem Quellcode als Git-Submodul. Das bedeutet:
- Keine Laufzeit-Abhängigkeit von der OpenSSL-Version des Systems
- Konsistentes Verhalten über Plattformen — gleiche Library, gleiche Code-Pfade
- Keine Überraschungen, wenn eine Distro OpenSSL 1.1 ausliefert, aber Bareos 3.x erwartet
Die CMake-Konfiguration erkennt automatisch, ob statisch oder dynamisch gelinkt werden soll, basierend auf der Plattform.
Qt 6.8 Minimum
Wir haben eine bewusste Entscheidung getroffen: Qt 6.8 oder neuer erforderlich. Das erlaubt uns moderne C++17-Features, die neuesten Qt-Networking-Verbesserungen und die neue Stylesheet-Engine — ohne Kompatibilitäts-Hacks für ältere Qt-Versionen zu pflegen.
Für Linux-Nutzer bedeutet das Ubuntu 24.04+, Fedora 40+ oder Qt aus dem Quellcode bauen. Das AppImage bündelt alles, sodass Endnutzer sich nicht darum kümmern müssen.
Erster Community-Beitrag
Die Cross-Platform-Arbeit hat unseren ersten externen Contributor angezogen: Build-Verbesserungen vom Bareos-Team selbst. Nichts validiert ein Projekt besser, als wenn sich die Upstream-Community beteiligt.