Skip to content

[#674-3/5] Replace remaining hardcoded .cpp lists with structured globbing #677

Description

@kcenon

What

Replace every remaining hardcoded source-file list in CMakeLists.txt with structured file(GLOB_RECURSE ... CONFIGURE_DEPENDS) calls (or per-feature target_sources blocks built from a single glob result), unified with the existing MONITORING_HEADERS/MONITORING_SOURCES GLOBs.

Why

The current CMakeLists.txt mixes patterns:

  • Lines 525/529 already use file(GLOB_RECURSE) for headers and sources.
  • Line 619 still hardcodes a MONITORING_MODULE_SOURCES set.
  • The EPIC's framing ("13 hardcoded .cpp paths") came from this set plus other scattered hardcoded references.

Hardcoded lists drift silently when files move (the file moves but the list doesn't), which is exactly what the EPIC is trying to prevent. CONFIGURE_DEPENDS makes CMake pick up new files on reconfigure, eliminating the manual maintenance step entirely.

Where

  • CMakeLists.txt line 619 (MONITORING_MODULE_SOURCES hardcoded set)
  • Any other hardcoded .cpp listings discovered during the sweep
  • CMakeLists.txt lines 525/529 (existing GLOBs — unify pattern with the new ones, add CONFIGURE_DEPENDS if missing)

How

Technical Approach

  1. Sweep CMakeLists.txt (and any module under cmake/) for hardcoded .cpp/.h listings. Patterns to grep: set(... .cpp), target_sources(... .cpp), add_library(... .cpp ...).
  2. For each, decide:
    • Same pattern as MONITORING_HEADERS/MONITORING_SOURCES: replace with file(GLOB_RECURSE ... CONFIGURE_DEPENDS).
    • Per-target source set: keep the structure but populate it from a single GLOB filtered by directory.
  3. Add CONFIGURE_DEPENDS to existing GLOBs that lack it.
  4. Verify build: every source previously compiled is still compiled; nothing extra is dragged in.
  5. Run a regression test: touch a file, reconfigure, confirm CMake picks up the change.

Trade-off Note

file(GLOB) for source lists is contentious in CMake circles because it can hide additions/removals from version control during incremental builds. CONFIGURE_DEPENDS mitigates this for everyday workflows. The EPIC explicitly chose globbing as the desired outcome — this PR implements that decision; do NOT relitigate it.

Dependencies

  • Blocked by: src/impl consolidation sub-issue (so the GLOB result is stable)
  • Blocked by: legacy CMake fallback removal sub-issue (so the dual-structure branches are gone before we touch source listings)

Acceptance Criteria

  • Zero hardcoded .cpp / .h listings in CMakeLists.txt and any module under cmake/
  • All GLOBs use CONFIGURE_DEPENDS
  • Build green, ctest passes
  • Adding a new source file to src/<feature>/ and running cmake --build build/ builds it without manual list edits (verified by reviewer's test)

Estimated Size

S. Localised to CMakeLists.txt; mostly a substitution exercise.

Part of #674

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority/highHigh priority - Critical for productionsize/SSmall - Less than 1 day of worktype/buildBuild system and dependenciestype/refactorCode refactoring without functional changes

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions