From: Max Vilimpoc Date: Sat, 5 Sep 2026 22:48:57 +0000 (+0200) Subject: dotfiles: fix two architecture bugs a real ARM64 run exposed X-Git-Url: https://vilimpoc.org/repos/dotfiles/commitdiff_plain/fbe899b67d263a1ae5404d3ed25f5f091c3d2c1e?ds=sidebyside;hp=fbe899b67d263a1ae5404d3ed25f5f091c3d2c1e dotfiles: fix two architecture bugs a real ARM64 run exposed Running setup-windows.bat end to end on an ARM64 box turned up two packages that quietly did the wrong thing, and one bug in the audit that was hiding a third. WinMerge installed as x64 on ARM64. Upstream publishes the ARM64 build as a MACHINE-scope installer and the x64 build as a PER-USER one, so an unelevated winget lets its scope preference beat its architecture preference and silently picks the emulated x64. Ask for --architecture arm64 first and fall back to the default, so an administrator run gets the native build and a standard-user run still gets a working diff tool. LLVM does not fail when it cannot write to Program Files - it relocates. The NSIS installer falls back to a per-user directory (observed at %USERPROFILE%\Documents\LLVM) and winget still reports "Successfully installed", so the compiler is genuinely present, genuinely native, and findable by nothing. Its silent install also does not take the add-to-PATH option. New LlvmPath step looks in that fallback as well as the usual roots, reports the architecture, notes when the location means the install was not machine-wide, and appends the directory to the user PATH. Appended rather than prepended: this is a second compiler kept alongside MSVC and should not quietly win a clang-cl meant for Visual Studio's copy. The audit resolved labelled entries PATH-first, so with upstream LLVM on the PATH the "clang-cl.exe (VS)" row answered with the upstream compiler and reported Visual Studio's as present when it was absent. A labelled entry names one specific copy and is now resolved only from its explicit candidates; unlabelled entries still resolve PATH-first, because for those the question is which binary a build would actually invoke. Also record what a standard user cannot provision. The elevated half needs an account that can elevate, and several packages in the non-elevated section are per-user in name only: the .NET SDK (exit 5), CMake and Android GPU Inspector (MSI 1603) and OpenCppCoverage (self-elevating) all fail without an administrator. Verified on ARM64: cmake, ninja, git, python, ssh, xperf, MSBuild and cl.exe all native; both compilers build a native ARM64 binary through the Ninja generator - MSVC 1950 and clang 22.1.8, each reporting target ARM64. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Ak6VzfGyaocrykX1LhNMwt ---