*without* one is called out, with a remedy where a native build exists — which is
how the `ninja` problem below was found.
+### You need an administrator for the elevated half
+
+`setup-windows.bat` assumes whoever runs it **can elevate**. If the account is a
+standard user, the UAC prompt is an over-the-shoulder *credential* prompt rather
+than a Yes/No, and declining it leaves the elevated half unrun — no Visual Studio
+components (so no `clang-cl`), no WDK, no `rsync`, no `sshd`. The batch reports
+`ELEVATED SETUP FAILED` and prints no log, because none was written.
+
+The same applies to several packages in the *non-elevated* section, which are
+per-user only in name: the .NET SDK (`exit 5`), CMake and Android GPU Inspector
+(MSI `1603`), and OpenCppCoverage (its installer self-elevates) all fail for a
+standard user. Sign in to an administrator account to provision, or expect that
+subset to be missing.
+
+Two consequences worth knowing rather than rediscovering:
+
+- **LLVM does not fail — it relocates.** Its NSIS installer targets
+ `%ProgramFiles%\LLVM`, and when it cannot write there it silently falls back to
+ a per-user directory (observed: `%USERPROFILE%\Documents\LLVM`) while winget
+ still reports *Successfully installed*. The compiler is genuinely there and
+ native; nothing can find it. The `LlvmPath` step looks in that fallback, puts
+ the directory on the user `PATH`, and says so.
+- **WinMerge silently downgrades to x64.** Upstream publishes ARM64 as a
+ **machine-scope** installer and x64 as a **per-user** one, so an unelevated
+ winget lets its scope preference beat its architecture preference. The batch
+ now asks for `--architecture arm64` first and falls back, so an admin run gets
+ the native build and a standard-user run still gets a working one.
+
### Two gotchas the audit surfaces
- **Visual Studio bundles an x64 `ninja.exe` even on ARM64.** It matters more
# for several, dot-call the script or use -Command:
# .\setup-windows-no-uac.ps1 -Skip BinSkim,GitConfig
# powershell -File .\setup-windows-no-uac.ps1 -Skip BinSkim
- [ValidateSet('WinMerge', 'VsWhere', 'BinSkim', 'GitConfig', 'NinjaPath', 'ArchAudit')]
+ [ValidateSet('WinMerge', 'VsWhere', 'BinSkim', 'GitConfig', 'NinjaPath', 'LlvmPath', 'ArchAudit')]
[string[]] $Skip = @()
)
Add-ToUserPath (Split-Path $native -Parent) -Prepend
}
+function Add-LlvmToUserPath {
+ # Put the upstream LLVM's bin directory on the user PATH.
+ #
+ # Two reasons this needs a step rather than trusting the installer:
+ #
+ # 1. WHERE IT LANDS. LLVM's NSIS installer targets %ProgramFiles%\LLVM, and
+ # when it cannot write there - a standard user, no elevation - it does not
+ # fail. It silently falls back to a per-user directory, observed as
+ # %USERPROFILE%\Documents\LLVM, and winget still reports "Successfully
+ # installed". So the package is registered, the compiler is genuinely
+ # there and native, and nothing can find it.
+ # 2. PATH. The installer's "add to PATH" option is not taken in a silent
+ # install, so clang-cl is not a command afterwards either way.
+ #
+ # Appended, not prepended: this is a second compiler kept deliberately
+ # alongside MSVC, and it should not quietly win a `clang-cl` that some script
+ # meant for Visual Studio's copy. Note VS does NOT put its own
+ # VC\Tools\Llvm on the PATH (its clang-cl is reached through CMake's
+ # -T ClangCL), so there is no collision to lose here.
+ Write-Step 'Upstream LLVM on the user PATH'
+ $candidates = @(
+ (Join-Path $env:ProgramFiles 'LLVM\bin')
+ (Join-Path ${env:ProgramFiles(x86)} 'LLVM\bin')
+ (Join-Path $env:LOCALAPPDATA 'Programs\LLVM\bin')
+ (Join-Path ([Environment]::GetFolderPath('MyDocuments')) 'LLVM\bin')
+ (Join-Path $env:USERPROFILE 'Documents\LLVM\bin')
+ )
+ $dir = $candidates | Where-Object { Test-Path (Join-Path $_ 'clang-cl.exe') } | Select-Object -First 1
+ if (-not $dir) {
+ Write-Host ' Not installed (winget install LLVM.LLVM); Visual Studio''s own clang-cl is unaffected.' -ForegroundColor DarkGray
+ return
+ }
+ $exe = Join-Path $dir 'clang-cl.exe'
+ $mach = Get-PEMachine $exe
+ Write-Host " $exe ($mach)"
+ if ($IsArm64 -and $mach -ne 'ARM64') {
+ Write-Warning "This LLVM is $mach, not ARM64. winget install LLVM.LLVM should resolve to the -woa64 build on this host."
+ }
+ if ($dir -notmatch [regex]::Escape($env:ProgramFiles)) {
+ Write-Host ' Note: not under Program Files - the installer fell back to a per-user' -ForegroundColor Yellow
+ Write-Host ' location because it could not write there. Re-run elevated for a machine-wide install.' -ForegroundColor Yellow
+ }
+ Add-ToUserPath $dir
+}
+
function Get-PEMachine {
# Architecture of a PE, read straight from the COFF header: the 2 bytes at
# the e_lfanew offset + 4. Cheap, and it answers the only question that
# puts the native copy first; this is the check that it worked.
$Remedies = @{
'ninja.exe' = 'Visual Studio bundles an x64 ninja. Install the native one (winget install Ninja-build.Ninja) and re-run - the NinjaPath step puts its directory at the front of the user PATH.'
- 'cmake.exe' = 'Install the native build with: winget install Kitware.CMake'
- 'clang-cl.exe' = 'Install the upstream native LLVM with: winget install LLVM.LLVM'
+ 'cmake.exe' = 'Install the native build with: winget install Kitware.CMake (its MSI is machine-scope, so it needs an administrator).'
+ 'clang-cl.exe' = 'Install the upstream native LLVM with: winget install LLVM.LLVM'
+ 'WinMergeU.exe' = 'Upstream ships ARM64 as a MACHINE-scope installer and x64 as per-user, so an unelevated winget picks x64. Re-run as an administrator to get: winget install WinMerge.WinMerge --architecture arm64'
}
$vs = $null
'pwsh.exe' = @()
'cmake.exe' = @((Join-Path $env:ProgramFiles 'CMake\bin\cmake.exe'))
'ninja.exe' = @()
- 'clang-cl.exe' = @((Join-Path $env:ProgramFiles 'LLVM\bin\clang-cl.exe'))
+ # Upstream LLVM. The Documents path is not a typo - see Add-LlvmToUserPath
+ # for why an unelevated install lands there.
+ 'clang-cl.exe' = @(
+ (Join-Path $env:ProgramFiles 'LLVM\bin\clang-cl.exe')
+ (Join-Path $env:LOCALAPPDATA 'Programs\LLVM\bin\clang-cl.exe')
+ (Join-Path ([Environment]::GetFolderPath('MyDocuments')) 'LLVM\bin\clang-cl.exe')
+ )
'dotnet.exe' = @((Join-Path $env:ProgramFiles 'dotnet\dotnet.exe'))
'WinMergeU.exe' = @((Join-Path $env:ProgramFiles 'WinMerge\WinMergeU.exe'), (Join-Path ${env:ProgramFiles(x86)} 'WinMerge\WinMergeU.exe'))
'BinSkim.exe' = @((Join-Path $BinSkimDir 'BinSkim.exe'))
$native = if ($IsArm64) { 'ARM64' } else { 'x64' }
$unexpected = @()
foreach ($name in $targets.Keys) {
- # PATH first - that is the binary a build would actually invoke - then the
- # explicit candidates. The bare exe name is stripped of any " (label)".
- $exe = ($name -split ' ')[0]
- $path = Resolve-OnPath $exe
- if (-not $path) { $path = $targets[$name] | Where-Object { $_ -and (Test-Path $_) } | Select-Object -First 1 }
+ # A LABELLED entry - "clang-cl.exe (VS)" - names one specific copy, so it
+ # is resolved ONLY from its explicit candidates. Falling back to the PATH
+ # there would silently answer with a different installation of the same
+ # tool: with upstream LLVM on the PATH, the "(VS)" row reported the
+ # upstream compiler and so claimed Visual Studio's was present when it was
+ # not. Unlabelled entries still resolve PATH-first, because for those the
+ # question is which binary a build would actually invoke.
+ $exe = ($name -split ' ')[0]
+ $isPinned = $name -ne $exe
+ if ($isPinned) {
+ $path = $targets[$name] | Where-Object { $_ -and (Test-Path $_) } | Select-Object -First 1
+ } else {
+ $path = Resolve-OnPath $exe
+ if (-not $path) { $path = $targets[$name] | Where-Object { $_ -and (Test-Path $_) } | Select-Object -First 1 }
+ }
if (-not $path) { Write-Host (" {0,-22} {1}" -f $name, '- not installed') -ForegroundColor DarkGray; continue }
$mach = Get-PEMachine $path
BinSkim = { Install-BinSkim }
GitConfig = { Set-GlobalGitConfig }
NinjaPath = { Set-NativeNinjaFirst }
+ LlvmPath = { Add-LlvmToUserPath }
# Last on purpose: it reports on what the steps above (and the winget installs
# in setup-windows.bat) actually put on the box.
ArchAudit = { Invoke-ArchAudit }
winget install Microsoft.DotNet.SDK.10\r
winget install Microsoft.PowerShell Microsoft.Sysinternals.ProcessExplorer Microsoft.Sysinternals.ProcessMonitor Microsoft.Sysinternals.SDelete Microsoft.VisualStudioCode Microsoft.WindowsTerminal\r
winget install Python.Python.3.13\r
-winget install WinMerge.WinMerge\r
+\r
+@rem WinMerge is the one package here where winget's own preference order picks\r
+@rem the WRONG architecture, and it is worth knowing why: upstream publishes the\r
+@rem ARM64 build as a MACHINE-scope installer (WinMerge-<ver>-ARM64-Setup.exe) and\r
+@rem the x64 build as a PER-USER one (WinMerge-<ver>-x64-PerUser-Setup.exe). Run\r
+@rem unelevated, winget's scope preference beats its architecture preference and\r
+@rem you silently get the emulated x64 build.\r
+@rem\r
+@rem So ask for arm64 explicitly, and fall back to the default when that cannot be\r
+@rem installed - which is exactly the standard-user case, where the machine-scope\r
+@rem installer has nowhere to go. The fallback is the x64 build under emulation:\r
+@rem a diff tool is not a hot path, and a working WinMerge beats none. The\r
+@rem architecture audit at the end of setup-windows-no-uac.ps1 reports which one\r
+@rem you ended up with.\r
+if "%IS_ARM64%"=="1" (\r
+ winget install WinMerge.WinMerge --architecture arm64 || winget install WinMerge.WinMerge\r
+) else (\r
+ winget install WinMerge.WinMerge\r
+)\r
\r
@rem --- Build drivers, standalone and native ---\r
@rem\r
vilimpoc.org / repos / dotfiles / commitdiff