X-Git-Url: https://vilimpoc.org/repos/dotfiles/blobdiff_plain/0b4125206461c1a63a971ac9cf503319bcb05798..8ea420894f0b867760b56c7f8d322ba89af8e6a3:/setup-windows.bat?ds=sidebyside diff --git a/setup-windows.bat b/setup-windows.bat index 7445de5..eb145ec 100644 --- a/setup-windows.bat +++ b/setup-windows.bat @@ -95,6 +95,8 @@ if "%ELEV%"=="NOLUA" ( @rem VS Clang/LLVM component with-uac see $ClangComponents @rem Windows Driver Kit with-uac see the WDK step @rem BinSkim no-uac NuGet publishes win-x64 only +@rem Google.AndroidStudio here no Windows ARM64 build +@rem Android SDK no-uac Windows build tools are x86/x64 only @rem @rem The decision itself is made in ONE place, setup-windows-steps.ps1, which @rem marks each of these -X64Only with its reason. The plan shows them as [-] @@ -211,7 +213,44 @@ call :winget ProcessExplorer Microsoft.Sysinternals.ProcessExplorer call :winget ProcessMonitor Microsoft.Sysinternals.ProcessMonitor call :winget SDelete Microsoft.Sysinternals.SDelete call :winget VSCode Microsoft.VisualStudioCode + +@rem --- Windows Terminal, after registering the framework package it needs --- +@rem +@rem Terminal is an MSIX, and its manifest depends on the Microsoft.UI.Xaml.2.8 +@rem framework package (>= 8.2306.22001.0), which winget installs first, from the +@rem 8.2310.30001.0 appx. That goes wrong when a NEWER build of the framework is +@rem already on the machine but not registered for this account - measured on +@rem the Windows 10 box, winget 1.29.380, with 8.2501.31001.0 staged and none +@rem registered for the account running this: +@rem - Windows stages nothing ("A higher version 8.2501.31001.0 of this package +@rem is already installed", AppXDeploymentServer event 735) and reports the +@rem stage as a success; +@rem - winget then registers the 8.2310 package it believes it staged, by full +@rem name, and there is no such package (0x80073CF1); +@rem - which it prints as +@rem Installer failed with exit code: 0x80070002 : The system cannot +@rem find the file specified. +@rem and Terminal itself is never attempted. On every run, since a failed +@rem run changes nothing. +@rem +@rem So register the build that is already there for this account first - by +@rem family name, which takes no version and no elevation. winget then finds the +@rem dependency met and installs Terminal alone. Asked only when this account +@rem has none registered, the case measured, so a re-run - Terminal and its +@rem framework both in place - changes nothing. +@rem +@rem With none on the machine either, the registration fails with that same +@rem 0x80073CF1, and that is not worth a line: it is the fresh box, where nothing +@rem is in winget's way and it installs the framework itself. Any other failure +@rem is reported, and winget still gets its turn. +@rem +@rem %PS64% because it is Windows PowerShell: the Appx module does not load in +@rem PowerShell 7 here ("Operation is not supported on this platform"). +call :want WindowsTerminal || goto :after_terminal +"%PS64%" -NoProfile -ExecutionPolicy Bypass -Command "$f = 'Microsoft.UI.Xaml.2.8'; if (-not (Get-AppxPackage $f)) { try { Add-AppxPackage -RegisterByFamilyName -MainPackage ($f + '_8wekyb3d8bbwe') -ErrorAction Stop; Write-Host ('[setup-windows] WindowsTerminal: registered ' + $f + ' ' + @(Get-AppxPackage $f)[0].Version + ', already on this machine, for this account.') } catch { if ($_.Exception.Message -notmatch '0x80073CF1') { Write-Host ('[setup-windows] WARNING: could not register ' + $f + ' for this account: ' + ($_.Exception.Message -split '\r?\n')[0]) } } }" call :winget WindowsTerminal Microsoft.WindowsTerminal +:after_terminal + call :winget Python Python.Python.3.13 @rem WinMerge is the one package here where winget's own preference order picks @@ -337,6 +376,46 @@ call :want NASM || goto :after_nasm if not "%ERRORLEVEL%"=="0" call :winget NASM NASM.NASM :after_nasm +@rem MSYS2, per-user, for the MinGW-w64 GCC toolchains - the same ones GitHub's +@rem windows-latest runner carries under C:\msys64, so a build that works here +@rem works there. Two environments are installed: +@rem ucrt64 x86_64, links the UCRT - the modern target +@rem mingw32 i686, links msvcrt.dll - the one that can still target +@rem Windows XP +@rem +@rem Not through winget: the MSYS2.MSYS2 package runs the GUI installer, which +@rem installs machine-wide into C:\msys64 by default. The self-extracting +@rem archive (7-Zip SFX) needs no elevation and unpacks wherever it is pointed, +@rem here %LOCALAPPDATA%\msys64. Nothing is put on the PATH on purpose: the +@rem environments' bin directories carry same-named exes (gcc, ld, windres) and +@rem a project picks one by its full path, e.g. %LOCALAPPDATA%\msys64\mingw32\bin. +@rem +@rem Re-running: the archive is downloaded only when pacman is missing; otherwise +@rem `pacman -Syu` updates what is there and `--needed` leaves installed packages +@rem alone. The first -Syu after a fresh unpack may replace the MSYS2 runtime and +@rem end the shell on purpose, which is why it runs twice. +call :want Msys2 || goto :after_msys2 +set "MSYS2_ROOT=%LOCALAPPDATA%\msys64" +if exist "%MSYS2_ROOT%\usr\bin\pacman.exe" goto :msys2_packages +echo [setup-windows] Msys2: downloading the MSYS2 base archive +"%PS64%" -NoProfile -ExecutionPolicy Bypass -Command "$ProgressPreference='SilentlyContinue'; Invoke-WebRequest -Uri 'https://github.com/msys2/msys2-installer/releases/latest/download/msys2-base-x86_64-latest.sfx.exe' -OutFile \"$env:TEMP\msys2-base.sfx.exe\"" +if not exist "%TEMP%\msys2-base.sfx.exe" ( echo [setup-windows] Msys2: download failed & goto :after_msys2 ) +echo [setup-windows] Msys2: unpacking into %MSYS2_ROOT% +"%TEMP%\msys2-base.sfx.exe" -y -o"%LOCALAPPDATA%" >nul +del /q "%TEMP%\msys2-base.sfx.exe" 2>nul +if not exist "%MSYS2_ROOT%\usr\bin\pacman.exe" ( echo [setup-windows] Msys2: unpack failed & goto :after_msys2 ) +@rem First start: creates the home directory and the key ring. +"%MSYS2_ROOT%\usr\bin\bash.exe" -lc "true" +:msys2_packages +echo [setup-windows] Msys2: updating the base system +"%MSYS2_ROOT%\usr\bin\bash.exe" -lc "pacman -Syuu --noconfirm" +"%MSYS2_ROOT%\usr\bin\bash.exe" -lc "pacman -Syuu --noconfirm" +echo [setup-windows] Msys2: MinGW-w64 GCC for ucrt64 and mingw32 +"%MSYS2_ROOT%\usr\bin\bash.exe" -lc "pacman -S --noconfirm --needed mingw-w64-ucrt-x86_64-gcc mingw-w64-i686-gcc" +"%MSYS2_ROOT%\mingw32\bin\gcc.exe" --version | findstr /i "gcc" && echo [setup-windows] Msys2: mingw32 gcc ready in %MSYS2_ROOT%\mingw32\bin +"%MSYS2_ROOT%\ucrt64\bin\gcc.exe" --version | findstr /i "gcc" && echo [setup-windows] Msys2: ucrt64 gcc ready in %MSYS2_ROOT%\ucrt64\bin +:after_msys2 + @rem VirtualBox has no ARM64 Windows host build, and the x64 one cannot be made to @rem work by emulation: a hypervisor is kernel-mode, and its x64 driver will not @rem load on an ARM64 kernel. Installing it on ARM64 gets you a broken product and @@ -345,6 +424,12 @@ if not "%ERRORLEVEL%"=="0" call :winget NASM NASM.NASM @rem This is also what makes setup-windows-7-test-env.bat unreachable from an @rem ARM64 host: it prepares a Windows 7 *x86* guest, and neither VirtualBox nor @rem Hyper-V on ARM64 can run one. +@rem +@rem Nor is it installed when this Windows is itself a virtual machine, which the +@rem planner reads from the firmware's SMBIOS strings: the test VMs belong on the +@rem physical host, and nesting VirtualBox inside a guest needs nested +@rem virtualization the outer hypervisor usually does not offer. The plan marks it +@rem -NotInVM, with that reason, and names the hypervisor it found. call :winget VirtualBox Oracle.VirtualBox @rem --------------------------------------------------------------------------- @@ -378,6 +463,27 @@ call :winget DotNetSdk Microsoft.DotNet.SDK.10 call :winget CMake Kitware.CMake call :winget AndroidGPUInspector Google.AndroidGPUInspector +@rem --- Android Studio --- +@rem +@rem Machine-wide: the manifest's NSIS installer elevates itself and installs to +@rem %ProgramFiles%\Android\Android Studio. x64 only - there is no ARM64 build - +@rem so the plan keeps it off ARM64. +@rem +@rem Installed only when it is missing, which setup-windows-current.ps1 decides. +@rem Android Studio updates itself, in the app, and the winget package is published +@rem with UpgradeBehavior: deny and RequireExplicitUpgrade, so winget would never +@rem upgrade it anyway. What the check prevents is the other case: a Studio that +@rem was installed some other way - as on the x64 laptop, where winget lists it +@rem only by its Add/Remove Programs key - is one winget cannot match to the +@rem package, so `winget install` would run the installer over it. +@rem +@rem It is also where the per-user Android SDK step gets its JDK: Studio bundles +@rem one (jbr), and the SDK's sdkmanager and Gradle both need Java. +call :want AndroidStudio || goto :after_studio +"%PS64%" -NoProfile -ExecutionPolicy Bypass -File "%~dp0setup-windows-current.ps1" -Step AndroidStudio -HostArch "%HOST_ARCH%" +if not "%ERRORLEVEL%"=="0" call :winget AndroidStudio Google.AndroidStudio +:after_studio + @rem OpenCppCoverage: native (PE) line coverage for the C++ binaries. run-coverage-occ.py drives the @rem pytest suite under it to produce an HTML report (the binaries under test build with PDBs, @rem which it reads). The installer elevates via UAC. @@ -687,9 +793,9 @@ if "%IS_ARM64%"=="1" ( echo [setup-windows] compiler by design; clang-cl and upstream LLVM are x64-box only. echo [setup-windows] Rust stable-aarch64-pc-windows-msvc, native, linking through MSVC. echo [setup-windows] emulated : iperf3 ^(x64^) and adb ^(x86^), both bound by their link, not the CPU. - echo [setup-windows] not here : Brave, WinMerge, LLVM, NASM, AGI, OpenCppCoverage, BinSkim - echo [setup-windows] and the WDK - dropped on ARM64; the plan above says why. - echo [setup-windows] unavailable : VirtualBox, the Windows 7 x86 test VM, Intel VTune, + echo [setup-windows] not here : Brave, WinMerge, LLVM, NASM, AGI, OpenCppCoverage, BinSkim, + echo [setup-windows] the WDK and the Android SDK - dropped on ARM64; the plan above says why. + echo [setup-windows] unavailable : VirtualBox, the Windows 7 x86 test VM, Intel VTune, Android Studio, echo [setup-windows] and the v141 / Windows XP targeting toolset. ) @rem The list above is what this script PROVIDES on ARM64, not necessarily what