Codegen pipeline integration tests for the dsviper DevKit.
Two projects exercise the DSM → Kibo → templates → runtime pipeline:
features/— value-system features: data, stream, json, database, attachments, codecs, hashers, fuzz.service/— RPC / function-pool features: function pools, attachments pools, remote variants, bridges.
These projects are not built or run by the dsviper runtime CI. They serve as a manual
sanity check of the codegen pipeline and as a reference of how a downstream application
wires DSM definitions, Kibo, templates, and the runtime together.
This repo expects three sibling checkouts under a common parent directory:
<common parent>/
├── com.digitalsubstrate.viper/ # runtime + third_parties (C++ ; private)
├── kibo/ # Kibo jar (built via `mvn package`)
├── kibo-template-viper/ # Kibo templates (cpp/, python/)
└── devkit-codegen-test/ # this repo
The siblings live in their own repositories:
- viper — the Viper C++ runtime. Sources are not publicly distributed
(Digital Substrate Commercial License 1.2); the public artefact is the
dsviperwheel on PyPI. The full C++ build below therefore requires access to the runtime sources (Digital Substrate organisation members or licensed evaluation). The Python-only flow (features/python) is exercisable against an installeddsviperwheel without source access. - digital-substrate/kibo — code generator.
- digital-substrate/kibo-template-viper — first-party Kibo templates for the Viper ecosystem.
generate.py resolves Kibo and templates via:
KIBO_JARandKIBO_TEMPLATESenvironment variables, if set.- Otherwise,
../kibo/target/kibo-*.jarand../kibo-template-viper/.
CMakeLists.txt (via lib.cmake) locates the sibling
com.digitalsubstrate.viper/ checkout to build the third_parties (sqlite,
json, hash, antlr4, cli11) and the viper static target.
# 1. Generate C++ and Python code from the DSM definitions.
cd features
python3 generate.py all.dsm -c -p
cd ../service
python3 generate.py -c -p
# 2. Build the C++ executables (links viper from the sibling checkout).
cd ..
mkdir build && cd build
cmake ..
cmake --build . -j
# 3. Run the Python tests against the generated `features` package.
cd ../features/python
./run_test.shCMakeLists.txt skips features/ or service/ cleanly when their generated
content is missing, so a fresh clone configures without errors.
MIT — see LICENSE.