Baf 1715/cmake migration

[martinburian-ba]

Summary

Migrates mission-module (v2.0.0) off cmlib onto plain CMake + FetchContent,
following the same pattern established in external-server-cpp (BAF-1706).

• Replaces FIND_PACKAGE(CMLIB ...) / CMDEF_ADD_LIBRARY / CMDEF_INSTALL
  usage with a cmake/FindCMLIB.cmake compatibility shim, so the rest of
  CMakeLists.txt is unchanged.
• Adds FindBA*.cmake modules that resolve each dependency via a system/
  config package first, falling back to FetchContent (nlohmann_json,
  fleet-protocol-interface, fleet-protocol-cxx-helpers-static,
  async-function-execution-shared, aeron, fleet-http-client-shared, Boost,
  ZLIB, cpprestsdk).

Fixes on top of the original migration commit

Found while verifying the migration builds:

1. Configure failed immediately — the migration dropped
   FIND_PACKAGE(CMLIB COMPONENTS CMDEF CMUTIL STORAGE REQUIRED) from
   CMakeLists.txt, so cmake/FindCMLIB.cmake (which defines
   CMDEF_ADD_LIBRARY/CMDEF_INSTALL) was never loaded. Restored the call.
2. Wrong package version — the CMDEF_PACKAGE shim was a no-op and
   silently dropped its VERSION argument, so cpack always produced
   0.1.1 instead of the real module version. Shim now sets
   CPACK_PACKAGE_VERSION from the passed version.

Verification

• Native x86_64 build (module-gateway variant,
  -DFLEET_PROTOCOL_BUILD_EXTERNAL_SERVER=OFF): configure, build, and
  cpack all pass — MissionModule-2.0.0-Linux.zip.
• Native x86_64 package build (both variants,
  -DBRINGAUTO_PACKAGE=ON, matching what the real deploy pipeline runs):
  passes.
• Ran the real fleet-os-deploy pipeline end to end against a temp tag on
  this branch (temp/baf-1715-deploy-verify) — steps 1-7 and the aarch64
  dependency-sysroot assembly all pass. The run is currently blocked only
  by the fleet-os-3 cross-compile Docker image not being available in any
  reachable registry — an infra gap unrelated to this change (it fails
  before even reaching this module, on module-gateway).

Closes BAF-1715.

[coderabbitai]

Warning

Review limit reached

@martinburian-ba, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 59 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 7a88dd3d-3877-4c5b-be0b-f849512caf5b

📥 Commits

Reviewing files that changed from the base of the PR and between 29f0102 and 38fa095.

📒 Files selected for processing (19)

• CLAUDE.md
• CMLibStorage.cmake
• CMakeLists.txt
• cmake/Dependencies.cmake
• cmake/FindBAAeron.cmake
• cmake/FindBAAsyncFunctionExecution.cmake
• cmake/FindBABoost.cmake
• cmake/FindBACppRestSdk.cmake
• cmake/FindBAFleetHttpClient.cmake
• cmake/FindBAFleetProtocolCpp.cmake
• cmake/FindBAFleetProtocolInterface.cmake
• cmake/FindBANlohmannJson.cmake
• cmake/FindBAProtobuf.cmake
• cmake/FindBAZlib.cmake
• cmake/FindCMLIB.cmake
• cmake/Findasync-function-execution-shared.cmake
• cmake/Findfleet-http-client-shared.cmake
• cmake/Findfleet-protocol-cxx-helpers-static.cmake
• cmake/Findfleet-protocol-interface.cmake

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch BAF-1715/cmake-migration

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jiriskuta]

Review — CMake migration (cmlib → plain CMake + FetchContent)

Version-pin audit: all dependency pins are preserved (fleet-protocol-interface v2.1.0, fleet-protocol-cpp v1.2.0, async-function-execution v1.0.0, aeron 1.48.6, zlib v1.3.2, nlohmann-json fetch v3.12.0, fleet-http-client v2.0.2, boost 1.86.0, cpprestsdk v2.10.20). protobuf v3.21.12 is a newly-explicit dep, not a regression. Looks good with minor changes.

1. MEDIUM — hardcoded personal machine paths + stale task notes committed to CLAUDE.md

The new ## CURRENT TASK block hardcodes /home/martin/Code/kubernetes/... in four places (reference shims, debug-loop cd, follow-up paths). It also commits a transient per-task worklog into a permanent doc, and that table is already factually stale vs the shipped code: it lists fleet-protocol-cxx-helpers-static 1.1.1 and nlohmann_json 3.10.5, but the actual pins are v1.2.0 and fetch v3.12.0.
Fix: remove the task block from CLAUDE.md (keep it in the PR description / tracker). If build docs are wanted, add repo-relative, version-accurate instructions.

2. LOW/MEDIUM — FindBAZlib.cmake depends on another module having forced BUILD_SHARED_LIBS OFF

FindBAZlib.cmake aliases zlibstatic and its comment assumes BUILD_SHARED_LIBS is forced OFF, but this module never sets it — it relies on FindBAAsyncFunctionExecution.cmake (runs earlier, set(... CACHE BOOL "" FORCE)) having done so. Reordering Dependencies.cmake, or making the async fetch conditional, would silently flip zlib to a shared build and break the alias.
Fix: have FindBAZlib.cmake set BUILD_SHARED_LIBS OFF itself before its FetchContent_MakeAvailable, or branch on whichever of zlib/zlibstatic actually exists.

3. LOW — removed BRINGAUTO_SYSTEM_DEP / BRINGAUTO_GET_PACKAGES_ONLY makes resolution unconditional

SYSTEM_DEP=ON (skip Dependencies.cmake) is subsumed gracefully by system-first resolution — no regression. But GET_PACKAGES_ONLY=ON (early RETURN(), packager-only) is gone; any CI/deploy invocation still passing these flags now silently proceeds to a full build (CMake only warns "unused variable").
Fix: confirm no CI/deploy step still passes -DBRINGAUTO_SYSTEM_DEP=ON / -DBRINGAUTO_GET_PACKAGES_ONLY=ON; note the removal in the PR/changelog.

4. LOW — FindBAAeron.cmake include-dir wiring lacks a TARGET guard

target_include_directories(aeron_driver ...) / aeron_driver_static are called unconditionally, while the install loop just below guards each with if(TARGET ...). If upstream aeron omits either target under some options, configure hard-errors.
Fix: wrap each in if(TARGET ...).

---

🤖 Review generated with Claude Code