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.
This avoids warnings about the actions targeting Node 20.
There is no easily available documentation about whether there are
any other API changes in the newer versions of these actions - in
particular the bump of build-push-action which advances by two
versions.
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.
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 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.
This matches what is done for the regular builds; we run (build-only)
tests already with the first cross compiler toolchains, not needing
to wait for the cross compiled toolchains to run on Windows.
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.
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.)
This makes the docker image contain a PGO optimized compiler,
without needing to redo all of the PGO build stages in docker.
This reverts commit 8f42112719,
and fixes building the multiplatform image in a simpler way.
Instead of doing two separate builds, with separate Dockerfiles,
just do one multiplatform build of one Dockerfile, which
docker runs serially, for each one of the included architectures,
just packaging the prebuilt toolchains in the docker image.
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 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.
Martin Storsjö