7z is included in the list of officially supported/included
applications on the Github Actions Windows images, so we can
rely on it.
This can be significantly faster than the Expand-Archive command,
see e.g. https://github.com/PowerShell/PowerShell/issues/3355.
Previously, we added the llvm-mingw bundled python to the head
of PATH, but we didn't expect to use it after all.
(In other tests, where we explicitly want to use the llvm-mingw
bundled python, we set -DPython3_EXECUTABLE="$Env:PYTHON_EXE.)
Previously (with runner image version 20260622.87.1), CMake ended
up choosing
C:/hostedtoolcache/windows/Python/3.13.14/x64/python3.exe, but
now (with runner image version 20260629.93.2) we ended up picking
C:/llvm-mingw/python/bin/python3.14.exe instead.
With the newer runner images, we do have
C:\hostedtoolcache\windows\Python\3.13.14\arm64\python3.exe in
PATH, but it is unclear why that doesn't get picked.
(Picking another version than the first one in PATH would make
sense if we'd have Python_FIND_STRATEGY=VERSION set. According to
the docs, that shouldn't be the default any longer though, and it
wouldn't explain why it picked 3.13 before when we provide
3.14.)
In any case, just skip adding our version to PATH since we
don't intend to use it, to make it use the system provided
version.
checkout@v5 should be the same as checkout@v4, just running on
Node 24. checkout@v6 has got a few other minor changes that
shouldn't make any difference; opt in to newer behaviours now.
This is required for properly formatting long doubles on x86
with UCRT (which doesn't use the mingw builtin printfs by default).
This fixes running the LLVM testsuite on x86 after commit
9bf7d04c4386daf1ef0acf95782a59855c98474a in llvm-project.
This allows specifying either a commit or a branch in the same
field, allowing simplifying both the workflow inputs, and
the expressions for passing commit/branch to both
dawidd6/action-download-artifact and actions/checkout.
This new option is available since
https://github.com/dawidd6/action-download-artifact/pull/329.
As the branch field has a default value "master", this default
not only applies when the dialog box for starting the manual
workflow is presented. But even if the prefilled branch field
is cleared, the default value also gets substituted when submitting.
In this case, when the commit and branch fields are mutually
exclusive, we can't easily have a default. Instead change the
uses of the fields, ignoring the branch field if the commit field
is filled.
If the dawidd6/action-download-artifact action would support
specifying either a commit or a branch in the same field, like
actions/checkout does, we wouldn't need this distinction at all;
this request is tracked upstream at
https://github.com/dawidd6/action-download-artifact/issues/242.
As the preinstalled CMake on the windows-11-arm runners currently
is an x86_64 build, we need to explicitly specify
CMAKE_SYSTEM_PROCESSOR, and CMAKE_SYSTEM_NAME to make CMake
consider it a cross compilation (otherwise CMAKE_SYSTEM_PROCESSOR
gets overridden by CMAKE_HOST_SYSTEM_PROCESSOR, which gets influenced
by the x86_64 as CMake is running emulated).
We also need to set LLVM_HOST_TRIPLE, as the autodetection of
it relies on CMAKE_HOST_SYSTEM_PROCESSOR. The host triple needs
to be in normalized form with "-windows-gnu", otherwise a couple
dozens of tests fail.
We also include the AArch64 target, to make sure the built compiler
can generate code for the host.
Since 07bc54bf4554398b199f4dc849e5193b98422f23 in llvm-project
(May 5th), these tests should pass on aarch64 too.
This avoids relying on finding these dependencies in $PATH while
running the tests. Some tests may set PATH="" while executing them,
which previously caused those tests to fail in this build setup.
The same is not an issue with MSVC builds with
-DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDLL, because those
DLLs are also available in global system directories (including
DLLs such as msvcp140.dll and vcruntime140.dll).
Ninja isn't documented as one of the tools provided by the CI runner
images, but it used to be available implicitly installed before
in the windows-2022 images. Since the 20230918.1.0 image update,
it no longer is available out of the box; see
https://github.com/actions/runner-images/issues/8343.
Martin Storsjö