X-Git-Url: https://vilimpoc.org/repos/dotfiles/blobdiff_plain/d68d73b6badfe1170a30008073d69fbcc38d80c1..3e0aa9fcdd4d04bd4d0714668af9af5fd200cb42:/setup-windows.bat?ds=inline diff --git a/setup-windows.bat b/setup-windows.bat index cc12420..05e65eb 100644 --- a/setup-windows.bat +++ b/setup-windows.bat @@ -2,30 +2,195 @@ @rem --------------------------------------------------------------------------- @rem setup-windows.bat - provision a fresh Windows box for native development +@rem +@rem Runs on x64 and on ARM64 (Windows 11 on Arm). See the ARM64 block below for +@rem what changes on Arm silicon. @rem --------------------------------------------------------------------------- +@rem --------------------------------------------------------------------------- +@rem Host architecture +@rem +@rem PROCESSOR_ARCHITECTURE alone is not enough: a 32-bit cmd.exe under emulation +@rem reports x86 and stashes the real one in PROCESSOR_ARCHITEW6432. Check both, +@rem so this is right however the script was launched. +@rem +@rem The value drives two things below, and nothing else - winget resolves the +@rem installer architecture on its own (native first, then whatever the box can +@rem emulate), so the ordinary installs need no help: +@rem - VirtualBox is skipped on ARM64 (see below) +@rem - the summary tells you which tools you got as emulated x64 +@rem --------------------------------------------------------------------------- +set "HOST_ARCH=%PROCESSOR_ARCHITECTURE%" +if defined PROCESSOR_ARCHITEW6432 set "HOST_ARCH=%PROCESSOR_ARCHITEW6432%" +set "IS_ARM64=0" +if /i "%HOST_ARCH%"=="ARM64" set "IS_ARM64=1" +echo [setup-windows] Host architecture: %HOST_ARCH% + @rem --- Non-admin (per-user) winget installs --- +@rem +@rem No --architecture anywhere on purpose. winget already picks the best +@rem installer the manifest offers for this machine - arm64, else x64, else x86 - +@rem and pinning it would turn "no native build, use the emulated one" into a +@rem hard failure. +@rem +@rem These all publish real ARM64 installers, so on an ARM64 box every one of +@rem them lands as a native ARM64 binary with no emulation involved. +@rem +@rem The Sysinternals packages are a multi-architecture ZIP rather than an +@rem installer, so the ARM64 build is IN there but is not the default-named exe: +@rem the zip holds procexp.exe (x86), procexp64.exe (x64) and procexp64a.exe +@rem (ARM64). On ARM64, run the *64a.exe variants - plain procexp.exe is the x86 +@rem one and will run emulated. winget install Anthropic.ClaudeCode +winget install Brave.Brave winget install Git.Git +winget install Microsoft.DotNet.SDK.10 winget install Microsoft.PowerShell Microsoft.Sysinternals.ProcessExplorer Microsoft.Sysinternals.ProcessMonitor Microsoft.Sysinternals.SDelete Microsoft.VisualStudioCode Microsoft.WindowsTerminal -winget install Oracle.VirtualBox winget install Python.Python.3.13 winget install WinMerge.WinMerge -winget install WiXToolset.WiXCLI + +@rem --- Build drivers, standalone and native --- +@rem +@rem CMake and Ninja BOTH ship with Visual Studio, so this is not about making +@rem them exist - it is about which binary you get and where it is on the PATH: +@rem +@rem - VS's cmake.exe is already ARM64, but it only lands on the PATH inside a +@rem Developer Command Prompt. The build line further down assumes a plain +@rem `cmake`, so install the standalone one to make that true in any shell. +@rem - VS's bundled ninja.exe is x64 EVEN ON ARM64 (verified on this box), so it +@rem runs under emulation. Ninja is re-invoked for every edge in the build +@rem graph, which makes it the one tool here where emulation is actually paid +@rem over and over, and ninja-winarm64.zip is a native build. Worth having. +@rem +@rem Which ninja wins inside a VS Developer Command Prompt: the native one. VS +@rem adds its copy from Common7\Tools\vsdevcmd\ext\cmake.bat with +@rem set "PATH=%PATH%;...\CMake\bin;...\CMake\Ninja" +@rem which APPENDS, so the VS directories sit at the very end of the composed +@rem PATH, behind every machine and user entry. setup-windows-no-uac.ps1 then +@rem pins the native ninja's directory to the FRONT of the user PATH so the +@rem margin does not depend on two append orders staying as they are. +winget install Kitware.CMake +winget install Ninja-build.Ninja + +@rem --- Second, independent Clang: compiler diversity --- +@rem +@rem The elevated half installs Visual Studio's Clang component (clang-cl, native +@rem ARM64). This is a DIFFERENT LLVM: the upstream release, on its own schedule +@rem and usually several major versions ahead of the one VS bundles, installed to +@rem C:\Program Files\LLVM rather than inside the VS tree. Two Clang majors plus +@rem MSVC over the same sources is the point - it is what catches the bugs a +@rem single toolchain agrees with itself about. +@rem +@rem Native on ARM64: the manifest resolves to LLVM--woa64.exe ("Windows on +@rem Arm 64"), not the x64 build. +@rem +@rem PATH ORDER MATTERS if you use it. Should this installer put its bin on the +@rem PATH, a bare `clang-cl` resolves to the upstream one while CMake's +@rem `-T ClangCL` toolset keeps using the VS copy - so the two can be selected +@rem independently, but only if you know which one you are asking for. Prefer +@rem -DCMAKE_CXX_COMPILER with a full path when you care. +winget install LLVM.LLVM + +@rem x64-only manifests: winget falls back to the x64 installer on ARM64 and these +@rem run under Prism emulation. Harmless for what they do here - iperf3 is a +@rem network benchmark bounded by the link, and AGI is an Android-side GPU +@rem profiler whose work happens on the phone. Neither is CPU-bound on this box. +winget install ar51an.iPerf3 +winget install Google.AndroidGPUInspector + +@rem NASM assembles x86/x86-64 only - there is no ARM64 target in it and no ARM64 +@rem build of it. Installed on ARM64 anyway (as emulated x64) because this box +@rem still cross-compiles x86/x64 binaries, where NASM is the assembler that +@rem builds them. If you only ever target ARM64, nothing here uses it: the ARM64 +@rem assembler is armasm64.exe, which ships with MSVC. +winget install NASM.NASM + +@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 +@rem a failed driver install, so skip it and say so. +@rem +@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. +if "%IS_ARM64%"=="1" ( + echo [setup-windows] Skipping Oracle.VirtualBox: no ARM64 Windows host build ^(x64 hypervisor drivers cannot load on an ARM64 kernel^). + echo [setup-windows] The Windows 7 x86 test-VM workflow ^(setup-windows-7-test-env.bat^) is therefore unavailable on this box. +) else ( + winget install Oracle.VirtualBox +) @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. +@rem +@rem x86/x64 only, and unlike the other emulated tools that is a real limit rather +@rem than a slowdown: it collects coverage by debugging the process under test and +@rem stepping x86/x64 instructions, so it can cover the x86/x64 binaries this box +@rem cross-compiles but NOT an ARM64 one. For ARM64 coverage, build the ARM64 +@rem binaries with /fsanitize-coverage or use the x64 build for the coverage run. winget install OpenCppCoverage.OpenCppCoverage +if "%IS_ARM64%"=="1" echo [setup-windows] NOTE: OpenCppCoverage is x86/x64-only - it cannot instrument ARM64 binaries. Run coverage against the x64 build. + +@rem --- WiX 5.0.2, pinned on purpose --- +@rem WiX packages our proprietary software into MSIs, and the version is pinned to keep that +@rem free of a fee. 5.0.2 is the last release distributed under the Microsoft Reciprocal +@rem License alone. From 6.0 onward the package also carries OSMFEULA.txt, an Open Source +@rem Maintenance Fee agreement: a monthly fee owed by anyone who uses the PREBUILT BINARIES +@rem as part of revenue-generating activity and has annual gross revenue >= US$10,000. +@rem +@rem It is a fee for the binaries, not a restriction on what we ship - MS-RL is file-scoped +@rem and never reached the MSIs WiX builds, under any version - but 5.0.2 owes nothing. +@rem The 6.x/7.x SOURCE is still MS-RL too, so self-compiling is another way out; a pin is +@rem the cheaper one. This replaces `winget install WiXToolset.WiXCLI`, which has no version +@rem selector and so installs the latest (7.0.0 today, EULA and all). +@rem +@rem PIN THE MSBUILD SIDE TOO. A .wixproj referencing WixToolset.Sdk without a version +@rem resolves to the latest - 7.x, same EULA - and nothing here constrains it. Pin it in the +@rem project: . +@rem +@rem dotnet.exe is called by full path: winget put the SDK on the machine PATH a few lines +@rem ago, but this cmd session inherited its environment before that and cannot see it. +@rem install-then-update is for re-runs - install fails once the tool is there, and update +@rem then holds it at exactly 5.0.2 - which keeps this script idempotent like the rest. +@rem +@rem %ProgramFiles%\dotnet is the NATIVE SDK's root on every architecture, ARM64 +@rem included - what winget just installed. An x64 SDK installed alongside it on +@rem an ARM64 box goes to %ProgramFiles%\dotnet\x64 instead, so fall back there +@rem for a machine that only ever got the x64 one. Prefer the native root: the +@rem ARM64 SDK runs the wix tool natively, and building an MSI is not something +@rem worth doing through emulation. +set "DOTNET_EXE=%ProgramFiles%\dotnet\dotnet.exe" +if not exist "%DOTNET_EXE%" set "DOTNET_EXE=%ProgramFiles%\dotnet\x64\dotnet.exe" +if not exist "%DOTNET_EXE%" echo [setup-windows] WARNING: dotnet.exe not found; skipping the WiX 5.0.2 pin. +if not exist "%DOTNET_EXE%" goto :after_wix + +"%DOTNET_EXE%" tool install --global wix --version 5.0.2 || "%DOTNET_EXE%" tool update --global wix --version 5.0.2 + +@rem Report what the pin actually produced. By full path again, and because the shim lands in +@rem a directory this session's PATH predates: expect "5.0.2+", not 7.x. +"%USERPROFILE%\.dotnet\tools\wix.exe" --version + +:after_wix @rem --------------------------------------------------------------------------- @rem No package manager needed for the Windows build @rem @rem Just: @rem cd windows && cmake -B build -G "Visual Studio 17 2022" -A x64 && cmake --build build --config Release +@rem +@rem -A selects the TARGET, independently of the host. On an ARM64 box the same +@rem generator cross-compiles all three, and MSVC's ARM64-hosted toolchain is used +@rem for each - nothing is emulated: +@rem -A ARM64 native ARM64 binaries +@rem -A x64 x64 binaries (run here under emulation) +@rem -A Win32 x86 binaries +@rem Use the generator matching the Visual Studio the elevated half installed - +@rem "Visual Studio 17 2022" on x64, "Visual Studio 18 2026" on ARM64 - or just +@rem let CMake pick the newest it finds. @rem --------------------------------------------------------------------------- -@rem --- Elevated installs (VS2022, WDK, system tools) --- +@rem --- Elevated installs (Visual Studio, WDK, system tools) --- @rem The elevated script runs in its own window and logs to setup-windows-uac.log. @rem -PassThru + $p.ExitCode propagates its real exit code back through to ERRORLEVEL. set "UAC_LOG=%~dp0setup-windows-uac.log" @@ -79,4 +244,21 @@ echo [setup-windows] Elevated setup completed successfully. @rem py -m pip install "headroom-ai[all]" @rem npm install headroom-ai -py -m pip install Pillow \ No newline at end of file +@rem Pillow publishes win_arm64 wheels alongside win_amd64, so `py` - the ARM64 +@rem Python winget just installed - gets a native wheel and never falls back to +@rem building from source. Any package WITHOUT an ARM64 wheel does fall back, and +@rem that source build needs the MSVC toolchain the elevated half installs. +py -m pip install Pillow + +if "%IS_ARM64%"=="1" ( + echo. + echo [setup-windows] ARM64 notes: + echo [setup-windows] native ARM64: Git, Python, .NET SDK, PowerShell, VS Code, Windows Terminal, + echo [setup-windows] WinMerge, Brave, Sysinternals ^(the *64a.exe variants^), + echo [setup-windows] Claude Code, CMake, Ninja, and the SDK/WPT tools. + echo [setup-windows] compilers : MSVC and clang-cl from Visual Studio 2026, plus upstream + echo [setup-windows] LLVM - all three native ARM64, two different Clang majors. + echo [setup-windows] emulated x64: iperf3, NASM, OpenCppCoverage, BinSkim, rsync.exe, AGI. + echo [setup-windows] unavailable : VirtualBox, the Windows 7 x86 test VM, Intel VTune, + echo [setup-windows] and the v141 / Windows XP targeting toolset. +)