Ship the native collector static lib in the bundle (Option B: own adapter)

[lotgon]

tt-aggregator2 is pivoting to write its own native adapter against hsm::collector (rather than relink the wrapper), and they need the collector library. I confirmed against their repo that their native build is manual MSBuild vendoring (Bridge2022.sln / AggregationBridgeSvc.vcxproj, $(AggregatorInclude)/$(AggregatorLib)) — no vcpkg/Conan/NuGet — so a prebuilt lib in the handoff bundle is the fit (a C++ package manager doesn't apply to their build).

• Adds hsm_collector_core.lib (x64 Debug+Release) under lib/hsm_collector/x64/{cfg}/. The hsm_collector/ headers already ship in the bundle.
• pack.ps1 grabs the lib from the wrapper's collector subbuild (build/wrapper/hsm_collector/<cfg>/) — no workflow change (the wrapper build already produces it).
• MANIFEST now documents Option A (drop-in relink) vs Option B (native adapter: link hsm_collector_core.lib + Windows SDK iphlpapi.lib/pdh.lib + libcurl.lib; runtime libcurl.dll/z.dll already shipped).

Verified: a workflow_dispatch build off this branch produced a bundle containing lib/hsm_collector/x64/{Release,Debug}/hsm_collector_core.lib.

🤖 Generated with Claude Code

[github-actions]

PR #1220 Review — bundle native collector lib

Scope is small and focused: pack.ps1 now also collects hsm_collector_core.lib into the bundle so a consumer can link a pure-native adapter (MANIFEST "Option B"), plus the matching README/MANIFEST docs. I verified the new logic against src/wrapper/CMakeLists.txt and src/native/collector/CMakeLists.txt.

Verdict

No blocking bugs found. The change is correct and notably well-guarded. A few minor notes below, none blocking.

What's correct / verified

• Primary path matches the build layout. add_subdirectory(... ${CMAKE_BINARY_DIR}/hsm_collector) (wrapper CMake:25) makes the subproject binary dir build/wrapper/hsm_collector. hsm_collector_core is a STATIC target (collector CMake:103) with no OUTPUT_NAME/DEBUG_POSTFIX/*_OUTPUT_DIRECTORY override, so a VS multi-config generator emits build/wrapper/hsm_collector/<cfg>/hsm_collector_core.lib — exactly the $BuildDir\hsm_collector\$cfg\hsm_collector_core.lib primary probe. Release/Debug land in separate <cfg> folders, so there's no name collision when both are copied.
• The fallback is null-safe. Under Set-StrictMode -Version Latest, (… | Select-Object -First 1).FullName yields $null (not an error) when the search finds nothing, and the subsequent -not $collLib -or -not (Test-Path $collLib) short-circuits on -not $collLib so Test-Path $null is never evaluated. It then throws a clear, actionable message. Good defensive handling.
• The recursive fallback can't grab the wrong artifact. It filters on the exact filename hsm_collector_core.lib (only the collector target produces it; examples/tests produce other names) and requires \<cfg>\ in the path, so it won't cross-pollinate Release/Debug.
• Option B link list is accurate. The doc tells manual (non-CMake) consumers to link iphlpapi.lib + pdh.lib + libcurl.lib alongside the static lib. This matches the target's deps (iphlpapi PUBLIC, pdh PRIVATE, CURL::libcurl PRIVATE) — correctly, since a raw .lib doesn't carry CMake usage-requirement transitivity, the consumer must add all three itself. Threads::Threads is a no-op on Windows, so omitting it is right.

Minor observations (non-blocking)

1. Single-config generator layouts aren't supported by the fallback. With Ninja/Makefiles the lib would be at build/wrapper/hsm_collector/hsm_collector_core.lib (no <cfg> segment), which fails the -match "\\$cfg\\" filter and would throw. This is consistent with the rest of the script (the wrapper DLL probe at $BuildDir\$cfg\ and the documented --config Release/Debug workflow already assume a multi-config generator), so it's fine for intended usage — worth a one-line note in the script comment if single-config builds are ever expected.
2. libcurl.lib is documented but not bundled. Option B step 2 tells the consumer to source libcurl.lib from vcpkg "or ask us to bundle it," yet the pack ships libcurl.dll (the runtime) but no import lib for the native-adapter path. That's an intentional gap per the wording, but it means Option B isn't fully self-contained out of the box — consider bundling libcurl.lib (and pdh.lib/iphlpapi.lib are Windows SDK, so those are fine) to make Option B a true drop-in.
3. Doc nit (README/MANIFEST): the header comment describes hsm_collector/ as "Native() and the pure-native adapter." Since Native() is an Option-A (wrapper) escape hatch and the pure-native adapter is Option B, the two labels on one line read slightly ambiguously — minor.

Security / performance

• No security concerns: no new external input, network, or credential handling; paths are derived from build outputs and copied locally.
• No performance concerns: the recursive Get-ChildItem fallback only runs when the fast-path Test-Path misses, scoped to $BuildDir/hsm_collector.

Nice work — the failure modes (missing lib, empty search, absent subdir) are all handled with loud, specific errors rather than silently shipping an incomplete bundle.