]> vilimpoc.org git repositories - dotfiles/commit - setup-windows.bat
dotfiles: pin the native ninja ahead of the one VS bundles
authorMax Vilimpoc <max@vilimpoc.org>
Sat, 5 Sep 2026 22:27:05 +0000 (00:27 +0200)
committerMax Vilimpoc <max@vilimpoc.org>
Sat, 5 Sep 2026 22:27:05 +0000 (00:27 +0200)
commit3e0aa9fcdd4d04bd4d0714668af9af5fd200cb42
tree7414d72c72f71b18c64e09899e699b53d013a59b
parent649b04df2966260f38a18d5225a68bd4e0896b95
dotfiles: pin the native ninja ahead of the one VS bundles

Visual Studio ships an x64 ninja.exe even on ARM64. That matters more
than a one-off emulated tool would, because ninja is re-invoked for every
edge in the build graph - it is the one place emulation is paid over and
over rather than once.

New NinjaPath step finds a native ninja (winget's package directory, or
one already on the PATH that is not the VS copy), checks its PE machine
type actually matches the host, and moves its directory to the FRONT of
the user PATH. Add-ToUserPath grew a -Prepend switch for it, which also
moves an entry already present further down; appending stays the default.

Corrects the previous commit, which claimed VsDevCmd prepends the VS
directories and that the emulated ninja therefore always won inside a
Developer Command Prompt. It does not. VS adds them from
Common7\Tools\vsdevcmd\ext\cmake.bat with

    set "PATH=%PATH%;...\CMake\bin;...\CMake\Ninja"

which APPENDS, so they land at the very end of the composed PATH, behind
every machine and user entry - a native ninja anywhere on the user PATH
already beat it. Measured on an ARM64 box: the winget copy wins in a
fresh VsDevCmd session either way. This step is therefore insurance, not
the load-bearing fix: winget also appends its package directory, so
without it the margin rested on two append orders staying as they are,
one of them in a file Microsoft owns and revises.

The architecture audit now resolves against the PATH a NEW shell would
get - machine + user from the registry, then anything extra this process
carries (where a Developer prompt's VS directories live, kept last to
mirror how VsDevCmd appends them). Auditing $env:PATH reported state from
before the script ran, so it warned about a problem it had just fixed.

Verified end to end on ARM64: ninja resolves to the winget ARM64 build in
a fresh VsDevCmd session, CMake records it as CMAKE_MAKE_PROGRAM, and
`cmake -G Ninja` builds an ARM64 binary through the native ARM64 MSVC.
The audit now ends "Everything resolved to a native build, or to a listed
exception."

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ak6VzfGyaocrykX1LhNMwt
README.md
setup-windows-no-uac.ps1
setup-windows.bat