wyvrnpm 2.20.0 → 2.20.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wyvrnpm",
-  "version": "2.20.0",
+  "version": "2.20.2",
   "description": "A simple, static-hosting-compatible C++ package manager",
   "keywords": [
     "c++",

package/src/build/cmake-exe.js

@@ -0,0 +1,72 @@
+'use strict';
+
+const fs   = require('fs');
+const path = require('path');
+
+// Default CMake install location on Windows (the Kitware MSI default). When
+// CMake isn't on PATH — common in stripped CI agents or a fresh dev box where
+// the installer's "add to PATH" box was unchecked — fall back to this so
+// install/build/source-build still work instead of failing with "is CMake on
+// PATH?".
+const WINDOWS_DEFAULT_CMAKE = 'C:\\Program Files\\CMake\\bin\\cmake.exe';
+
+/**
+ * Decide which `cmake` command to spawn. Pure — all environment inputs are
+ * injected, so it's testable across platforms.
+ *
+ *   1. cmake found on PATH → `'cmake'` (let spawn / PATH resolve it; preserves
+ *      the pre-fix behaviour and respects a user's chosen cmake).
+ *   2. else, on Windows, the default install location exists → its absolute
+ *      path.
+ *   3. else → `'cmake'` so the caller's spawn fails with the normal
+ *      "is CMake installed and on PATH?" error rather than a confusing ENOENT
+ *      on a hard-coded path.
+ *
+ * @param {{ platform: string, pathValue: string|undefined,
+ *           exists: (p: string) => boolean }} args
+ * @returns {string}
+ */
+function pickCmakeExe({ platform, pathValue, exists }) {
+  const isWin   = platform === 'win32';
+  const pathLib = isWin ? path.win32 : path.posix;
+  const delim   = isWin ? ';' : ':';
+  // .bat/.cmd cover shim installs (e.g. via package managers); .exe is the
+  // stock installer.
+  const names = isWin ? ['cmake.exe', 'cmake.bat', 'cmake.cmd'] : ['cmake'];
+
+  for (const dir of (pathValue || '').split(delim).filter(Boolean)) {
+    for (const name of names) {
+      if (exists(pathLib.join(dir, name))) return 'cmake';
+    }
+  }
+
+  if (isWin && exists(WINDOWS_DEFAULT_CMAKE)) return WINDOWS_DEFAULT_CMAKE;
+  return 'cmake';
+}
+
+let cached; // undefined = unprobed; string = resolved command (per-process)
+
+/**
+ * Resolve the cmake executable to spawn, memoised per-process (PATH and the
+ * install location don't change mid-run). Returns either `'cmake'` (on PATH /
+ * give-up) or an absolute path to the Windows-default cmake.exe.
+ *
+ * @returns {string}
+ */
+function resolveCmakeExe() {
+  if (cached === undefined) {
+    cached = pickCmakeExe({
+      platform:  process.platform,
+      pathValue: process.env.PATH,
+      exists:    fs.existsSync,
+    });
+  }
+  return cached;
+}
+
+module.exports = {
+  resolveCmakeExe,
+  WINDOWS_DEFAULT_CMAKE,
+  // Exported for unit tests
+  pickCmakeExe,
+};

package/src/build/cmake.js

@@ -7,6 +7,7 @@ const { spawn } = require('child_process');
 const { loadMsvcEnv } = require('./msvc-env');
 const { archToVsPlatform, isVisualStudioGenerator } = require('../toolchain');
 const { detectDefaultGenerator } = require('./default-generator');
+const { resolveCmakeExe } = require('./cmake-exe');
 const log = require('../logger');
 
 /**
@@ -144,7 +145,7 @@ async function pickGenerator(candidates) {
  */
 function runCmake(args, opts = {}) {
   return new Promise((resolve, reject) => {
-    const proc = spawn('cmake', args, {
+    const proc = spawn(resolveCmakeExe(), args, {
       stdio: 'inherit',
       cwd:   opts.cwd,
       env:   opts.env || process.env,

package/src/build/default-generator.js

@@ -1,124 +1,129 @@
-'use strict';
-
-const { spawn } = require('child_process');
-
-const { isVisualStudioGenerator } = require('../toolchain');
-
-/**
- * Parse `cmake --help` output for the platform's default generator. CMake
- * marks the default with a leading `* ` in the "Generators" section, e.g.:
- *
- *   The following generators are available on this platform (* marks default):
- *   * Visual Studio 17 2022 [arch] = Generates Visual Studio 2022 project files.
- *     Visual Studio 16 2019 [arch] = Generates Visual Studio 2019 project files.
- *     Ninja                        = Generates build.ninja files.
- *
- * Returns the default generator's name verbatim (with any trailing ` [arch]`
- * annotation stripped), or null when no default marker is present. The name is
- * returned as-is — deciding whether it's a Visual Studio generator is the
- * caller's job.
- *
- * @param {string} helpText
- * @returns {string|null}
- */
-function parseDefaultGenerator(helpText) {
-  if (typeof helpText !== 'string') return null;
-  for (const line of helpText.split(/\r?\n/)) {
-    const m = line.match(/^\*\s+(.+?)\s*=/);
-    if (!m) continue;
-    return m[1].replace(/\s*\[arch\]\s*$/, '').trim();
-  }
-  return null;
-}
-
-/**
- * Spawn `cmake --help` and resolve its stdout. Resolves null (never rejects)
- * when cmake is absent from PATH or exits non-zero — generator detection is
- * best-effort, and an unavailable cmake simply means the caller falls back to
- * leaving the generator unpinned, exactly as before this feature.
- *
- * @returns {Promise<string|null>}
- */
-function runCmakeHelp() {
-  return new Promise((resolve) => {
-    let out = '';
-    const proc = spawn('cmake', ['--help'], {
-      shell: process.platform === 'win32',
-    });
-    proc.stdout.on('data', (chunk) => { out += chunk.toString(); });
-    // cmake not on PATH → detection unavailable; recoverable, fall back to null.
-    proc.on('error', () => resolve(null));
-    proc.on('close', (code) => resolve(code === 0 ? out : null));
-  });
-}
-
-// Per-process memo of the production (no-injection) probe result. The default
-// generator can't change mid-run, so a single `cmake --help` spawn is enough
-// for the whole process — important when one process drives many installs
-// (e.g. a source-build that resolves several deps, or the test suite). Calls
-// that inject `platform`/`runHelp` (tests) bypass this cache to stay hermetic.
-let cachedDefault; // undefined = unprobed; string|null = probed result
-
-/**
- * Detect the Visual Studio generator CMake would use by default on this
- * machine. On Windows with VS installed, CMake's implicit default is the
- * newest installed VS — which builds host x64 unless `-A`/architecture is
- * pinned. Returns that VS generator name so callers can pin it (and the
- * matching `-A`), or null when the default is not a VS generator
- * (non-Windows, or VS not installed → today's behaviour, no pin).
- *
- * `platform` and `runHelp` are injectable for tests; the defaults probe the
- * real machine and memoise the result per-process.
- *
- * @param {{ platform?: string, runHelp?: () => Promise<string|null> }} [opts]
- * @returns {Promise<string|null>}
- */
-async function detectDefaultGenerator({ platform, runHelp } = {}) {
-  const injected = platform !== undefined || runHelp !== undefined;
-  if (!injected && cachedDefault !== undefined) return cachedDefault;
-
-  const plat = platform ?? process.platform;
-  let result = null;
-  if (plat === 'win32') {
-    const helpText = await (runHelp ?? runCmakeHelp)();
-    const name = helpText ? parseDefaultGenerator(helpText) : null;
-    // Only VS generators need an arch pin; everything else (Ninja, NMake, …)
-    // already honours the active vcvarsall env for target arch.
-    result = isVisualStudioGenerator(name) ? name : null;
-  }
-
-  if (!injected) cachedDefault = result;
-  return result;
-}
-
-/**
- * Resolve the generator a CMake invocation will actually use, given an
- * optional explicit choice (CLI `--generator` or a recipe `build.generator`)
- * and the active profile.
- *
- *   - An explicit non-empty generator always wins, verbatim.
- *   - Otherwise, on a Windows/MSVC profile, fall back to the detected default
- *     VS generator so callers can pin `-A`/architecture against it.
- *   - Otherwise null — the caller leaves the generator unpinned (CMake picks
- *     its default), exactly as before this feature. On non-Windows toolchains
- *     target arch is the compiler's job, not the generator's.
- *
- * @param {{ explicit?: string|null,
- *           profile?: { os?: string, compiler?: string }|null,
- *           detect?: () => Promise<string|null> }} [args]
- * @returns {Promise<string|null>}
- */
-async function resolveEffectiveGenerator({ explicit = null, profile = null, detect = detectDefaultGenerator } = {}) {
-  if (typeof explicit === 'string' && explicit.trim()) return explicit;
-  if (profile && profile.os === 'Windows' && profile.compiler === 'msvc') {
-    return detect();
-  }
-  return null;
-}
-
-module.exports = {
-  resolveEffectiveGenerator,
-  detectDefaultGenerator,
-  // Exported for unit tests
-  parseDefaultGenerator,
-};
+'use strict';
+
+const { spawn } = require('child_process');
+
+const { isVisualStudioGenerator } = require('../toolchain');
+const { resolveCmakeExe } = require('./cmake-exe');
+
+/**
+ * Parse `cmake --help` output for the platform's default generator. CMake
+ * marks the default with a leading `* ` in the "Generators" section, e.g.:
+ *
+ *   The following generators are available on this platform (* marks default):
+ *   * Visual Studio 17 2022 [arch] = Generates Visual Studio 2022 project files.
+ *     Visual Studio 16 2019 [arch] = Generates Visual Studio 2019 project files.
+ *     Ninja                        = Generates build.ninja files.
+ *
+ * Returns the default generator's name verbatim (with any trailing ` [arch]`
+ * annotation stripped), or null when no default marker is present. The name is
+ * returned as-is — deciding whether it's a Visual Studio generator is the
+ * caller's job.
+ *
+ * @param {string} helpText
+ * @returns {string|null}
+ */
+function parseDefaultGenerator(helpText) {
+  if (typeof helpText !== 'string') return null;
+  for (const line of helpText.split(/\r?\n/)) {
+    const m = line.match(/^\*\s+(.+?)\s*=/);
+    if (!m) continue;
+    return m[1].replace(/\s*\[arch\]\s*$/, '').trim();
+  }
+  return null;
+}
+
+/**
+ * Spawn `cmake --help` and resolve its stdout. Resolves null (never rejects)
+ * when cmake is absent from PATH or exits non-zero — generator detection is
+ * best-effort, and an unavailable cmake simply means the caller falls back to
+ * leaving the generator unpinned, exactly as before this feature.
+ *
+ * @returns {Promise<string|null>}
+ */
+function runCmakeHelp() {
+  return new Promise((resolve) => {
+    let out = '';
+    const cmakeExe = resolveCmakeExe();
+    // shell:true (Windows) lets a bare `cmake` resolve .bat/.cmd shims on PATH.
+    // But a resolved absolute fallback path contains spaces ("Program Files"),
+    // which a shell would word-split — spawn it directly without a shell.
+    const proc = spawn(cmakeExe, ['--help'], {
+      shell: process.platform === 'win32' && cmakeExe === 'cmake',
+    });
+    proc.stdout.on('data', (chunk) => { out += chunk.toString(); });
+    // cmake not on PATH → detection unavailable; recoverable, fall back to null.
+    proc.on('error', () => resolve(null));
+    proc.on('close', (code) => resolve(code === 0 ? out : null));
+  });
+}
+
+// Per-process memo of the production (no-injection) probe result. The default
+// generator can't change mid-run, so a single `cmake --help` spawn is enough
+// for the whole process — important when one process drives many installs
+// (e.g. a source-build that resolves several deps, or the test suite). Calls
+// that inject `platform`/`runHelp` (tests) bypass this cache to stay hermetic.
+let cachedDefault; // undefined = unprobed; string|null = probed result
+
+/**
+ * Detect the Visual Studio generator CMake would use by default on this
+ * machine. On Windows with VS installed, CMake's implicit default is the
+ * newest installed VS — which builds host x64 unless `-A`/architecture is
+ * pinned. Returns that VS generator name so callers can pin it (and the
+ * matching `-A`), or null when the default is not a VS generator
+ * (non-Windows, or VS not installed → today's behaviour, no pin).
+ *
+ * `platform` and `runHelp` are injectable for tests; the defaults probe the
+ * real machine and memoise the result per-process.
+ *
+ * @param {{ platform?: string, runHelp?: () => Promise<string|null> }} [opts]
+ * @returns {Promise<string|null>}
+ */
+async function detectDefaultGenerator({ platform, runHelp } = {}) {
+  const injected = platform !== undefined || runHelp !== undefined;
+  if (!injected && cachedDefault !== undefined) return cachedDefault;
+
+  const plat = platform ?? process.platform;
+  let result = null;
+  if (plat === 'win32') {
+    const helpText = await (runHelp ?? runCmakeHelp)();
+    const name = helpText ? parseDefaultGenerator(helpText) : null;
+    // Only VS generators need an arch pin; everything else (Ninja, NMake, …)
+    // already honours the active vcvarsall env for target arch.
+    result = isVisualStudioGenerator(name) ? name : null;
+  }
+
+  if (!injected) cachedDefault = result;
+  return result;
+}
+
+/**
+ * Resolve the generator a CMake invocation will actually use, given an
+ * optional explicit choice (CLI `--generator` or a recipe `build.generator`)
+ * and the active profile.
+ *
+ *   - An explicit non-empty generator always wins, verbatim.
+ *   - Otherwise, on a Windows/MSVC profile, fall back to the detected default
+ *     VS generator so callers can pin `-A`/architecture against it.
+ *   - Otherwise null — the caller leaves the generator unpinned (CMake picks
+ *     its default), exactly as before this feature. On non-Windows toolchains
+ *     target arch is the compiler's job, not the generator's.
+ *
+ * @param {{ explicit?: string|null,
+ *           profile?: { os?: string, compiler?: string }|null,
+ *           detect?: () => Promise<string|null> }} [args]
+ * @returns {Promise<string|null>}
+ */
+async function resolveEffectiveGenerator({ explicit = null, profile = null, detect = detectDefaultGenerator } = {}) {
+  if (typeof explicit === 'string' && explicit.trim()) return explicit;
+  if (profile && profile.os === 'Windows' && profile.compiler === 'msvc') {
+    return detect();
+  }
+  return null;
+}
+
+module.exports = {
+  resolveEffectiveGenerator,
+  detectDefaultGenerator,
+  // Exported for unit tests
+  parseDefaultGenerator,
+};

package/src/commands/build.js

@@ -7,7 +7,9 @@ const { spawn } = require('child_process');
 const { normalizeRecipe, hasBuildRecipe, VALID_CMAKE_CONFIGS, DEFAULT_RECIPE } = require('../build/recipe');
 const { loadMsvcEnv }  = require('../build/msvc-env');
 const { archToVsPlatform, isVisualStudioGenerator } = require('../toolchain');
+const { readConfigurePresetGenerator } = require('../toolchain/presets');
 const { resolveEffectiveGenerator } = require('../build/default-generator');
+const { resolveCmakeExe } = require('../build/cmake-exe');
 const { LOCAL_OVERLAY_FILENAME, readLocalOverlay } = require('../conf');
 const { resolveBinaryDirRoot, DEFAULT_BINARY_DIR_ROOT } = require('../binary-dir');
 const { buildContext } = require('../context');
@@ -225,6 +227,54 @@ function buildInstallArgs({ binaryDir, config, prefix }) {
   return args;
 }
 
+/**
+ * Resolve the generator `cmake --preset <presetName>` will actually use, so
+ * the caller can decide generator-dependent flags (the Visual Studio `-A`
+ * arch pin, and whether to activate vcvarsall) against reality.
+ *
+ * Precedence — each step mirrors what CMake itself does:
+ *   1. CLI `--generator` — `build` passes it as `-G`, which overrides the
+ *      preset, so it wins here too.
+ *   2. The generator baked into the configure preset by `install`. This file,
+ *      not the project's recipe, is the contract `cmake --preset` consumes;
+ *      the recipe and the emitted preset can legitimately diverge (an
+ *      install-time `--generator`, or a recipe edited after the last install).
+ *      Trusting a re-derived recipe value is exactly the bug this guards
+ *      against — it pins `-A` against a non-VS preset (a hard CMake error) and
+ *      wrongly skips vcvarsall.
+ *   3. The detected default (Windows/MSVC → newest VS) for a generator-less
+ *      preset — emitted by a pre-arch-pin client, or any non-Windows
+ *      toolchain. Keeps the recipe-less arch pin firing. See
+ *      claude/PLAN-VS-ARCH-PIN.md.
+ *
+ * `readPresetGenerator` and `detect` are injectable for hermetic tests.
+ *
+ * @param {{
+ *   rootDir:    string,
+ *   presetName: string,
+ *   cliGenerator?: string|null,
+ *   profile?:   { os?: string, compiler?: string, arch?: string }|null,
+ *   readPresetGenerator?: (args: { projectRoot: string, presetName: string }) => string|null,
+ *   detect?:    () => Promise<string|null>,
+ * }} args
+ * @returns {Promise<string|null>}
+ */
+async function resolveConfigureGenerator({
+  rootDir,
+  presetName,
+  cliGenerator = null,
+  profile = null,
+  readPresetGenerator = readConfigurePresetGenerator,
+  detect,
+}) {
+  if (typeof cliGenerator === 'string' && cliGenerator.trim()) return cliGenerator;
+
+  const fromPreset = readPresetGenerator({ projectRoot: rootDir, presetName });
+  if (fromPreset) return fromPreset;
+
+  return resolveEffectiveGenerator({ explicit: null, profile, detect });
+}
+
 // ---------------------------------------------------------------------------
 // Spawn wrapper
 // ---------------------------------------------------------------------------
@@ -244,7 +294,7 @@ function runCmake(args, env = null) {
   return new Promise((resolve, reject) => {
     const opts = { stdio: 'inherit' };
     if (env) opts.env = env;
-    const proc = spawn('cmake', args, opts);
+    const proc = spawn(resolveCmakeExe(), args, opts);
     proc.on('error', (err) => {
       reject(new Error(
         `Failed to spawn cmake: ${err.message}\n` +
@@ -369,32 +419,20 @@ async function build(argv) {
   //
   // Same mechanism the source-build path already uses (src/build/msvc-env.js).
   let cmakeEnv = null;
-  let effectiveGenerator = argv.generator ?? null;
-  let effectiveProfile   = null;
+  const effectiveProfile = activeProfile;
+  let effectiveGenerator = null;
   try {
-    effectiveProfile = activeProfile;
-    // Which generator will the preset actually use? Read it from the
-    // project's own recipe if one exists. If not, default to null and let
-    // cmake/CMakePresets decide — in which case MSVC env activation is
-    // skipped (because VS is usually the default on Windows).
-    const manifest = ctx.manifest;
-    let presetGenerator = null;
-    if (hasBuildRecipe(manifest)) {
-      try {
-        const recipe = normalizeRecipe(manifest.build, null);
-        if (recipe.generators.length > 0) [presetGenerator] = recipe.generators;
-      } catch { /* templates need options → skip env activation */ }
-    }
-    // CLI --generator wins, then the recipe's generator, then — on a
-    // Windows/MSVC profile with neither — CMake's detected default VS
-    // generator. Resolving the default here keeps the `-A` pin below and the
-    // vcvarsall-skip decision consistent with the generator `cmake --preset`
-    // will actually use (install pins the same generator into the preset).
-    // Non-Windows / non-MSVC → null, unchanged from before.
-    // See claude/PLAN-VS-ARCH-PIN.md.
-    effectiveGenerator = await resolveEffectiveGenerator({
-      explicit: effectiveGenerator ?? presetGenerator,
-      profile:  activeProfile,
+    // The generator `cmake --preset` will actually use is the one baked into
+    // the configure preset by `install` (a CLI --generator overrides it). That
+    // value — not the project's recipe — drives both the `-A` pin below and the
+    // vcvarsall-skip decision, so they stay consistent with reality even when
+    // the recipe and the emitted preset disagree. See resolveConfigureGenerator
+    // and claude/PLAN-VS-ARCH-PIN.md.
+    effectiveGenerator = await resolveConfigureGenerator({
+      rootDir,
+      presetName,
+      cliGenerator: argv.generator,
+      profile:      activeProfile,
     });
     cmakeEnv = await loadMsvcEnv({
       profile:          activeProfile,
@@ -485,6 +523,7 @@ module.exports._helpers = {
   resolvePresetName,
   resolveBinaryDir,
   resolveConfigList,
+  resolveConfigureGenerator,
   buildConfigureArgs,
   buildBuildArgs,
   buildInstallArgs,

package/src/context.js

@@ -7,7 +7,7 @@
  * re-read config, re-resolve auth, and each toggle JSON mode on the logger.
  * The divergence was cheap at 11 commands; it starts costing real bugs
  * once F3 (`tool_requires`) and F4 (build/host profile split) double the
- * flag surface. See [claude/PLAN-COMMAND-CONTEXT.md](../claude/PLAN-COMMAND-CONTEXT.md).
+ * flag surface. See [.claude-wyvrn-local/plans/2026-04-23-command-context.md](../.claude-wyvrn-local/plans/2026-04-23-command-context.md).
  *
  * `buildContext(argv)` runs once at the top of each command. It:
  *   - resolves filesystem anchors (rootDir, manifestPath)

package/src/toolchain/presets.js

@@ -388,6 +388,36 @@ function generateCMakePresets({
   return { path: null, action: 'skipped', isUser: false };
 }
 
+/**
+ * Read the `generator` of a named configure preset from the project's
+ * CMakePresets.json (falling back to CMakeUserPresets.json). This is the
+ * generator `cmake --preset <name>` will actually use, so callers deciding
+ * generator-dependent flags — the Visual Studio `-A` arch pin, or whether to
+ * activate vcvarsall — must trust it over a value re-derived from the recipe.
+ * The recipe and the emitted preset can legitimately diverge (an install-time
+ * `--generator`, or a recipe edited after the last install); trusting the
+ * recipe pins `-A` against a Ninja preset, which CMake rejects with a hard
+ * "does not support platform specification" error.
+ *
+ * Returns the generator string, or null when the file/preset is absent or the
+ * preset declares no generator — the latter means CMake will fall back to its
+ * platform default, which the caller's detection path handles.
+ *
+ * @param {{ projectRoot: string, presetName: string }} args
+ * @returns {string|null}
+ */
+function readConfigurePresetGenerator({ projectRoot, presetName }) {
+  for (const file of ['CMakePresets.json', 'CMakeUserPresets.json']) {
+    const parsed  = safeReadJson(path.join(projectRoot, file));
+    const presets = parsed && Array.isArray(parsed.configurePresets) ? parsed.configurePresets : [];
+    const match   = presets.find((p) => p && p.name === presetName);
+    if (match && typeof match.generator === 'string' && match.generator.trim()) {
+      return match.generator;
+    }
+  }
+  return null;
+}
+
 /**
  * Strip every wyvrnpm-generated entry from a parsed presets object.
  * Mirror of `mergeIntoExisting` — used by `wyvrnpm clean --all` to
@@ -475,6 +505,7 @@ function stripWyvrnPresets(existing) {
 
 module.exports = {
   generateCMakePresets,
+  readConfigurePresetGenerator,
   stripWyvrnPresets,
   safeReadJson,
   // Exported for tests