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.
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.
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.
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.
Since 3e56f5f41843204b6e612362542b77110f8f8188 in llvm-project,
this should pass for all 4 architectures. (This doesn't pass
in the pinned release version right now.)
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).
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.
This is required for building libffi. With ubuntu-22.04 images,
the libltdl-dev package was available out of the box.
Also explicitly install swig, which we rely on - this also seems
to have been available implicitly.
This fixes building on Ubuntu 24.04 (the one currently used by
the github actions ubuntu-latest tag), by including a fix for texinfo
7.0.
Not bumping to ffmpeg 7.x, as some tests there can be flaky at times.
These days, it seems to be installed out of the box already on the
runner images, and installing it triggers very visible warnings
about it already being installed.
Currently, the "macos-latest" runners aren't really the latest
version - on the contrary, they're running the oldest HW/OS.
Currently, there are macos-12, macos-13 and macos-14, and macos-latest
are the macos-12 ones.
The macos-14 ones run on Apple Silicon.
Previously, the macos-12 runners have usually managed to run the build
job in less than 3 hours. However, lately, the jobs often end up
taking much longer, over 5 hours, and have ended up exceeding the
6 hour timeout occasionally, even if they still also some times run
in the expected time of less than 3 hours.
Switch to the faster macos-14 runners (which can complete the build
job in around 1 h 40 min), to avoid these timeouts.
6b6b1240e2 tried to build a
multiplatform image, by building two images separately and pushing
them one at a time, with the same name (but with a different platform).
This doesn't work as expected; the last push for the image name
replaces earlier pushes. So depending on which push finishes
last, we'd end up with either an amd64 or arm64 image, but not
one that supports both.
Instead, push two separate images just with push-by-digest, and
then create the actual tag with "docker buildx imagetools create".
Alternatively, we could build all platform variants of the main
image with Dockerfile.toolchain, simplifying the setup significantly.
The contents of such a build is marginally different though, so
keep the amd64 image as it was, for now, compiled in that environment.
Martin Storsjö