Replace CMake source globs with explicit targets and shared target configuration #220

Closed
opened 2026-09-01 21:09:41 +02:00 by TapTap · 1 comment
Owner

Summary

The top-level build uses file(GLOB ...) for production and test sources at CMakeLists.txt:60-62 and CMakeLists.txt:81. CMake does not reliably reconfigure when files are added or removed from a glob, so a new source/test can be silently omitted until a manual reconfigure. The server, client, and tests targets also repeat include directories, library lists, and compile definitions across CMakeLists.txt:64-85, making build policy changes easy to apply inconsistently.

Scope

List source files explicitly (or use a controlled source manifest) and factor common include/link/options into reusable targets or functions. Keep fuzz target discovery separate if desired, but make its dependency set deliberate.

Acceptance criteria

  • Adding a production source or test requires a visible CMake-list change and cannot silently disappear from an existing build.
  • Common include paths and dependency linkage are defined once for server/client/tests.
  • A clean configure/build runs all current unit, integration, sanitizer, fuzz, and coverage targets as before.
  • Documentation or CMake comments explain the source-list maintenance convention.

Severity

low

Category

quality


Automated maintainability audit; no source changes were made.

## Summary The top-level build uses `file(GLOB ...)` for production and test sources at `CMakeLists.txt:60-62` and `CMakeLists.txt:81`. CMake does not reliably reconfigure when files are added or removed from a glob, so a new source/test can be silently omitted until a manual reconfigure. The `server`, `client`, and `tests` targets also repeat include directories, library lists, and compile definitions across `CMakeLists.txt:64-85`, making build policy changes easy to apply inconsistently. ## Scope List source files explicitly (or use a controlled source manifest) and factor common include/link/options into reusable targets or functions. Keep fuzz target discovery separate if desired, but make its dependency set deliberate. ## Acceptance criteria - Adding a production source or test requires a visible CMake-list change and cannot silently disappear from an existing build. - Common include paths and dependency linkage are defined once for server/client/tests. - A clean configure/build runs all current unit, integration, sanitizer, fuzz, and coverage targets as before. - Documentation or CMake comments explain the source-list maintenance convention. ## Severity low ## Category quality --- _Automated maintainability audit; no source changes were made._
TapTap added the qualityneeds-triage labels 2026-09-01 21:09:41 +02:00
Author
Owner

Fixed. All file(GLOB ...) usage is gone; sources are explicit lists (SHARED_SRCS, SERVER_*_SRCS, CLIENT_*_SRCS, TEST_SRCS, FUZZ_SRCS) in CMakeLists.txt, and common include/link/options are factored onto the fastsync_shared/*_core targets. Closing as completed.

Fixed. All `file(GLOB ...)` usage is gone; sources are explicit lists (`SHARED_SRCS`, `SERVER_*_SRCS`, `CLIENT_*_SRCS`, `TEST_SRCS`, `FUZZ_SRCS`) in `CMakeLists.txt`, and common include/link/options are factored onto the `fastsync_shared`/`*_core` targets. Closing as completed.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: TapTap/FastSync#220