If using Clang from /usr/bin, this makes it clear to CMake to use
$HOST-strip, as it otherwise may pick plain /usr/bin/strip, which
may not be able to strip the cross built executables.
CMAKE_ASM_COMPILER is set implicitly from CMAKE_C_COMPILER,
but the target flags aren't implied in the same way.
This fixes cross compiling LLVM with clang for an x86_64 target.
This wasn't an issue when cross compiling LLVM with clang for an
aarch64 target, because the BLAKE3 aarch64 SIMD is in the form
of a C file (with intrinsics), not a standalone .S file.
In this case, we want to incrementally build the remaining tools,
not do a full build. In case someone runs build-all.sh with CLEAN
set, the --macos-native-tools invocation of build-llvm.sh shouldn't
wipe the build directory.
This reverts commit 9e628b0f2d.
If LLVM was built with --disable-dylib, then the individual
LLVM libraries may expose a dependency on zlib. By restricting
the lldb-mi build to detect dependencies outside of $LLVM_DIR,
the build of lldb-mi fails to find zlib, making it impossible to
find all the necessary dependencies, ending up with errors like this:
CMake Error at llvm-mingw/llvm-project/llvm/build-asserts/lib/cmake/llvm/LLVMExports.cmake:55 (set_target_properties):
The link interface of target "LLVMSupport" contains:
ZLIB::ZLIB
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
Revert this change for now, to allow building lldb-mi against
a non-dylib build of LLVM.
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.
Do the same as when cross compiling; disallow detecting dependencies
outside of the given CMAKE_FIND_ROOT_PATH. Don't export LLVM_DIR
as we no longer need to pass it implicitly that way.
This makes the errors clearer, if LLVM isn't found where expected,
instead of misdetecting it from a different installation of LLVM
in the system.
If lldb-mi would try to find other optional dependencies, they would
no longer be found; this was already the case when cross compiling
though.
As build-llvm now can create a larger variety of build dir names,
enumerating all possible suffixes becomes problematic (especially
as they don't necessarily appear in one canonical order).
Instead, iterate over potential matches. If cross compiling, it
is easy as we can require the directory to contain the expected
suffix. If not cross compiling, we have no explicit suffix to look
for, but we can check that the directory doesn't match common
cross compilation triples.
Passing --instrumented=IR or --instrumented=Frontend builds
instrumented tool binaries. After running them and merging the
output profile files, run build-llvm.sh with
--profile=profile.profdata.
When cross compiling with llvm-mingw, we already implicitly use
clang and lld, but we don't need to specify these options as they
are set implicitly via the llvm-mingw wrappers.
Don't use tools from $PREFIX/bin automatically; this can be
confusing and problematic. If running with $PREFIX/bin in path,
the build at this stage gets reconfigured if rebuilding after
installing clang.
For multistage builds, install into separate toolchain
directories and add the right one to $PATH before invoking
build-llvm.sh. If one really wants to use the tools from $PREFIX
for a new build into the same directory, one has to add that
directory to the path manually.
This is an option I set outside of this script in a number of
build cases where I build with ccache; move this into the script.
In practice it has little effect though; one has to set
CCACHE_BASEDIR anyway in order to be able to share a ccache
between build directories.
If enabling ccache by adding e.g. /usr/lib/ccache to the front of
PATH, without using the COMPILER_LAUNCHER variable, this won't
get enabled.
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.
Clang expects the aarch64 compiler-rt name on ARM64EC. While this could be adjusted
in Clang, the current approach mirrors MSVC, where the core CRT is provided as
archives containing both EC and native support. Ideally, the LLVM build system would
handle this automatically, but for now we can merge it here.
Martin Storsjö