Build the Windows probe with a Visual Studio the runner actually has

[cb1kenobi]

⊙ Problem

Both windows-x64 targets failed in run 37891970381, in the behavioural probe:

-- Building for: NMake Makefiles
CMake Error at CMakeLists.txt:2 (project): Running 'nmake' '-?' failed with: no such file or directory
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage

The other eight targets passed, and the archive itself was correct on Windows. The counter-name check ran there for the first time and behaved exactly as designed:

'user_key_comparison_count' in lib/rocksdb.lib: 190; in lib/no-perf-context/rocksdb.lib: 177

Both libraries carry the name, because vcpkg compiles release objects with /Z7 and the identical PerfContextBase field reaches the archive as CodeView type info. Only the strict inequality separates them. A presence test would have failed all four Windows targets.

💡 Solution

The runner image is now windows-2025-vs2026. Two things were wrong, and only the pair fixes it.

The probe never named a generator, so the runner image chose our toolchain. CMake's Windows default search found no Visual Studio it could use and fell back to NMake Makefiles, which needs a developer prompt this step does not have.

The CMake on PATH was 3.31.10, not the image's 4.4.3. The build pins that version to match the pinned vcpkg 2026.06.24 baseline, and lukka/get-cmake prepends it. The Visual Studio 18 2026 generator arrived in CMake 4.2, so 3.31.10 had nothing to fall back to. Naming the generator alone would still have failed both jobs — only with a readable error. Verified against a CMake 3.31-shaped cmake --help: the lookup returns empty for VS major 18.

The build's pin is deliberate and stays. The probe only consumes the installed package, so it gets its own CMake on the Windows legs that actually run it.

🔧 Changes

File	What changed
.github/scripts/verify-prebuild-archive.sh	On a Windows shell, vswhere gives the installed VS major version and cmake --help gives that generator's name, so neither is hardcoded. Every lookup failure exits with its own message rather than falling through to a default that cannot build.
.github/workflows/build.yml	A probe-only CMake 4.4.3 on the two Windows legs with run_probe, after the build so the pinned 3.31.10 still builds the libraries. The two x64 entries also name -A x64 instead of inheriting the host architecture.
.github/DESIGN.md	Records why the generator and architecture are named and why the probe has its own CMake, so the next reader meets the constraint before the code.

❓ Your call: lukka/get-cmake@latest is a moving branch. Both uses now pin a89e43e2 (what latest resolves to today), including the pre-existing build-time install — leaving one mutable in a job holding GH_TOKEN would not remove the exposure. Behaviour is unchanged today. Say so and I will split that half out.

✅ Verification

Route: local runs on darwin-arm64 plus fixture tests for the Windows-only path, which cannot be reached on this machine.

• Full archive verification still passes unchanged: markers 1 vs 0, nm 59 vs 0, probe user_key_comparison_count 40,959 vs 0.
• Generator lookup against a Windows cmake --help fixture: VS major 18 → Visual Studio 18 2026, 17 → Visual Studio 17 2022, 19 → empty. Against a CMake 3.31-shaped fixture, 18 → empty, which is the evidence that the CMake bump is load-bearing.
• Version parsing handles 18.10.12217.157 and 17.7.34009.444, CRLF included.
• Forced-Windows on macOS exits 1 with no vswhere.exe at … instead of falling through to a default generator.
• The four Windows matrix entries were enumerated against the new condition: the two x64 legs install the probe CMake, both arm64 legs do not.
• shellcheck clean.

Not verified here: that the selected generator builds the probe on the runner, and that CMake 4.4.3 installs cleanly alongside the pinned 3.31.10. build.yml has no pull_request trigger, so a dispatch is the only proof — the same gap that let the previous two defects reach main.

_{🤖 Generated by Claude (Anthropic); posted via @cb1kenobi.}

Related PRs: #28 overlaps (repaired the same verification step; merged), #27 overlaps (added it; merged)
Complexity: medium

_{Review-Coverage: authored=claude; ran=cursor-composer,codex,gemini,cursor-muse; adjudicated=domain; declined=cursor-grok,cursor-kimi; rounds=3; full=2 @ 4229597}

_{Review-Attention: read ~3m (decisions: probe-generator-strategy, windows-vswhere-hard-requirement) @ 4229597}

[gemini-code-assist]

Code Review

This pull request updates the behavioral probe verification script on Windows to dynamically detect the installed Visual Studio version using vswhere and select the appropriate CMake generator, preventing build failures due to CMake falling back to NMake. The design documentation is also updated to reflect these changes. Feedback on the changes highlights a critical issue where the use of head -1 in a pipeline under pipefail can cause a SIGPIPE (exit code 141) and abort the script; a suggestion is provided to temporarily disable pipefail within the subshell to resolve this.