Background
PR #2641 added zlib as a runtime dependency for raw-deflate decompression of the `.ssdr_cfg` ZIP packages. The implementation uses:
- Linux/macOS: `find_package(ZLIB REQUIRED)` — links to the system zlib (libz/zlib1.dylib). Universally available.
- Windows: vcpkg install `zlib:x64-windows` in CI (`.github/workflows/ci.yml`, `.github/workflows/windows-installer.yml`), then copy `zlib*.dll` to the deploy directory.
The constitution's Technology Constraints section says:
Third-party: vendor under `third_party/` with `THIRD_PARTY_LICENSES` updated. Prefer bundled libraries over package-manager dependencies for portability (see libmosquitto bundling for MQTT, #699).
So the vcpkg dependency on Windows is a deviation from project convention. The libmosquitto precedent (#699) bundles a full TLS-capable MQTT stack rather than relying on package managers; that same posture would apply here.
Trade-offs
Pros of bundling:
- Aligns with the constitution's Technology Constraint.
- Single source-of-truth zlib version across all platforms (Linux, macOS, Windows).
- No vcpkg cache miss → no Windows CI slow-down on cold caches.
- Self-contained Windows installer artifact (no zlib1.dll dependency).
Pros of staying with the current approach:
- zlib is small, ubiquitous, and ABI-stable. On Linux/macOS the system zlib has been the reliable pattern for decades.
- vcpkg keeps Windows builds simple and matches Microsoft's recommended workflow.
- Bundling zlib means owning the security-patch cadence for it (low risk in practice but non-zero).
Suggested approach
Add `third_party/zlib/` (vendor zlib 1.3.1 minor source tree) with a CMake `add_subdirectory(third_party/zlib EXCLUDE_FROM_ALL)` block, then `target_link_libraries(AetherSDR PRIVATE zlibstatic)`. Keeps Linux/macOS on the system zlib if it's available, falls back to bundled otherwise. Or just always-bundle for parity with libmosquitto.
Then revert the vcpkg block in the two CI workflows.
Scope and risk
- Mechanical CMake + workflow change.
- ~50 LOC plus the zlib source tree (~600 KB).
- THIRD_PARTY_LICENSES update.
- AetherClaude-eligible if the constitution citation makes the decision clear.
Context
Surfaced during review of #2641. Defensible deviation given zlib's near-system status, but worth tracking explicitly.
73, Jeremy KK7GWY & Claude (AI dev partner)
Background
PR #2641 added zlib as a runtime dependency for raw-deflate decompression of the `.ssdr_cfg` ZIP packages. The implementation uses:
The constitution's Technology Constraints section says:
So the vcpkg dependency on Windows is a deviation from project convention. The libmosquitto precedent (#699) bundles a full TLS-capable MQTT stack rather than relying on package managers; that same posture would apply here.
Trade-offs
Pros of bundling:
Pros of staying with the current approach:
Suggested approach
Add `third_party/zlib/` (vendor zlib 1.3.1 minor source tree) with a CMake `add_subdirectory(third_party/zlib EXCLUDE_FROM_ALL)` block, then `target_link_libraries(AetherSDR PRIVATE zlibstatic)`. Keeps Linux/macOS on the system zlib if it's available, falls back to bundled otherwise. Or just always-bundle for parity with libmosquitto.
Then revert the vcpkg block in the two CI workflows.
Scope and risk
Context
Surfaced during review of #2641. Defensible deviation given zlib's near-system status, but worth tracking explicitly.
73, Jeremy KK7GWY & Claude (AI dev partner)