This page summarizes the repository workflows used to validate JRM itself.
link:example$commands.sh[role=include]link:example$commands.sh[role=include]The test target stages acceptance inputs under <build-dir>/tests/JRMTests-reflection/<config>/ and runs JRM there.
Generated headers and cache files stay in the build tree. Unchanged builds skip generation.
CTest runs the complete suite; direct invocation of JRMTests remains supported.
Tests cover configuration and cache behavior, preprocessing and scope navigation, reflector diagnostics, generated-file integration, metadata, class and enum serialization, inheritance, and runtime adapter behavior.
Prefer incremental builds. Use a clean build only after structural CMake or toolchain changes, or when the build cache is demonstrably stale.
| Option | Default | Effect |
|---|---|---|
|
Context-dependent |
Explicit values win. Otherwise follows an existing |
|
|
Install shared skill links explicitly. Requires the pinned Agents submodule and a Git checkout. |
|
|
Treat JRM warnings as errors; enabled in CI. |
|
|
Build |
|
|
Instrument supported GCC or Clang targets. Tests must remain enabled. |
|
|
Add the |
|
|
Select the report directory. It must be a child of JRM’s binary directory, separate from build artifacts. Multi-config builds append the configuration name. Existing nonempty directories must carry the |
link:example$commands.sh[role=include]Presets use separate directories under build/. Available configurations include debug, release, Linux gcc-debug, gcc-release, clang-debug, clang-release, benchmark, coverage-gcc, and coverage-clang.
Compiler-specific presets require the corresponding toolchain on PATH.
Coverage presets also require matching coverage tools.
Use an ignored CMakeUserPresets.json for personal overrides.
For MSVC, run the portable presets from a developer command prompt.
link:example$commands.sh[role=include]Multi-config executables are under bin/<config>/ and libraries under lib/<config>/.
Separate configurations stage independent reflection projects.
CMake generates the version header under <build-dir>/include/JustReflectMe/.
In-source builds are rejected.
Normal builds need no Git or agent tooling once required build dependencies are populated.
Parent projects retain their output-directory, compiler-launcher, and runtime settings.
The repository targets C++26 as an engineering policy while retaining a current CMake cxx_std_26 feature requirement for available toolchains.
MSVC debug information uses embedded /Z7-style data for ccache compatibility.
Before committing C changes, run clang-format on changed C/C files and clang-tidy with a configured compile_commands.json.
CI checks formatting, static analysis, GCC and Clang builds, unit tests, coverage, and Valgrind.
For documentation example changes, the focused format check is:
link:example$commands.sh[role=include]The Google Benchmark target measures StringHelper and FileNavigationHelper primitives used by scanning: replacement, trimming, splitting, line navigation, bounded search, line/column calculation, type-name parsing, and scope-end discovery.
It does not currently benchmark a complete project scan, so do not present those microbenchmarks as end-to-end generation latency.
link:example$commands.sh[role=include]Use Release builds, repeat measurements on the same machine and power mode, and compare matching benchmark names and argument sets. Coverage instrumentation and benchmarks cannot be enabled in the same CMake configuration.
link:example$commands.sh[role=include]Coverage supports GCC and Clang and writes an HTML report below the selected build directory.
GCC requires gcov and gcovr; Clang requires matching llvm-profdata and llvm-cov tools.
link:example$commands.sh[role=include]Valgrind complements normal unit tests for lifetime, allocation, filesystem, and ownership-sensitive changes. The repository wrapper fails on memory errors and definite leaks.
Documentation sources use the Antora component layout below docs/modules/ROOT.
After changing source pages and tagged examples, build the site as a separate step from the repository root:
link:example$commands.sh[role=include]The generated docs/html directory is build output and must not be edited or used as documentation source.