2.5 KiB
Repository Guidelines
Project Structure & Module Organization
Core code lives in src/ and public headers in include/cvmmap_streamer/. The main runtime is src/main_streamer.cpp; shared logic is split by concern under src/config, src/core, src/ipc, src/pipeline, src/protocol, and src/metrics. Test utilities are standalone binaries in src/testers/. Automation and release gates live in scripts/, while operator notes and smoke-test profiles live in docs/. Third-party dependencies are vendored in lib/ and should only be changed deliberately.
Build, Test, and Development Commands
Configure and build with:
cmake -B build -S .
cmake --build build
This produces build/cvmmap_streamer, build/rtp_receiver_tester, build/rtmp_stub_tester, and build/ipc_snapshot_tester.
Use cmake --fresh -B build -S . if CMake caches stale dependency paths. Run the mandatory acceptance matrix with ./scripts/acceptance_standalone.sh and the baseline fault suite with ./scripts/fault_suite.sh. For targeted manual checks, run the built testers directly against build/cvmmap_streamer.
Coding Style & Naming Conventions
This project targets C++23. Follow the existing style: tabs for indentation, braces on the same line, snake_case for functions and variables, PascalCase for types and enums, and lowercase directory names by subsystem. Keep headers under include/cvmmap_streamer/... aligned with their implementation paths where practical. No formatter or linter config is checked in, so match the surrounding file exactly before submitting changes.
Testing Guidelines
There is no top-level unit-test framework in this repo; verification is primarily binary- and script-driven. Add behavior checks through src/testers/ and extend the shell suites in scripts/ when introducing new protocol or fault scenarios. Prefer deterministic inputs such as the dummy backend (--input-mode dummy) and keep labels short. Review generated evidence under .sisyphus/evidence/ when validating failures.
Commit & Pull Request Guidelines
Recent history uses Conventional Commit prefixes such as feat(...), fix(...), refactor(...), test(...), build(...), and chore(...). Continue that pattern and keep scopes specific, for example refactor(protocol): simplify wire codec setup. PRs should explain the runtime impact, list the commands you ran, and attach relevant logs or screenshots when output behavior changes. Link any issue or task ID when one exists.