This is necessary so that Tests.cmake is always included in the
generated build file and any changes made by subbuilds are detected
without needing to rerun CMake.
This is equivalent to an earlier version of D121647.
Differential Revision: https://reviews.llvm.org/D121647
This patch makes it possible to pass a CMake option to one of the runtimes
for all targets being built. Basically, any option that starts with the
name of a runtime project being built will be forwarded as-is to the
sub-build. This is useful for customizing a sub-build for all targets.
Differential Revision: https://reviews.llvm.org/D121822
This ensures that Tests.cmake is tracked by Ninja and any changes to
this file from the subbuilds are correctly detected.
Differential Revision: https://reviews.llvm.org/D121647
This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.
Differential Revision: https://reviews.llvm.org/D119918
Prior to this change, we would make check-all depend on check-runtimes
which is a target that runs tests in the runtimes build. This means that
the runtimes tests are going to run prior to other test suites in
check-all, and if one of them fails, we won't run the other test suites
at all.
To address this issue, we instead collect the list of test suites and
their dependencies from the runtimes subbuild, and include them in
check-all, so a failure of runtimes test suite doesn't prevent other
test suites from being executed.
This addresses https://github.com/llvm/llvm-project/issues/54154.
Differential Revision: https://reviews.llvm.org/D121276
The upstream project ships CMake rules for building vanilla gtest/gmock which conflict with the names chosen by LLVM. Since LLVM's build rules here are quite specific to LLVM, prefixing them to avoid collision is the right thing (i.e. there does not appear to be a path to letting someone *replace* LLVM's googletest with one they bring, so co-existence should be the goal).
This allows LLVM to be included with testing enabled within projects that themselves have a dependency on an official gtest release.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D120789
When using the default target, there's no other way to pass these
into the builtins and runtimes subbuilds.
Differential Revision: https://reviews.llvm.org/D116976
When building compiler-rt via runtimes, many tests fail because tools like
FileCheck and count aren't built yet. This is because the RUNTIME_TEST_DEPENDENCIES
haven't been added to any of the compiler-rt targets. The fix is to explicitly
add any runtimes as test_targets.
Differential Revision: https://reviews.llvm.org/D109625
In some build configurations, the target we depend on is not available for declaring the build dependency.
We only need to declare the build dependency, if the build target is available in the same build.
Fixes the issue raised in https://reviews.llvm.org/D107156#2969862
This patch should go into release/13 together with D108404
Differential Revision: https://reviews.llvm.org/D108868
D107156 and D107320 are not sufficient when OpenMP is built as llvm runtime
(LLVM_ENABLE_RUNTIMES=openmp) because dependencies only work within the same
cmake instance.
We could limit the dependency to cases where libomptarget/plugins are really
built. But compared to the whole llvm project, building openmp runtime is
negligible and postponing the build of OpenMP runtime after the dependencies
are ready seems reasonable.
The direct dependency introduced in D107156 and D107320 is necessary for the
case where OpenMP is built as llvm project (LLVM_ENABLE_PROJECTS=openmp).
Differential Revision: https://reviews.llvm.org/D108404
When using `-DLLVM_ENABLED_RUNTIMES` instead of `-DLLVM_ENABLED_PROJECTS`
the `llvm-omp-device-info` tool is not compiled or installed.
In general, no llvm tool would be build on runtimes, because the
-DLLVM_BUILD_TOOLS flag is removed by the way runtimes compilation calls
cmake again.
This patch is simple. Just forward the value of this flag to the
runtime cmake command.
I'm also removing an unnecessary comment in the compilation of the tool
Differential Revision: https://reviews.llvm.org/D107177
When we're building the runtimes for multiple platform targets, we
create umbrella build targets for each distribution component, but those
targets didn't have any dependencies and were just no-ops. Make the
umbrella target depend on the sub-targets for each platform to fix this,
which is consistent with the behavior of the umbrella targets for each
runtime, and also consistent with the behavior when we've only specified
the default target.
Windows is in the unique position of having two drivers, clang-cl and normal GNU clang, depending on whether a GNU or MSVC target is used. The current implementation with the USE_TOOLCHAIN argument assumes that when CMAKE_SYSTEM_NAME is set to Windows that clang-cl should be used, which is the incorrect choice when targeting a GNU environment.
This patch solves this problem by adding an optional TARGET_TRIPLE argument to llvm_ExternalProject_Add, which sets the various CMAKE_<LANG>_COMPILER_TARGET variables. Additionally, if the triple is detected as an MSVC environment, clang-cl and similar MSVC specific tools will be used instead of the GNU tools.
Previously, llvm/runtimes/CMakeLists.txt played two different roles:
1. host side which could used to set up the build of runtimes for
different targets in the right order;
2. target side to build the runtimes for the specified target.
This change splits llvm/runtimes/CMakeLists.txt and moves the target
side to runtimes/CMakeLists laying down the foundation for the "A vision
for building the runtimes" proposal. From the user perspective, there
shouldn't be any visible difference at the moment.
Differential Revision: https://reviews.llvm.org/D93408
For now, `*_STANDALONE_BUILD` is set to ON even if they're built along
with LLVM because of issues mentioned in the comments. This can cause some issues.
For example, if we build OpenMP along with LLVM, we'd like to copy those OpenMP
headers to `<prefix>/lib/clang/<version>/include` such that `clang` can find
those headers without using `-I <prefix>/include` because those headers will be
copied to `<prefix>/include` if it is built standalone.
In this patch, we fixed the dependence issue in OpenMP such that it can be built
correctly even with `OPENMP_STANDALONE_BUILD=OFF`. The issue is in the call to
`add_lit_testsuite`, where `clang` and `clang-resource-headers` are passed as
`DEPENDS`. Since we're building OpenMP along with LLVM, `clang` is set by CMake
to be the C/C++ compiler, therefore these two dependences are no longer needed,
where caused the dependence issue.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D93738
This patch added `openmp` to `LLVM_ALL_RUNTIMES` so that when the CMake argument `LLVM_ENABLE_RUNTIMES=all`, OpenMP can also be built.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D94369
Currently when building OpenMP along with LLVM, CMake variables for OpenMP (prefix with `LIBOMP` and `LIBOMPTARGET`) will not be passed through because by default it uses the prefix of the runtime name, aka `OPENMP` in this case. This patch fixed this issue.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D93603
This is a massive revert of the following commits (from most revent to oldest):
2b9b7b5775.
529ac3319728270234f169c2087283b5aa67446e5d796645d6
After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.
These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.
See https://reviews.llvm.org/D89041 for more details on this adventure.
The runtimes build was lying to the various runtimes builds by setting
XXX_STANDALONE_BUILD=ON when they are really not being built standalone.
Only COMPILER_RT_STANDALONE_BUILD appears to be necessary, but setting it
for the other runtimes actually breaks everything.
Differential Revision: https://reviews.llvm.org/D90005
When we call cmake_pop_check_state, we undo any changes to REQUIRED
variables performed by HandleLLVMOptions which is undesirable. Rather
use replacement which is what we've used prior to 8d26760a.
Differential Revision: https://reviews.llvm.org/D88756
This is a partial revert of D62155. Rather than copying libc++ headers
into the build directory to be later overwritten by the final headers,
use -isystem flag to access libc++ headers during CMake checks. This
should address the occasional flake we've seen, especially on Windows
builders where CMake fails to overwrite __config with the final version.
Differential Revision: https://reviews.llvm.org/D88454
https://reviews.llvm.org/D88310 fixed the AIX issue in LLVMExternalProjectUtils,
so we shouldn't need the workaround in the runtimes build anymore. I'm
reverting it because it prevents the target-specific tool selection in
LLVMExternalProjectUtils from taking effect, which we rely on for our
runtimes builds.
Reviewed By: daltenty
Differential Revision: https://reviews.llvm.org/D88627
Since 64-bit XCOFF and the big AR format is not yet supported in some of these tools, this patch avoids additional setup of these tools. This patch is not intended to prevent picking up the LLVM tools if they happen to be available otherwise.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D85329
AIX by default usually folds 32-bit & 64-bit arch libraries into a single
archive, a behaviour we may want for the runtime libraries in the future,
so we don't necessarily want to opt into the multlib layout introduce in
D45604, which is currently the default for runtime builds.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D88169
Configure default value of `LLVM_ENABLE_WARNINGS` in `HandleLLVMOptions.cmake`.
`LLVM_ENABLE_WARNINGS` is documented as ON by default, but `HandleLLVMOptions` assumes the default has been set somewhere else. If it has not been explicitly set, then `HandleLLVMOptions` implicitly uses OFF as a default.
This removes the various `option()` declarations in favor of a single declaration in `HandleLLVMOptions`. This will prevent the unwanted use of `-w` that is mentioned in a couple of the comments.
Reviewed By: DavidTruby, #libunwind, JDevlieghere, compnerd
Differential Revision: https://reviews.llvm.org/D87243
{builtin,runtime}_register_target passes a TOOLCHAIN_TOOLS list, whereas
{builtin,runtime}_default_target does notl. The explicit TOOLCHAIN_TOOLS
list matches what LLVMExternalProjectUtils would have set anyway,
barring some target-specific adjustments, and those target-specific
adjustments seem valuable, so let's drop the explicit TOOLCHAIN_TOOLS
list and let LLVMExternalProjectUtils take care of it.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D86366
We have two ways of using the runtimes build setup to build the
builtins. You can either have an empty LLVM_BUILTIN_TARGETS (or have it
include the "default" target), in which case builtin_default_target is
called to set up the default target, or you can have actual triples in
LLVM_BUILTIN_TARGETS, in which case builtin_register_target is called
for each triple. builtin_default_target lets you build the builtins for
Darwin (assuming your default triple is Darwin); builtin_register_target
does not.
I don't understand the reason for this distinction. The Darwin builtins
build is special in that a single CMake configure handles building the
builtins for multiple platforms (e.g. macOS, iPhoneSimulator, and iOS)
and architectures (e.g. arm64, armv7, and x86_64). Consequently, if you
specify multiple Darwin triples in LLVM_BUILTIN_TARGETS, expecting each
configure to only build for that particular triple, it won't work.
However, if you specify a *single* x86_64-apple-darwin triple in
LLVM_BUILTIN_TARGETS, that single configure will build the builtins for
all Darwin targets, exactly the same way that the default target would.
The only difference between the configuration for the default target and
the x86_64-apple-darwin triple is that the latter runs the configuration
with `-DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON`, but that makes no
difference for Apple targets (none of the CMake codepaths which have
different behavior based on that variable are run for Apple targets).
I tested this by running two builtins builds on my Mac, one with the
default target and one with the x86_64-apple-darwin19.5.0 target (which
is the default target triple for my clang). The only relevant
CMakeCache.txt difference was the following, and as discussed above, it
has no effect on the actual build for Apple targets:
```
-//Default triple for which compiler-rt runtimes will be built.
-COMPILER_RT_DEFAULT_TARGET_TRIPLE:STRING=x86_64-apple-darwin19.5.0
+//No help, variable specified on the command line.
+COMPILER_RT_DEFAULT_TARGET_ONLY:UNINITIALIZED=ON
```
Furthermore, when I add the `-D` flag to compiler-rt's libtool
invocations, the libraries produced by the two builds are *identical*.
If anything, I would expect builtin_register_target to complain if you
tried specifying a triple for a particular Apple platform triple (e.g.
macosx), since that's the scenario in which it won't work as you want.
The generic darwin triple should be fine though, as best as I can tell.
I'm happy to add the error for specific Apple platform triples, either
in this diff or in a follow-up.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D86313
Since 64-bit XCOFF and the big AR format is not yet supported in some of these tools, this patch avoids additional setup of these tools. This patch is not intended to prevent picking up the LLVM tools if they happen to be available otherwise.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D85329
We were relying on CMAKE_ARGS argument to be passed to subbuild, but
this argument was never properly defined. This patch addresses that.
Differential Revision: https://reviews.llvm.org/D83842
The runtimes build includes libcxx/include/CMakeLists.txt directly instead
of going through the top-level CMake file. This not-very-hygienic inclusion
caused some variables like LIBCXX_BINARY_DIR not to be defined properly,
and the config_site generation logic to fail after landing 53623d4aa7.
This patch works around this issue by defining the missing variables.
However, the proper fix for this would be for the runtimes build to
always go through libc++'s top-level CMakeLists.txt. Doing otherwise
is unsupported.
When building runtimes, the compiler name (e.g. clang, clang-cl) is set based on
`CMAKE_SYSTEM_NAME` passed to `llvm_ExternalProject_Add()` through `CMAKE_ARGS` argument.
This mechanism doesn't work well if the target is Windows host.
`runtime_default_target()`/`builtin_default_target()` doesn't provide a way
to specify `CMAKE_SYSTEM_NAME` and doesn't set it either.
This patch appends variables specified in `RUNTIMES_CMAKE_ARGS`/`BUILTINS_CMAKE_ARGS`
to `CMAKE_ARGS` argument of `llvm_ExternalProject_Add()` in the case of called
from `runtime_default_target()`/`builtin_default_target()` thus in particular
it allows passing CMAKE_SYSTEM_NAME whenever it is required.
Reviewed By: phosek, compnerd, plotfi
Differential Revision: https://reviews.llvm.org/D81877
No need to parse and add the same variables twice if runtimes is being
built for a generic target (i.e. w/o multilib).
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D81574
Currently we passthrough CMake variables based on project prefix,
i.e. LIBCXX_, LIBCXXABI_, LIBUNWIND_ and COMPILER_RT_. However, many
compiler-rt flags start with SANITIZER_ rather than COMPILER_RT, so
passthrough those as well.
Differential Revision: https://reviews.llvm.org/D75773
This will create e.g. a compiler-rt target that'll build compiler-rt for
all configured targets, similar to how the runtimes umbrella target
builds all the runtimes for all configured targets.
Differential Revision: https://reviews.llvm.org/D74458
These don't build on MSVC at the moment, so filter these out altogether
from the list of runtimes and print a warning.
Differential Revision: https://reviews.llvm.org/D73812
Petr Hosek