We switched specifically to macos-14 runners in
1a25a0ff74, since the macos-15
runners were notably slower at the time.
The macos-14 runners are being removed now, so we need to switch
to something else.
Before 1a25a0ff74 we occasionally
saw cases where the builds (with macos-latest, resolving to
macos-15 at the time) timed out; we'll have to see if this still
is the case now.
A quick comparison (with a single sample of each), of doing a
single-stage build (without PGO, without LTO) saw macos-14
completing at 3 h 5 m, macos-15 at 4 h 8 m, macos-26 at
4 h 33 m, and xcode-27 at 4 h 7 m - so there's a risk that this
still is 30% slower than macos-14 was.
This also avoids the problem with building on Ubuntu 26.04 if
building docs isn't disabled. (We're not interested in building
the docs here anyway, so keep it disabled in any case.)
This avoids failing if building in an environment where texinfo
exists, but is a newer version. (Support for texinfo 7.1 and 7.2
was added in ffmpeg 8.0.)
Ubuntu 26.04 contains a version of texinfo that fails to build
the docs in ffmpeg 6.0.2. The "ubuntu-latest" runners on Github
Actions are now running on Ubuntu 26.04.
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.
The mingw64 environment is deprecated, which the setup-msys2 action
warns about.
We don't really use the host environment's tools anyway so the
choice doesn't matter. Ideally we maybe would use the msys
environment instead, to avoid accidentally relying on build tools
from there. But if building in the msys environment, ffmpeg things
we're building for msys as opposed to native mingw. (This can
probably be avoided by specifying --target-os though.)
With arm64ec now being built as arm64x, sharing DLLs with the
regular aarch64 target, we no longer need these options - the
regular libc++.dll/libunwind.dll from $PATH (from the toolchain
bin directory) work for the arm64ec build as well.
With arm64ec now being built as arm64x, sharing DLLs with the
regular aarch64 target, we no longer need these options - the
regular libc++.dll/libunwind.dll from $PATH (from the toolchain
bin directory) work for the arm64ec build as well.
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 makes sure the openmp tests actually are executed; since
switching to the runtimes build of openmp for the tests (in
98684ab807), the tests weren't
executed, as it no longer found the tools necessary for executing
the tests - as they are expected to be specified differently
in the runtimes build mode.
This requires the commit 48a5119d8e7d7236a28c14d06ec215ef3366ef90
(backported to 22.x in 9794a7932465bdc244b327388905d66df38485e2,
part of the 22.1.1 release) in llvm-project, to be able to run
tests without actually building clang in the same build as the
test tools.
Since 6295b8e763503644961f9087382f80965b98d466 in llvm-project,
one no longer can configure the openmp project entirely standalone,
one has to do it through the runtimes directory.
However, in practice, this currently leads to no tests being
executed at all, as the runtimes build setup doesn't support
pointing to an external FileCheck executable - it currently has
to be part of a full bootstrapping build.
These builds fail regularly, under mysterious circumstances.
("The hosted runner lost communication with the server. Anything
in your workflow that terminates the runner process, starves it
for CPU/Memory, or blocks its network access can cause this error.")
This usually seems to happen around the build-libcxx.sh step.
For some unknown reason, macos-15 runners (which macos-latest
resolves to currently) seem to be consistently 25-40% slower than
macos-14 runners; the "macos" job (doing an universal binary build
for 2 architectures, with LTO) often take over 5 hours, and have
reached the 6 hour timeout once.
Switch this back to macos-14 to speed it up and reduce the risk of
hitting the timeout.
In the future, if/when the macos-14 runners are phased out, and if
the performance reduction in macos-15 runners remains, we'd need to
switch to building each architecture in a separate job, and merge
them together separately if we still want to provide universal
binaries.
The ARM github actions runners now run on Windows 11 10.0.26100,
which no longer support executing armv7 binaries. (Previously they
were running Windows 11 10.0.22631.)
Using Frontend instrumentation rather than IR. This gives less
total speedup, but makes the profile much more usable for cross
other build targets.
Build the full Linux toolchain in stage1; this avoids needing to
rebuild runtimes for doing the profiling in stage2, and avoids
needing to wait for stage3 to complete before cross building
for Windows.
This requires setting CMAKE_CXX_COMPILER_TARGET manually; the LLVM
build system infers the wrong architecture when CMake is an
x86_64 binary.
(The wrong inferred architecture doesn't affect building libcxx,
but the wrong architecture gets passed as --target= parameter
when running the tests.)
Since 9c67ae861ccb0312fc680414a8441892d169d14a in llvm-project
(May 9th), these tests should pass on aarch64 too.
Co-authored-by: Jeremy Drake <github@jdrake.com>
Currently, "macos-latest" gets "macos-14", while there also are
"macos-15" runners available. Switch back to the latest variant
in preparation for that being updated at some point.
This reverts 7bd4b284f9.
Since 3e56f5f41843204b6e612362542b77110f8f8188 in llvm-project,
this should pass for all 4 architectures. (This doesn't pass
in the pinned release version right now.)
This matches what 28851edf164a337c334755ae33fd58f03cffd5a2 in
llvm-project did.
When setting up the built libcxx files for testing, the built
files are installed into a temporary test root, and the install of
them litters the build log with mostly uninteresting output.
Martin Storsjö