paulhorn
da43859b97
Layout, Build und Konventionen analog zu mydb und cxx_scaffold_cli: Header und Quellen nebeneinander in playground/, Unit-Tests als .test.c/.test.cpp daneben, Integrationstests in tests/. Geruest-Module counter (C, Unity) und notebook (C++, doctest) zeigen jede Regel einmal an lauffaehigem Code. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.4 KiB
ADR 0001 — Toolchain und Projektstruktur
- Status: akzeptiert
- Datum: 2026-08-30
Kontext
playground soll ein Ort zum Ausprobieren sein, aber kein Ort, an dem jedes
Mal neu über Verzeichnisnamen, Include-Form und Testablage entschieden wird.
Die bestehenden Projekte mydb und cxx_scaffold_cli haben diese Fragen
bereits beantwortet.
Entscheidung
Struktur nach P1204R0, Build- und Stilkonfiguration wörtlich von mydb
übernommen (.clang-format, .clang-tidy, .clangd, .editorconfig,
CMakePresets.json, cmake/), lediglich das Makro- und Target-Präfix von
MYDB_/mydb_ auf PLAYGROUND_/playground_ umgestellt.
Die vendorten Abhängigkeiten (Unity 2.7.0, doctest 2.5.3) wurden aus
mydb/third_party/ kopiert statt neu geholt — damit sind die Versionen über
alle Projekte hinweg identisch.
Konsequenzen
Ein Wechsel zwischen den Projekten kostet keine Umgewöhnung, und ein hier erprobtes Modul lässt sich unverändert in ein anderes Projekt heben.
Der Preis ist Duplikation: eine Änderung am Hausstandard muss in jedem Repo
einzeln nachgezogen werden. Das war schon vor diesem Repo so; cxx_scaffold_cli
ist der Ort, an dem eine gemeinsame Vorlage entstehen müsste.
Offen bleibt, dass docs/CONVENTIONS.md in mydb ein check_style.sh und ein
tools/vendor.sh beschreibt, die in keinem der Repos existieren. In der
playground-Fassung sind diese Verweise entfernt.