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
When building the default builtin and runtimes target, set the
CMAKE_SYSTEM_NAME to the current one. This is not necessary on
Linux and Darwin, but it appears to be necessary on Windows,
otherwise CMake fails.
Differential Revision: https://reviews.llvm.org/D73811
I missed the NOT in the condition; this part is actually responsible for
passing LLVM_ENABLE_RUNTIMES to the per-target runtime configures, which
in turn makes them actually build.
I'll put up a more general solution for review, but restore this in the
meantime to fix the runtimes build.
We have to replace the ";" with "|" (since LLVMExternalProjectUtils uses
"|" as the `LIST_SEPARATOR` when invoking `ExternalProject_Add`) in
order for lists to be passed correctly to the runtimes CMake configures.
Remove the special case for `LLVM_ENABLE_RUNTIMES`, since it'll just get
handled by the general logic now.
Differential Revision: https://reviews.llvm.org/D73512
The installation target we create should trigger the corresponding
installation target in the runtimes external project.
Differential Revision: https://reviews.llvm.org/D73251
Runtimes variables in a multi-target environment are defined like:
RUNTIMES_target_VARIABLE_NAME
RUNTIMES_target+multi_VARIABLE_NAME
In my case, I have a downstream runtimes cache that does the following:
set(RUNTIMES_${target}+except_LIBCXXABI_ENABLE_EXCEPTIONS ON CACHE BOOL "")
set(RUNTIMES_${target}_LIBCXX_ENABLE_EXCEPTIONS OFF CACHE BOOL "")
I found that I was always getting the 'target' variable value (OFF) in
my 'target+except' build, which was unexpected. This behavior was
caused by the loop in llvm/runtimes/CMakeLists.txt that runs through all
variable names, adding '-DVARIABLE_NAME=' options to the subsequent
external project's cmake command.
The issue is that the loop does a single pass, such that if the 'target'
value appears in the cache after the 'target+except' value, the 'target'
value will take precedence. I suggest in my change here that the more
specific 'target+except' value should take precedence always, without
relying on CMake cache ordering.
Differential Revision: https://reviews.llvm.org/D71570
Patch By: JamesNagurne
Summary: With the new LLVM_ENABLE_RUNTIMES option introduced in https://reviews.llvm.org/D40233, compiler-rt can now be included as a runtime. Since compiler-rt is needed for PGO, runtimes needs to be included as a dependency of clang-bootstrap-deps when building the stage1 compiler.
Reviewers: beanz, phosek, compnerd, smeenai, plotfi, xiaobai
Reviewed By: phosek
Subscribers: smeenai, beanz, phosek, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71430
Summary: Currently, llvm-lipo is not specified as a dependency, but it is needed when building Darwin-x86_64 runtimes, so I'm adding it to the dependencies lists.
Reviewers: alexshap, beanz, phosek, compnerd, smeenai, mtrent, plotfi, xiaobai
Reviewed By: phosek, smeenai
Subscribers: smeenai, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71429
Second attempt: Now with ';' -> '|' replacement.
On some platforms, certain runtimes are not supported. For runtimes builds of
those platforms it would be nice if we could disable certain runtimes (ie
libunwind on Windows).
Differential Revision: https://reviews.llvm.org/D67195
llvm-svn: 372784
On some platforms, certain runtimes are not supported. For runtimes builds of
those platforms it would be nice if we could disable certain runtimes (ie
libunwind on Windows).
Differential Revision: https://reviews.llvm.org/D67195
llvm-svn: 371566
Summary: The default runtimes targets aren't getting their dependencies configured correctly which results in check-runtimes failing when built from a clean build.
Reviewers: phosek, compnerd
Reviewed By: phosek
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63107
llvm-svn: 363015
LLVM CMake build already uses libtool instead of ar when building
for Apple platform and we should be using the same when building
runtimes. To do so, this change extracts the logic for finding
libtool into a separate file and then uses it from both the LLVM
build as well as the LLVM runtimes build.
Differential Revision: https://reviews.llvm.org/D62769
llvm-svn: 362313
CMake always uses absolute file paths in the generated compiler
invocation which results in absolute file paths being embedded in debug
info. This is undesirable when building a toolchain e.g. on bots as the
debug info may embed the bot source checkout path which is meaningless
anywhere else.
This change introduces the LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO which uses
-fdebug-prefix-map (where supported) options to rewrite paths embedded
into debug info with relative ones. Additionally, LLVM_SOURCE_PREFIX can
be used to override the path to source directory with a different one.
Differential Revision: https://reviews.llvm.org/D62622
llvm-svn: 362185
This avoids using llvm-config for inferring various paths within the
runtimes build. We also set LLVM_INCLUDE_DIR variable that's used by
these builds and move assignment of LLVM_BINARY_DIR and LLVM_LIBRARY_DIR
to the same location for consistency.
Differential Revision: https://reviews.llvm.org/D62637
llvm-svn: 362047
Joachim Protze