Cabin: Cargo-Workflow für C/C++ mit Manifest, Registry und Beispielkatalog

Cabin: ein Cargo-inspirierter Paketmanager für C und C++

Cabin versteht sich als meinungsfreudiger Build- und Paketmanager für konventionelle C/C++-Projekte. Es nutzt ein deklaratives Manifest und ein vorhersagbares Projektmodell, um Build-Konfigurationsballast zu reduzieren. Inspiriert ist es von Cargo, dort, wo der Workflow sauber abbildbar ist, weicht es bewusst ab, wo C und C++ andere Semantik verlangen. Die Sprache des Projekts selbst ist Rust, die Lizenz Apache-2.0.

Wichtig für die Einordnung: Cabin ist noch vor der Version 1.0. Das README warnt ausdrücklich, dass Features unvollständig, experimentell oder einem Redesign unterworfen sein können. Die Release-Folge zeigt trotzdem Tempo, 0.15.0 vom Juni 2026, 0.16.0 zwei Wochen später und 0.17.0 im Juli 2026. Finanziell unterstützt wurde das Projekt 2018 über das MITOU IT Program in Japan, 2026 trägt Anthropics Programm Claude for Open Source zur Entwicklung bei. 1484 Sterne und nur 3 offene Issues deuten auf eine enge Kopplung zwischen Feature-Umfang und Pflege.

examples/, crates/ und ports/: drei Verzeichnisse mit drei Rollen

Die README unter examples/ zieht eine klare Grenze zwischen drei Verzeichnissen. examples/ enthält benutzerorientierte, ausführbare Cabin-Beispielprojekte, jedes Unterverzeichnis ein echtes Cabin-Paket mit eigener cabin.toml, Quellen und eigener README.md. Wer in ein beliebiges dieser Verzeichnisse wechselt, kann direkt bauen und starten.

crates/<name>/examples/ wäre der Ort für Cargo-Beispielziele der Rust-Crates, heute existieren dort aber keine. ports/ schließlich hält kuratierte Foundation-Ports, die echte Upstream-C/C++-Bibliotheken anpassen, die noch kein natives cabin.toml mitliefern. Jeder Port ist als Paket mit Herkunftsnachweis committet, und die Quellen, von denen die Registry-Pakete cabin-ports/* abhängen, werden von dort veröffentlicht. Diese Trennung ist mehr als Kosmetik: Beispiele können Ports konsumieren, ohne dass die Ports selbst als Beispiele geführt werden, und die Herkunftsprüfung der Upstream-Quellen ist im Port-Verzeichnis verankert.

Vom hello-c bis zu feature-gated-targets im Beispielkatalog

Der Beispielkatalog deckt die Build-Funktionen systematisch ab. hello-c und hello-cpp sind die kleinsten sinnvollen Projekte mit je einem ausführbaren Ziel. library-and-app zeigt eine Bibliothek, die von einer ausführbaren Datei im selben Paket konsumiert wird, inklusive Weitergabe von include-dirs. library-with-tests ergänzt zwei Testziele, die über cabin test laufen. header-only-lib definiert ein Header-only-Ziel, bei dem nichts kompiliert wird, ein typischer C/C++-Sonderfall, den Cargo-Analogien selten abbilden.

Weiter geht es mit workspace-basic, einer virtuellen Workspace-Wurzel mit zwei Mitgliedern, verbunden über eine Pfadabhängigkeit. workspace-app-and-lib kommt zusätzlich mit einer Registry-Paketabhängigkeit, die transitiv über eine Pfadabhängigkeit erreicht wird. feature-gated-targets sperrt eine optionale Bibliothek hinter required-features und expliziten Abhängigkeitslinks. Kleinere Anwendungen runden den Katalog ab: json-cli macht einen JSON-Roundtrip, png-info schiebt Bilddaten über die transitive Kante von libpng zu zlib, und platform-cfg kompiliert je nach Windows oder Unix unterschiedliche Makros.

cabin-ports/*: zlib, libpng und spdlog aus der Registry

Viele Beispiele konsumieren Registry-Pakete aus cabin-ports/* für gängige Bibliotheken: zlib, sqlite3, libpng, fmt, spdlog, googletest, catch2, nlohmann_json, CLI11, miniz, stb, uthash, inih und picohttpparser. Das Beispiel cli-with-spdlog kombiniert CLI11 für die Argumentverarbeitung, {fmt} für Formatierung und spdlog für Logging zu einem kompletten kleinen Programm.

Diese Liste zeigt den praktischen Wert des Port-Konzepts. Statt jede Bibliothek von Hand zu beschaffen und in den Build einzubinden, deklariert man eine Abhängigkeit auf ein Port-Paket, dessen Herkunft über den committeten Port und die Publisher-Pipeline nachvollziehbar bleibt. Für Projekte, die heute Build-Skripte um zlib oder sqlite3 stricken, ist das der eigentliche Zugewinn: Die Version, der Quellenursprung und die Konfiguration stehen im Manifest und im Port, nicht in einer Vereinbarung zwischenINSTALL.md, Wildwuchs und Tribal Knowledge im Team.

Erste Schritte mit cabin build und cabin run in hello-cpp

Der manuelle Einstieg ist absichtlich einfach gehalten. Die README nennt als Wegweiser: cd examples/hello-cpp, dann cabin build, dann cabin run. cabin run baut das executable-Ziel des Pakets und startet es. Abweichungen sind möglich, aber dokumentiert: Die README jedes Beispiels nennt den exakten Befehl, falls er von dieser Standardfolge abweicht.

Für die Installation selbst verweist die README auf den Installationsteil der Cabin-Dokumentation unter cabinpkg.com/docs/installation/, den Weg aus den Quellen über INSTALL.md markiert sie ausdrücklich als nicht empfohlen. Wer Cabin für ein eigenes Projekt bewerten will, bekommt damit eine reproduzierbare Ausgangslage: Beispiele im Repository ausführen, dann das eigene Projekt anfangs so strukturieren wie library-and-app oder workspace-basic, um Manifest-Syntax und include-Weitgabe im kleinen Rahmen zu prüfen.

Integrationstests über cargo test --test cabin_examples und Apache-2.0

Das Repository führt Integrationstests, die jedes Beispiel mit dem mitgelieferten cabin-Binary bauen und ausführen. Der Aufruf von der Repository-Wurzel lautet cargo test --test cabin_examples. Vor dem Bauen kopieren die Tests jedes Beispiel in ein temporäres Verzeichnis, damit der Quellbaum keine Build-Ausgaben ansammelt. Tests, die echte Quellen kompilieren, schlagen mit klarer Meldung fehl, wenn Ninja oder ein C/C++-Compiler fehlt, das ist die minimale Werkzeugvoraussetzung.

Tests für Beispiele, die cabin-ports/*-Pakete konsumieren, sind mit #[ignore] markiert, weil sie ausgehenden Netzwerkzugriff brauchen. Sie laufen mit cargo test --test cabin_examples -- --ignored, bereiten die committeten Ports über die Publisher-Pipeline in einer lokalen Datei-Registry vor, laden die festgelegten Upstream-Archive herunter und bauen jedes Beispiel mit --index-path gegen diese Registry. Die Apache-2.0-Lizenz erlaubt kommerzielle Nutzung samt Patentlizenz mit bestimmten Beendigungsbedingungen, für den Einsatz im Team ist das unkritisch. Offen bleibt, wie stabil die Port-Abdeckung über die nächsten 0.x-Versionen wächst, das Beispielverzeichnis ist der ehrlichste Spiegel dieses Fortschritts.

Redaktionelles Fazit

Cabin eignet sich für konventionelle C/C++-Projekte, die einen expliziten, paketorientierten Workflow suchen und auf frei programmierbare Build-Systeme verzichten können. Wer exotische Toolchain-Anforderungen hat oderProduktionssicherheit vor Version 1.0 braucht, sollte zurückschrecken. Vor dem Ernstfall lohnt der Weg über cd examples/hello-cpp mit cabin build und cabin run sowie ein cargo test --test cabin_examples -- --ignored, um Registry-Abhängigkeiten in der eigenen Umgebung zu prüfen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes