What
Decompose the (post sub-issues #1-#3) root CMakeLists.txt into per-concern modules under cmake/, leaving the top-level file as a thin orchestrator (~50-80 lines: cmake_minimum_required, project(...), policy settings, then include(cmake/...) calls in dependency order). Match the canonical layout used by sibling repos in the broader EPIC.
Why
After the legacy fallback removal and source-list cleanup, the remaining content of CMakeLists.txt is still monolithic. Sibling repos in the ecosystem (e.g. container_system after PR #540) already use a per-concern cmake-module layout. Aligning monitoring_system removes a recurring friction point: every time someone touches options/dependencies/install rules they no longer have to scroll through ~600+ lines to find the right block.
The container_system precedent (kcenon/container_system PR #540) reduced its top-level from 743 → 49 lines and produced 11 modules. monitoring_system should land in a similar range after sub-issues #1-#3 trim the file first.
Where
- Top-level
CMakeLists.txt
- Existing
cmake/ directory (verify what's already modular before creating duplicates)
How
Suggested Decomposition
Adapt to reality after inspecting existing cmake/:
| Module |
Responsibility |
cmake/options.cmake |
option(...) declarations, feature toggles |
cmake/dependencies.cmake |
find_package, vcpkg, third-party resolution |
cmake/compile_options.cmake |
warning flags, sanitizers, std settings, IPO/LTO |
cmake/sources.cmake |
source-list file(GLOB_RECURSE ...) calls (post sub-issue #3) |
cmake/targets.cmake |
add_library(...) and target_* calls |
cmake/install.cmake |
install() rules, export sets, package config |
cmake/test.cmake |
enable_testing(), ctest registration |
cmake/documentation.cmake |
Doxygen target wiring (if present) |
cmake/summary.cmake |
end-of-configure summary block (if present) |
If cmake/ already contains some of these, extend them rather than overwriting.
Important: behaviour parity
This is a refactor, not a redesign. Expected outputs:
- Build artefacts identical to pre-PR
develop
cmake --install produces the same export layout- ctest results match
If local toolchain available: diff cmake --install build/ --prefix /tmp/before vs /tmp/after. Otherwise rely on CI delta.
Dependencies
- Blocked by: legacy fallback removal sub-issue (no point decomposing two paths)
- Blocked by: hardcoded paths cleanup sub-issue (so the source-list module is meaningful)
Risk Profile
Higher than sub-issues #1-#3. CMake decomposition rearranges variable scope, evaluation order of find_package vs option, and target-property propagation. Expect at least one CI ordering issue to surface — honour the 3-fail rule strictly.
Acceptance Criteria
Estimated Size
L. Mechanical relocation is medium effort; verifying parity is fiddly.
Part of #674
What
Decompose the (post sub-issues #1-#3) root
CMakeLists.txtinto per-concern modules undercmake/, leaving the top-level file as a thin orchestrator (~50-80 lines:cmake_minimum_required,project(...), policy settings, theninclude(cmake/...)calls in dependency order). Match the canonical layout used by sibling repos in the broader EPIC.Why
After the legacy fallback removal and source-list cleanup, the remaining content of
CMakeLists.txtis still monolithic. Sibling repos in the ecosystem (e.g. container_system after PR #540) already use a per-concern cmake-module layout. Aligning monitoring_system removes a recurring friction point: every time someone touches options/dependencies/install rules they no longer have to scroll through ~600+ lines to find the right block.The container_system precedent (kcenon/container_system PR #540) reduced its top-level from 743 → 49 lines and produced 11 modules. monitoring_system should land in a similar range after sub-issues #1-#3 trim the file first.
Where
CMakeLists.txtcmake/directory (verify what's already modular before creating duplicates)How
Suggested Decomposition
Adapt to reality after inspecting existing
cmake/:cmake/options.cmakeoption(...)declarations, feature togglescmake/dependencies.cmakefind_package, vcpkg, third-party resolutioncmake/compile_options.cmakecmake/sources.cmakefile(GLOB_RECURSE ...)calls (post sub-issue #3)cmake/targets.cmakeadd_library(...)andtarget_*callscmake/install.cmakeinstall()rules, export sets, package configcmake/test.cmakeenable_testing(), ctest registrationcmake/documentation.cmakecmake/summary.cmakeIf
cmake/already contains some of these, extend them rather than overwriting.Important: behaviour parity
This is a refactor, not a redesign. Expected outputs:
developcmake --installproduces the same export layoutIf local toolchain available: diff
cmake --install build/ --prefix /tmp/beforevs/tmp/after. Otherwise rely on CI delta.Dependencies
Risk Profile
Higher than sub-issues #1-#3. CMake decomposition rearranges variable scope, evaluation order of
find_packagevsoption, and target-property propagation. Expect at least one CI ordering issue to surface — honour the 3-fail rule strictly.Acceptance Criteria
CMakeLists.txt≤ ~80 lines (orchestrator only)cmake/<area>.cmakedevelop(verified by diff if possible, otherwise by reasoning)pass/neutralEstimated Size
L. Mechanical relocation is medium effort; verifying parity is fiddly.
Part of #674