What
Decompose the 749-line top-level CMakeLists.txt into modular files under cmake/, leaving the root CMakeLists.txt as a thin orchestrator. Match the canonical cmake module layout used by sibling repos in the EPIC.
Why
A 749-line top-level CMakeLists is hard to review and prone to merge conflicts every time options/dependencies/install rules change. Sibling repos in the EPIC (kcenon/common_system #657 family) already use a per-concern cmake-module layout. Aligning container_system removes a recurring friction point for cross-repo refactors and makes future changes scoped.
Where
- Top-level
CMakeLists.txt (749 lines → expected ~50 lines after split)
- New / existing
cmake/ directory (some modules may already exist; verify before creating)
How
Technical Approach
Split top-level into per-concern modules. Suggested decomposition (adjust to match the canonical template once verified):
| Module |
Responsibility |
cmake/options.cmake |
option(...) declarations and feature toggles |
cmake/dependencies.cmake |
find_package, vcpkg, third-party resolution |
cmake/compile_options.cmake |
warning flags, sanitizers, std settings |
cmake/targets.cmake |
library/object target definitions |
cmake/sources.cmake |
target_sources aggregation |
cmake/install.cmake |
install + export + package config |
cmake/test.cmake |
enable_testing + ctest registration |
cmake/package.cmake |
CPack configuration |
Top-level CMakeLists.txt becomes: project(), policy settings, then include(cmake/...) calls in dependency order.
This sub-issue runs orthogonally to header/source migration in terms of file moves, but its target_sources listings must be kept in sync — coordinate ordering so this lands AFTER the source migration sub-issue or rebase carefully.
Acceptance Criteria
Estimated Size
L. The mechanical split is medium effort, but verifying install/export parity is fiddly.
Part of #531
What
Decompose the 749-line top-level
CMakeLists.txtinto modular files undercmake/, leaving the rootCMakeLists.txtas a thin orchestrator. Match the canonical cmake module layout used by sibling repos in the EPIC.Why
A 749-line top-level CMakeLists is hard to review and prone to merge conflicts every time options/dependencies/install rules change. Sibling repos in the EPIC (kcenon/common_system #657 family) already use a per-concern cmake-module layout. Aligning container_system removes a recurring friction point for cross-repo refactors and makes future changes scoped.
Where
CMakeLists.txt(749 lines → expected ~50 lines after split)cmake/directory (some modules may already exist; verify before creating)How
Technical Approach
Split top-level into per-concern modules. Suggested decomposition (adjust to match the canonical template once verified):
cmake/options.cmakeoption(...)declarations and feature togglescmake/dependencies.cmakefind_package, vcpkg, third-party resolutioncmake/compile_options.cmakecmake/targets.cmakecmake/sources.cmaketarget_sourcesaggregationcmake/install.cmakecmake/test.cmakecmake/package.cmakeTop-level
CMakeLists.txtbecomes: project(), policy settings, theninclude(cmake/...)calls in dependency order.This sub-issue runs orthogonally to header/source migration in terms of file moves, but its
target_sourceslistings must be kept in sync — coordinate ordering so this lands AFTER the source migration sub-issue or rebase carefully.Acceptance Criteria
CMakeLists.txt≤ ~80 lines (orchestrator only)cmake/<area>.cmakecmake -S . -B build && cmake --build buildsucceedsinstallstill produces the same export layout (verified by diffing install manifest)Estimated Size
L. The mechanical split is medium effort, but verifying install/export parity is fiddly.
Part of #531