X-Git-Url: https://vilimpoc.org/repos/dotfiles/blobdiff_plain/7d4887fe245e7643a497e87e04fc8f97d8ca436f..f51da37a77ac790110def9697b57f49b821c4c75:/setup-windows-no-uac.ps1?ds=sidebyside diff --git a/setup-windows-no-uac.ps1 b/setup-windows-no-uac.ps1 index 1197300..27f7a0e 100644 --- a/setup-windows-no-uac.ps1 +++ b/setup-windows-no-uac.ps1 @@ -11,16 +11,19 @@ elevated would configure the *administrator's* profile instead of yours. What this installs / configures: - - WinMerge on the user PATH + - WinMerge on the user PATH (x64 only) - 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 (x64 only - the NuGet package publishes win-x64 alone) - 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. @@ -35,12 +38,43 @@ param( # 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')] + [ValidateSet('WinMerge', 'VsWhere', 'BinSkim', 'GitConfig', 'NinjaPath', 'LlvmPath', 'ArchAudit')] [string[]] $Skip = @() ) $ErrorActionPreference = 'Stop' +# Host architecture, from the machine environment in the registry. Both of the +# obvious sources report the EMULATED architecture inside an emulated x64 +# PowerShell - which is what `powershell` resolves to when launched from an x64 +# shell on an ARM64 box. Measured on this machine: +# [RuntimeInformation]::OSArchitecture X64 <- wrong +# $env:PROCESSOR_ARCHITECTURE AMD64 <- wrong +# HKLM\...\Session Manager\Environment ARM64 <- right +# OSArchitecture is documented as the OS's architecture, and on .NET Core it is; +# under .NET Framework on Prism it is not, so it is kept only as a fallback. +# $IsArm64 decides which steps run at all, so this has to be the real one. +$rawArch = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -ErrorAction SilentlyContinue).PROCESSOR_ARCHITECTURE +if (-not $rawArch) { $rawArch = [Runtime.InteropServices.RuntimeInformation]::OSArchitecture.ToString() } +$IsArm64 = ($rawArch -eq 'ARM64') +$HostArch = if ($IsArm64) { 'Arm64' } elseif ($rawArch -eq 'AMD64') { 'X64' } else { $rawArch } + +# Steps that do not run on ARM64, with the reason printed in place of the step. +# +# The ARM64 machine is provisioned as a single-compiler build box - see the +# x64-only set in setup-windows.bat - so the packages these three steps wire up +# are not installed there. Skipping the step rather than letting it find nothing +# matters: Install-BinSkim would happily download and PATH the x64 build, and +# Add-LlvmToUserPath is the step that put an emulated-adjacent toolchain on the +# PATH ahead of MSVC in the first place. +# +# -Skip still works on top of this; it can only subtract. +$Arm64Dropped = [ordered]@{ + WinMerge = 'not installed on ARM64 - the only build an unelevated winget can fetch is the emulated x64 one' + BinSkim = 'not installed on ARM64 - the NuGet package publishes win-x64 only' + LlvmPath = 'not installed on ARM64 - this box carries MSVC alone' +} + # --- 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 @@ -62,19 +96,46 @@ function Write-Step([string]$Msg) { 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 } - $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)." + + if ($already -and (& $norm $entries[0]) -eq (& $norm $Dir)) { + Write-Host " $Dir already first in user PATH." + return + } + $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 { @@ -113,11 +174,21 @@ function Add-VsWhereToUserPath { 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. @@ -182,10 +253,22 @@ function Install-BinSkim { -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\\\ 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. @@ -255,6 +338,16 @@ function Set-GlobalGitConfig { # 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') @@ -298,9 +391,322 @@ function Set-GlobalGitConfig { 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. + # + # Shorter than it was: BinSkim, OpenCppCoverage and NASM used to be listed + # here as accepted emulation, and are now simply not installed on ARM64. That + # is the whole shape of the change - the exceptions that were tolerable one at + # a time added up to a VM full of x64 binaries. + # + # rsync came off this list when the release started publishing an arm64 + # asset. An x64 rsync.exe on an ARM64 box is now a leftover from a run before + # that, not an accepted exception, so it warns and gets a remedy below. + $KnownEmulated = @{ + '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. + # + # Only two left, and both are for tools ARM64 still installs. The clang-cl and + # WinMerge remedies were removed with their rows: advising an install that the + # x64-only set has just declined to do would be the audit arguing with the + # provisioning. + $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).' + 'rsync.exe' = 'Left over from before the release published an arm64 asset. Re-run setup-windows-with-uac.ps1 as an administrator to replace it, and the ARM64 ssh.exe beside it, with the native build.' + } + + $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' = @() + # Both homes of the launcher: C:\Windows for an all-users install, the + # per-user Launcher directory otherwise. Often neither - it is a separate + # component from the interpreter, and "- not installed" here next to a + # native python.exe is the normal result of an unelevated Python install. + 'py.exe' = @("$env:WINDIR\py.exe", "$env:LOCALAPPDATA\Programs\Python\Launcher\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")) + } + + # Tools this box does not provision on ARM64. Dropped from the audit rather + # than left to print "- not installed", because that line reads as a gap in + # the provisioning when it is the provisioning working as intended - and a + # dull audit is one you keep reading. + # + # The rows survive on x64, where all of these are installed and expected. + # Anything still on disk from before the split shows up in the winget list, + # not here. + if ($IsArm64) { + foreach ($gone in 'WinMergeU.exe', 'BinSkim.exe', 'nasm.exe', + 'OpenCppCoverage.exe', 'clang-cl.exe', 'clang-cl.exe (VS)') { + $targets.Remove($gone) + } + } + + $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.' @@ -311,6 +717,11 @@ $steps = [ordered]@{ 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 = @() @@ -319,6 +730,10 @@ foreach ($name in $steps.Keys) { Write-Host "`n==> $name (skipped)" -ForegroundColor DarkGray continue } + if ($IsArm64 -and $Arm64Dropped.Contains($name)) { + Write-Host "`n==> $name (skipped: $($Arm64Dropped[$name]))" -ForegroundColor DarkGray + continue + } try { & $steps[$name] } catch {