[windows] Preinstall MSYS2 with CLANGARM64 toolchain on Windows 11 ARM64

[v-davit-ioramashvili]

Description

Preinstall MSYS2 with the CLANGARM64 toolchain on both Windows 11 ARM64 images, so they ship a MinGW toolchain that targets aarch64. As on the x64 images, MSYS2 is installed but not added to PATH.

Size: 1.28 GB. Installation time: 2m14s.

Used an explicit package list (gcc-compat, clang, cmake, make, pkgconf) rather than the mingw-w64-clang-aarch64-toolchain group — the group pulls two full LLVM versions plus lldb and the analyzer for 8.46 GB, with no extra function.

Related issue:

Closes #14087

Changes

• Added Install-Msys2.ps1 to both ARM64 templates; it now picks the native arm64 installer, since the x86_64 one misbehaves there (Installer hangs on Arm64 Windows 11 msys2/msys2-installer#96)
• Populated MsysPackages.mingw in both ARM64 toolsets
• Configure-Shell.ps1 creates msys2bash.cmd on ARM64 with MSYSTEM=CLANGARM64, and fixes the x64 value to MINGW64 (thanks @mmuetzel)
• Dropped the ARM64 skips in MSYS2.Tests.ps1 and the Test-IsX64 gates on the Shells/MSYS2 report sections, so the ARM64 readme documents MSYS2 as the Windows 2025 one does

Testing

Ran the real Install-Msys2.ps1 and Configure-Shell.ps1 on a hosted windows-11-arm runner:

• clangarm64\bin\gcc -dumpmachine -> aarch64-w64-windows-gnu; msys2bash.cmd reports MSYSTEM=CLANGARM64
• MSYS2 Pester tests: 19 passed, 0 failed
• Machine PATH unchanged — no msys64 entry, gcc still resolves to C:\mingw64\bin\gcc.exe
• MSYSTEM casing checked on windows-2025: lowercase mingw64 leaves PATH[0] at /usr/local/bin, MINGW64 correctly prepends /mingw64/bin. No impact on existing jobs — that directory is empty on the current image

Check list

• Related issue / work item is attached
• Tests are written (if applicable)
• Documentation is updated (if applicable)
• Changes are tested and related VM images are successfully generated

[mmuetzel]

For a pre-installed make it would probably be more useful to install this package instead:
https://packages.msys2.org/packages/make?variant=x86_64 (i.e., the "Cygwin" make)

[mmuetzel]

The main difference is probably that make uses a POSIX shell and mingw32-make uses cmd.exe.
Because most Makefiles are written with Linux first in mind, many of the more complex Makefiles assume a working shell with the corresponding intrinsics. Attempting to use mingw32-make with such a Makefile will likely fail.

Very few projects write Makefiles for Windows cmd.exe. So the applications where one would want to use mingw32-make are limited.

For very simple Makefiles, either one would probably work.

[mmuetzel]

It might be best to install the base-devel group instead (which contains the "correct" version of make).

[v-davit-ioramashvili]

Thanks — I gave this a try on a windows-11-arm runner. The package itself is fine: pacman -S make installs cleanly at 1.62 MiB and gives GNU Make 4.4.1 in /usr/bin.

The blocker is elsewhere. Populating MsysPackages.msys2 makes Install-Msys2Packages run, and that function unconditionally does pacman -R p7zip and throws if it fails:

--- Install msys2 packages
Total Installed Size:  1.62 MiB
installing make...
--- Remove p7zip/7z package due to conflicts
error: target not found: p7zip

p7zip isn't part of the msys2 base install any more, so the build dies right after the package installs. That array has been empty on every toolset since Windows 2019 was removed in January, so this went unnoticed.

So adding make needs that removal made conditional first. I'd rather fix it as its own change than fold it into this PR.

[mmuetzel]

Oof. I didn't expect that this would cause so much trouble.
Alternatively, you could probably just drop installing any make package (the mingw32-make is pretty useless imho). Then users could install it with pacman -S make (or with the msys2/setup-msys2 action).