What this installs / configures:
- WinMerge on the user PATH
+ - vswhere.exe on the user PATH: the Visual Studio installer puts it in
+ %ProgramFiles(x86)%\Microsoft Visual Studio\Installer, which nothing adds
+ to the PATH, so build scripts (and VsDevCmd.bat itself) complain that
+ 'vswhere.exe' is not recognized
- BinSkim (binary hardening analyzer) in %LOCALAPPDATA%\Programs\BinSkim,
- on the user PATH
+ on the user PATH. The package has no win-arm64 build, so on ARM64 this is
+ the x64 tool under emulation - which analyses ARM64 binaries fine, since it
+ only reads their headers.
- Global git identity, and core.sshCommand pointed at a Win32-OpenSSH
client so git shares the Windows ssh-agent: the fast ssh.exe the elevated
half unpacks beside rsync.exe if it is there, the in-box one otherwise
+ - An architecture audit: the real PE machine type of every tool this box
+ provisions, resolved the way a shell would. Informational, never fatal.
+ Anything running emulated without a listed reason is called out.
FILL IN $GitUserName / $GitUserEmail below before the first run.
# 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', 'BinSkim', 'GitConfig')]
+ [ValidateSet('WinMerge', 'VsWhere', 'BinSkim', 'GitConfig', 'NinjaPath', 'LlvmPath', 'ArchAudit')]
[string[]] $Skip = @()
)
$ErrorActionPreference = 'Stop'
+# Host architecture. RuntimeInformation rather than PROCESSOR_ARCHITECTURE: an
+# emulated PowerShell reports the emulated architecture in the environment
+# variable while this API reports the real one. Values: X64, Arm64, X86.
+$HostArch = [Runtime.InteropServices.RuntimeInformation]::OSArchitecture.ToString()
+$IsArm64 = ($HostArch -eq 'Arm64')
+
# --- Global git identity: FILL THESE IN BEFORE RUNNING ---
# Left empty, Set-GlobalGitConfig skips the identity and says so, rather than
# stamping a placeholder onto your commits. Leaving them empty is a legitimate
Write-Host "`n==> $Msg" -ForegroundColor Cyan
}
-function Add-ToUserPath([string]$Dir) {
+function Add-ToUserPath {
# HKCU PATH, not the process PATH: this must outlive the script. Idempotent,
# and re-applied on every run so an entry lost to an unrelated PATH edit is
# repaired without re-doing the install that put it there.
+ #
+ # -Prepend puts the directory FIRST and moves it there if it is already
+ # present further down, which is the difference between "on the PATH" and
+ # "the one that wins". Only for entries where that matters; appending is the
+ # polite default and stays the default.
+ param(
+ [string] $Dir,
+ [switch] $Prepend
+ )
$user = [Environment]::GetEnvironmentVariable('Path', 'User')
if (-not $user) { $user = '' }
- if (($user -split ';') -contains $Dir) {
- Write-Host " $Dir already in user PATH."
+ # Compare trailing-backslash-insensitively: C:\x and C:\x\ are the same
+ # directory, and adding a second spelling of one is just noise.
+ $norm = { param($s) $s.Trim().TrimEnd('\') }
+ $entries = @($user -split ';' | Where-Object { $_.Trim() })
+ $already = $entries | Where-Object { (& $norm $_) -eq (& $norm $Dir) }
+
+ if (-not $Prepend) {
+ if ($already) { Write-Host " $Dir already in user PATH."; return }
+ $new = if ($user.Trim()) { $user.TrimEnd(';') + ';' + $Dir } else { $Dir }
+ [Environment]::SetEnvironmentVariable('Path', $new, 'User')
+ Write-Host " Added $Dir to user PATH (restart your shell to pick it up)."
+ return
+ }
+
+ if ($already -and (& $norm $entries[0]) -eq (& $norm $Dir)) {
+ Write-Host " $Dir already first in user PATH."
return
}
- $new = if ($user.Trim()) { $user.TrimEnd(';') + ';' + $Dir } else { $Dir }
- [Environment]::SetEnvironmentVariable('Path', $new, 'User')
- Write-Host " Added $Dir to user PATH (restart your shell to pick it up)."
+ $rest = $entries | Where-Object { (& $norm $_) -ne (& $norm $Dir) }
+ [Environment]::SetEnvironmentVariable('Path', (@($Dir) + $rest) -join ';', 'User')
+ if ($already) {
+ Write-Host " Moved $Dir to the front of the user PATH (restart your shell to pick it up)."
+ } else {
+ Write-Host " Added $Dir to the front of the user PATH (restart your shell to pick it up)."
+ }
}
function Add-WinMergeToUserPath {
Add-ToUserPath $dir
}
+function Add-VsWhereToUserPath {
+ # vswhere.exe is how scripts locate Visual Studio (MSBuild, VsDevCmd.bat,
+ # the Windows SDK), and the VS installer drops it in a fixed directory that
+ # is never on the PATH. VsDevCmd.bat itself prints "'vswhere.exe' is not
+ # recognized" on every run without it. The directory is fixed by contract
+ # (32-bit Program Files, no version in the path), so there is nothing to
+ # search for: if it is missing, Visual Studio is not installed.
+ Write-Step 'vswhere on the user PATH'
+ $dir = Join-Path ${env:ProgramFiles(x86)} 'Microsoft Visual Studio\Installer'
+ if (-not (Test-Path (Join-Path $dir 'vswhere.exe'))) {
+ Write-Warning "vswhere.exe not found in $dir (no Visual Studio installer present); user PATH unchanged."
+ return
+ }
+ Add-ToUserPath $dir
+}
+
function Install-BinSkim {
# BinSkim checks the exact mitigations the native project enables in
# CMakeLists.txt (CFG/XFG, CET, ASLR/HighEntropyVA, DEP, /GS, stack cookies,
- # DEPENDENTLOADFLAG, ...). The NuGet package ships a self-contained win-x64
- # build, so this needs no .NET SDK/runtime: the .nupkg is a zip - extract the
- # win-x64 tool folder and put it on the PATH. After restarting the shell:
+ # DEPENDENTLOADFLAG, ...). The NuGet package ships a self-contained build, so
+ # this needs no .NET SDK/runtime: the .nupkg is a zip - extract the tool
+ # folder for this architecture and put it on the PATH. After restarting the
+ # shell:
# binskim analyze path\to\your.exe
#
+ # ARCHITECTURE. The package currently publishes win-x64 only (its other RIDs
+ # are linux-x64, linux-arm64 and osx-x64) - there is no win-arm64 build. So on
+ # ARM64 this installs the x64 tool and it runs under emulation. That is a
+ # slowdown and nothing more: BinSkim READS PE headers and load configs, so the
+ # architecture of the binaries it analyses is independent of its own - an
+ # emulated x64 BinSkim checks ARM64 binaries perfectly well. $BinSkimRids is
+ # ordered preference, so if a win-arm64 build ever ships, an ARM64 box picks
+ # it up with no further change here.
+ #
# VERSION CHECK FIRST. The .nupkg is a large download (well over 100 MB), so
# ask NuGet what the newest stable version is BEFORE fetching anything, and
# skip the download entirely when the installed copy already matches.
-Uri "https://api.nuget.org/v3-flatcontainer/$BinSkimPackage/$latest/$BinSkimPackage.$latest.nupkg"
Expand-Archive -Path $zip -DestinationPath $tmp -Force
- $src = Get-ChildItem -Path $tmp -Recurse -Filter 'BinSkim.exe' |
- Where-Object { $_.FullName -match 'win-x64' } |
- Sort-Object FullName | Select-Object -Last 1
- if (-not $src) { throw 'BinSkim.exe (win-x64) not found in package.' }
+ # Native RID first, emulatable one second. Matched against the path
+ # so the newest matching tools\<tfm>\<rid>\ folder wins, as before.
+ $BinSkimRids = if ($IsArm64) { @('win-arm64', 'win-x64') } else { @('win-x64') }
+ $src = $null
+ $allExes = Get-ChildItem -Path $tmp -Recurse -Filter 'BinSkim.exe'
+ foreach ($rid in $BinSkimRids) {
+ $src = $allExes | Where-Object { $_.FullName -match [regex]::Escape($rid) } |
+ Sort-Object FullName | Select-Object -Last 1
+ if ($src) {
+ if ($rid -ne $BinSkimRids[0]) {
+ Write-Host " No $($BinSkimRids[0]) build in the package; using $rid (runs under emulation)." -ForegroundColor Yellow
+ }
+ break
+ }
+ }
+ if (-not $src) { throw "BinSkim.exe ($($BinSkimRids -join ' / ')) not found in package." }
# Replace wholesale rather than merging over the old tree, so files
# dropped between releases don't linger.
# in-box client stays the fallback - and on a first provisioning run from
# setup-windows.bat it is the elevated half that runs first, so the fast one
# is normally already there.
+ #
+ # ON ARM64 the preference is the same but the trade is different: that build
+ # is published for x64 only, so it is the EMULATED client being preferred over
+ # a native ARM64 one. It is still the right pick when it runs - a push is
+ # bounded by the socket, not by emulated CPU, so lifting the 3KB stdin cap
+ # wins by far more than emulation costs - but it may well not run at all,
+ # because it links against a System32 libcrypto.dll that is an ARM64 binary
+ # here. That is exactly why candidates are tried by RUNNING them below rather
+ # than by Test-Path, and why the elevated half deletes that ssh.exe outright
+ # when it will not start. Either way this lands on a working client.
$sshCandidates = @(
(Join-Path $RsyncDir 'ssh.exe'),
(Join-Path $env:WINDIR 'System32\OpenSSH\ssh.exe')
Write-Host " $version"
}
+function Set-NativeNinjaFirst {
+ # Make the native ninja.exe the one that wins, including inside a Visual
+ # Studio Developer Command Prompt.
+ #
+ # WHY THIS IS INSURANCE RATHER THAN THE FIX. VS ships an x64 ninja.exe even on
+ # ARM64 and puts it on the PATH from
+ # Common7\Tools\vsdevcmd\ext\cmake.bat, which does:
+ # set "PATH=%PATH%;...\CMake\bin;...\CMake\Ninja"
+ # That APPENDS - the VS directories land at the very end of the composed
+ # PATH, behind every machine and user entry. So a native ninja installed
+ # anywhere on the user PATH already beats it, and measurement on an ARM64 box
+ # confirms it does. (An earlier revision of this script claimed VsDevCmd
+ # prepends and that the VS copy therefore always won; that was wrong.)
+ #
+ # It is still worth pinning the order explicitly: winget appends its package
+ # directory to the user PATH, so the margin depends on nothing more than two
+ # append orders staying as they are, in a file Microsoft owns and revises.
+ # Putting the directory first costs nothing and removes the dependency.
+ #
+ # Ninja is worth this attention where a one-off tool would not be: it is
+ # re-invoked for every edge in the build graph, so it is the one place an
+ # emulated binary is paid over and over rather than once.
+ Write-Step 'Native ninja ahead of the Visual Studio copy'
+
+ $candidates = @()
+ $candidates += Get-ChildItem (Join-Path $env:LOCALAPPDATA 'Microsoft\WinGet\Packages') `
+ -Filter 'ninja.exe' -Recurse -Depth 2 -ErrorAction SilentlyContinue |
+ ForEach-Object { $_.FullName }
+ $candidates += @(
+ (Join-Path $env:ProgramFiles 'Ninja\ninja.exe')
+ (Join-Path $env:LOCALAPPDATA 'Programs\Ninja\ninja.exe')
+ )
+ # A ninja already on the PATH counts too - but only if it is not the VS one,
+ # which is the binary this step exists to get out in front of.
+ $onPath = (Get-Command ninja.exe -ErrorAction SilentlyContinue | Select-Object -First 1).Source
+ if ($onPath -and $onPath -notmatch 'CommonExtensions\\Microsoft\\CMake') { $candidates += $onPath }
+
+ $native = $null
+ foreach ($c in ($candidates | Where-Object { $_ -and (Test-Path $_) } | Select-Object -Unique)) {
+ $m = Get-PEMachine $c
+ if ($m -eq $(if ($IsArm64) { 'ARM64' } else { 'x64' })) { $native = $c; break }
+ }
+
+ if (-not $native) {
+ Write-Warning 'No native ninja.exe found. Install it with: winget install Ninja-build.Ninja'
+ Write-Warning 'Until then a build using the Ninja generator gets the x64 ninja Visual Studio bundles.'
+ return
+ }
+
+ Write-Host " native ninja: $native ($(Get-PEMachine $native))"
+ 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
+ # matters here - would this exe run natively, or through emulation?
+ #
+ # Deliberately NOT Get-Command's .FileVersionInfo or the package metadata:
+ # a multi-architecture package (Sysinternals) ships every build in one zip
+ # under different names, and an installer's own metadata says nothing about
+ # which binary got laid down. The file itself cannot be wrong.
+ param([string]$Path)
+ if (-not (Test-Path $Path)) { return $null }
+ try {
+ $fs = [IO.File]::OpenRead($Path)
+ $br = New-Object IO.BinaryReader($fs)
+ try {
+ $fs.Seek(0x3c, 'Begin') | Out-Null
+ $pe = $br.ReadInt32()
+ if ($pe -le 0 -or $pe -gt ($fs.Length - 6)) { return 'not-PE' }
+ $fs.Seek($pe + 4, 'Begin') | Out-Null
+ switch ($br.ReadUInt16()) {
+ 0x8664 { 'x64' }
+ 0xAA64 { 'ARM64' }
+ 0x014c { 'x86' }
+ 0x01c4 { 'ARM32' }
+ default { 'unknown' }
+ }
+ } finally { $br.Close(); $fs.Close() }
+ } catch { $null }
+}
+
+function Invoke-ArchAudit {
+ # Report the actual architecture of the tools this box provisions, resolved
+ # the way a shell would (PATH first, then the usual install roots), so what
+ # is printed is what you would really run.
+ #
+ # This exists because "winget installed it" does not mean "you got the native
+ # build", and the gap is not always where you would guess - Visual Studio's
+ # own bundled ninja.exe is x64 even on an ARM64 host. A per-run audit turns
+ # that from something you trip over into something the log tells you.
+ #
+ # Purely informational: it never fails the run. On x64 everything is expected
+ # to be x64 and the output is dull; the value is on ARM64, where each line is
+ # either native or a known, listed exception.
+ Write-Step "Architecture audit (host: $HostArch)"
+
+ # Resolve against the PATH a NEW shell would get, not this process's.
+ #
+ # The steps above write the HKCU PATH, which a running process never sees -
+ # so auditing $env:PATH would report the state from before this script ran and
+ # warn about a problem it had just fixed. Compose machine + user from the
+ # registry (the order Windows itself uses), then append anything extra this
+ # process happens to carry: that tail is where a Developer Command Prompt's VS
+ # directories live, and keeping it last mirrors how VsDevCmd appends them.
+ $composed = @()
+ foreach ($scope in 'Machine', 'User') {
+ $v = [Environment]::GetEnvironmentVariable('Path', $scope)
+ if ($v) { $composed += ($v -split ';' | Where-Object { $_.Trim() }) }
+ }
+ $composed += ($env:PATH -split ';' | Where-Object { $_.Trim() })
+ $seen = New-Object 'System.Collections.Generic.HashSet[string]' ([StringComparer]::OrdinalIgnoreCase)
+ $searchPath = @($composed | Where-Object { $seen.Add($_.Trim().TrimEnd('\')) })
+
+ function Resolve-OnPath([string]$Exe) {
+ foreach ($d in $searchPath) {
+ $p = Join-Path $d $Exe
+ if (Test-Path $p -PathType Leaf) { return $p }
+ }
+ return $null
+ }
+
+ # Tools with no native ARM64 build available anywhere, with the reason. These
+ # print as expected rather than as problems - see the README's ARM64 section.
+ $KnownEmulated = @{
+ 'BinSkim.exe' = 'NuGet package publishes win-x64 only; it reads PE headers, so it still analyses ARM64 binaries'
+ 'rsync.exe' = 'no ARM64 asset published; transfer is socket-bound, not CPU-bound'
+ 'OpenCppCoverage.exe' = 'x86/x64 only, and cannot instrument ARM64 binaries - run coverage against the x64 build'
+ 'nasm.exe' = 'x86/x86-64 assembler by definition; ARM64 uses armasm64.exe from MSVC'
+ 'iperf3.exe' = 'no ARM64 build published; network-bound anyway'
+ 'py.exe' = 'python.org ships the launcher shim as x86; it execs the native python.exe'
+ 'vswhere.exe' = 'Microsoft ships x86 only; runs once per script'
+ }
+
+ # Fixable cases: a native build DOES exist, something just resolved ahead of
+ # it. Printed with the finding so the log carries the remedy, not just the
+ # complaint.
+ #
+ # ninja is the one that actually bites: Visual Studio bundles an x64 ninja.exe
+ # even on ARM64, and it is re-invoked for every edge in the build graph, so
+ # an emulated one is paid over and over rather than once. The NinjaPath step
+ # 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 (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
+ $vsWhereExe = Join-Path ${env:ProgramFiles(x86)} 'Microsoft Visual Studio\Installer\vswhere.exe'
+ if (Test-Path $vsWhereExe) {
+ $vs = & $vsWhereExe -products '*' -property installationPath -format value | Select-Object -First 1
+ }
+
+ # name -> extra candidate paths searched when the name is not on the PATH.
+ $targets = [ordered]@{
+ 'git.exe' = @("$env:LOCALAPPDATA\Programs\Git\cmd\git.exe", (Join-Path $env:ProgramFiles 'Git\cmd\git.exe'))
+ 'python.exe' = @()
+ 'py.exe' = @("$env:WINDIR\py.exe")
+ 'pwsh.exe' = @()
+ 'cmake.exe' = @((Join-Path $env:ProgramFiles 'CMake\bin\cmake.exe'))
+ 'ninja.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'))
+ 'rsync.exe' = @((Join-Path $RsyncDir 'rsync.exe'))
+ 'ssh.exe' = @((Join-Path $env:WINDIR 'System32\OpenSSH\ssh.exe'))
+ 'nasm.exe' = @()
+ 'iperf3.exe' = @()
+ 'OpenCppCoverage.exe' = @((Join-Path $env:ProgramFiles 'OpenCppCoverage\OpenCppCoverage.exe'), (Join-Path ${env:ProgramFiles(x86)} 'OpenCppCoverage\OpenCppCoverage.exe'))
+ 'vswhere.exe' = @($vsWhereExe)
+ 'xperf.exe' = @((Join-Path ${env:ProgramFiles(x86)} 'Windows Kits\10\Windows Performance Toolkit\xperf.exe'))
+ }
+ if ($vs) {
+ $targets['MSBuild.exe'] = @((Join-Path $vs 'MSBuild\Current\Bin\arm64\MSBuild.exe'), (Join-Path $vs 'MSBuild\Current\Bin\MSBuild.exe'))
+ # The MSVC and VS-Clang compilers, under whichever MSVC version is present.
+ $msvc = Get-ChildItem (Join-Path $vs 'VC\Tools\MSVC') -Directory -ErrorAction SilentlyContinue |
+ Sort-Object Name | Select-Object -Last 1
+ if ($msvc) {
+ $hostDir = if ($IsArm64) { 'Hostarm64\arm64' } else { 'Hostx64\x64' }
+ $targets['cl.exe (MSVC)'] = @((Join-Path $msvc.FullName "bin\$hostDir\cl.exe"))
+ }
+ $llvmHost = if ($IsArm64) { 'ARM64\bin' } else { 'x64\bin' }
+ $targets['clang-cl.exe (VS)'] = @((Join-Path $vs "VC\Tools\Llvm\$llvmHost\clang-cl.exe"))
+ }
+
+ $native = if ($IsArm64) { 'ARM64' } else { 'x64' }
+ $unexpected = @()
+ foreach ($name in $targets.Keys) {
+ # 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
+ if (-not $mach) { continue }
+ if ($mach -eq $native) {
+ Write-Host (" {0,-22} {1,-6} native" -f $name, $mach) -ForegroundColor Green
+ } elseif ($KnownEmulated.ContainsKey($exe)) {
+ Write-Host (" {0,-22} {1,-6} expected: {2}" -f $name, $mach, $KnownEmulated[$exe]) -ForegroundColor DarkGray
+ } else {
+ Write-Host (" {0,-22} {1,-6} NOT NATIVE - $path" -f $name, $mach) -ForegroundColor Yellow
+ if ($Remedies.ContainsKey($exe)) {
+ Write-Host (" {0,-22} {1,-6} -> {2}" -f '', '', $Remedies[$exe]) -ForegroundColor Yellow
+ }
+ $unexpected += "$name ($mach)"
+ }
+ }
+
+ if ($unexpected) {
+ Write-Warning "Running under emulation with no listed reason: $($unexpected -join ', ')."
+ Write-Warning 'If a native build exists, prefer it (see the -> lines above); otherwise add it to $KnownEmulated with the reason.'
+ } else {
+ Write-Host ' Everything resolved to a native build, or to a listed exception.' -ForegroundColor Green
+ }
+}
+
# ---------------------------------------------------------------------------
# Main
# ---------------------------------------------------------------------------
+Write-Host "Host architecture: $HostArch" -ForegroundColor Cyan
+
if (([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole(
[Security.Principal.WindowsBuiltInRole]::Administrator)) {
Write-Warning 'Running elevated. The user PATH and .gitconfig changes below will apply to the administrator profile, not yours.'
$steps = [ordered]@{
WinMerge = { Add-WinMergeToUserPath }
+ VsWhere = { Add-VsWhereToUserPath }
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 }
}
$failed = @()
vilimpoc.org / repos / dotfiles / blobdiff