Commit Graph

110 Commits

Author SHA1 Message Date
Petr Hosek b688c5875d [CMake] Split the target side of runtimes build
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
2021-01-11 23:39:36 -08:00
Shilei Tian 7be3285248 [OpenMP] Not set OPENMP_STANDALONE_BUILD=ON when building OpenMP along with LLVM
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
2021-01-10 16:46:19 -05:00
Shilei Tian 894d2dbf50 [LLVM] Added OpenMP to `LLVM_ALL_RUNTIMES`
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
2021-01-10 16:45:51 -05:00
Shilei Tian 36b0dd8f67 [OpenMP] Fixed the issue that CMake variables for OpenMP were not passed through when building OpenMP with LLVM_ENABLE_RUNTIMES
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
2020-12-20 18:40:12 -05:00
Louis Dionne 48e4b0fd3a [runtimes] Revert the libc++ __config_site change
This is a massive revert of the following commits (from most revent to oldest):

	2b9b7b5775.
	529ac33197
	28270234f1
	69c2087283
	b5aa67446e
	5d796645d6

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.
2020-10-23 09:41:48 -04:00
Louis Dionne 2b9b7b5775 [runtimes] Do not set XXX_STANDALONE_BUILD for libc++/abi/unwind
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
2020-10-23 01:09:23 -04:00
Petr Hosek 64f2855f15 [CMake] Don't use CMakePushCheckState
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
2020-10-02 17:13:34 -07:00
Petr Hosek 8d26760a95 [CMake] Use -isystem flag to access libc++ headers
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
2020-10-01 12:09:27 -07:00
Shoaib Meenai dcb5b6dfbf [runtimes] Remove TOOLCHAIN_TOOLS specialization
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
2020-10-01 09:53:10 -07:00
David Tenty e03dd978d0 [AIX] Try to not use LLVM tools while building runtimes
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
2020-09-25 10:55:24 -04:00
David Tenty 4b8cb665a1 [CMake][AIX] Set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR appropriately for AIX
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
2020-09-24 16:37:25 -04:00
Dave Lee b36bdfe5ca [cmake] Centralize LLVM_ENABLE_WARNINGS option
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
2020-09-21 10:23:17 -07:00
Shoaib Meenai a7d8aabf29 [runtimes] Remove TOOLCHAIN_TOOLS specialization
{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
2020-08-24 13:48:29 -07:00
Shoaib Meenai e2ab5bcf56 [runtimes] Allow LLVM_BUILTIN_TARGETS to include Darwin
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
2020-08-20 18:28:30 -07:00
Hubert Tong 48cd6b8ca5 Revert "[AIX] Try to not use LLVM tools while building runtimes"
This reverts commit 50dd75c8e0.
@phosek reports a build break.
2020-08-10 21:35:49 -04:00
David Tenty 50dd75c8e0 [AIX] Try to not use LLVM tools while building runtimes
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
2020-08-10 16:11:33 -04:00
Louis Dionne afa1afd410 [CMake] Bump CMake minimum version to 3.13.4
This upgrade should be friction-less because we've already been ensuring
that CMake >= 3.13.4 is used.

This is part of the effort discussed on llvm-dev here:

  http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html

Differential Revision: https://reviews.llvm.org/D78648
2020-07-22 14:25:07 -04:00
Petr Hosek 3577317b6d [CMake][runtimes] Pass the CMAKE_ARGS to runtimes build correctly
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
2020-07-15 09:25:18 -07:00
Louis Dionne 05c552ad05 [libc++] Fix the runtimes build after making __config_site mandatory
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.
2020-06-26 01:26:34 -04:00
Kristina Bessonova cd058033b9 [CMake] Fix runtimes build for host Windows (default target)
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
2020-06-20 10:44:22 +02:00
Kristina Bessonova 5a39bf2dc5 [CMake][runtimes] Skip adding 2nd set of the same variables for a generic target
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
2020-06-15 09:59:27 +02:00
Petr Hosek fe30eb6268 [runtimes] When COMPILER_RT is enabled, consider SANITIZER prefixes
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
2020-03-11 14:22:20 -07:00
Shoaib Meenai 26edb21c29 [runtimes] Add umbrella targets for runtimes
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
2020-02-12 09:46:14 -08:00
Vladimir Vereschaka b4aff1210c Revert "[CMake] Filter libc++abi and libunwind from runtimes build in MSVC"
This reverts commit 9986b88e64.

These changes break ARM/Aarch64 cross builders on Windows platform

* http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l
* http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64

suppressing building libc++abi/libunwind by "just built" toolchain.

Differential Revision: https://reviews.llvm.org/D73812
2020-02-07 11:28:21 -08:00
Petr Hosek 8707c246bc Revert "[CMake] Passthrough CMAKE_SYSTEM_NAME to default builtin and runtimes target"
This reverts commit 491a4a7ac9 as it
broke the runtimes build on Darwin.
2020-02-06 08:24:08 -08:00
Petr Hosek 9986b88e64 [CMake] Filter libc++abi and libunwind from runtimes build in MSVC
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
2020-02-05 09:59:06 -08:00
Petr Hosek 491a4a7ac9 [CMake] Passthrough CMAKE_SYSTEM_NAME to default builtin and runtimes target
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
2020-02-04 22:38:20 -08:00
Shoaib Meenai 0423ddfb81 [build] Fix LLVM_ENABLE_RUNTIMES override condition
I forgot to add parentheses in fa44d72b9e, though I prefer the
expanded form anyway.
2020-01-29 13:41:31 -08:00
Shoaib Meenai fa44d72b9e [build] Fix runtimes build after 2e745ba6b0
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.
2020-01-29 12:16:40 -08:00
Shoaib Meenai 2e745ba6b0 [runtimes] Fix passing lists to runtimes configures
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
2020-01-28 14:36:14 -08:00
Shoaib Meenai a308b98ecb [runtimes] Support install-*-stripped targets
This is needed to support including runtime targets in
LLVM_DISTRIBUTION_COMPONENTS.

Differential Revision: https://reviews.llvm.org/D73252
2020-01-27 17:00:24 -08:00
Shoaib Meenai b1da8eba60 [runtimes] Fix installation for LLVM_RUNTIME_DISTRIBUTION_COMPONENTS
The installation target we create should trigger the corresponding
installation target in the runtimes external project.

Differential Revision: https://reviews.llvm.org/D73251
2020-01-27 17:00:18 -08:00
James Nagurne 128e1ebd93 [CMake] Prefer multi-target variables over generic target variables in runtimes build
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
2020-01-17 15:18:18 -08:00
Xin-Xin Wang d6777207b4 [llvm/runtimes] Add runtimes as a dependency of clang-bootstrap-deps
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
2019-12-16 16:58:15 -08:00
Xin-Xin Wang f5bbe387e8 [llvm] Add llvm-lipo dependency to runtimes
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
2019-12-16 16:05:52 -08:00
Puyan Lotfi 819ff64ea0 Adding support for overriding LLVM_ENABLE_RUNTIMES for runtimes builds.
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
2019-09-24 22:38:18 +00:00
Petr Hosek c856eb0b76 Revert "Adding support for overriding LLVM_ENABLE_RUNTIMES for runtimes builds."
This reverts commit r371566: this doesn't correctly handle the case
where LLVM_ENABLE_RUNTIMES contains a list of values.

llvm-svn: 371579
2019-09-11 00:43:35 +00:00
Puyan Lotfi 244e738485 Adding support for overriding LLVM_ENABLE_RUNTIMES for runtimes builds.
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
2019-09-10 22:55:47 +00:00
Chris Bieneman dc2c72eefa Setup testing target dependencies for default runtimes
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
2019-06-11 00:25:57 +00:00
Petr Hosek 84254dd8ab [CMake] Use libtool for runtimes when building for Apple platform
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
2019-06-02 02:05:01 +00:00
Petr Hosek 2ab7af29c6 [CMake] Provide an option to use relative paths in debug info
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
2019-05-31 01:34:51 +00:00
Petr Hosek 433a191683 [CMake] Use find_package(LLVM) instead of LLVMConfig
This addresses an issues introduced in r362047.

Differential Revision: https://reviews.llvm.org/D62640

llvm-svn: 362065
2019-05-30 07:34:39 +00:00
Petr Hosek 7e041d6dac [CMake] Set LLVM_PATH in the runtimes build
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
2019-05-30 01:24:31 +00:00
Chris Bieneman 96c500aab4 [CMake] [Runtimes] Set *_STANDALONE_BUILD
Summary:
The runtimes use `*_STANDALONE_BUILD=OFF` to signify that clang is an in-tree target. This is not the case with the runtime builds, so we really need this set to `ON`.

In order to resolve the issues phosek was having with checks, we should use checks that don't link. We can use compiler-rt's `try_compile_only` as a basis for that.

This patch is *required* to be able to run the runtime libraries check-* targets.

Reviewers: smeenai, phosek, compnerd

Reviewed By: phosek

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D62410

llvm-svn: 362007
2019-05-29 18:37:49 +00:00
Chris Bieneman 07745a131f [CMake] Fix issues building runtimes
This resolves two issues:
(1) LIBCXX_HEADER_DIR is a very misleadingly named variable because it shouldn't be set to the header directory, instead it needs to be the root binary dir.
(2) If you build runtimes without libcxx, we can't depend on the libcxx header target, so we should instaed refer to it by the variable name which will be unset if libcxx isn't present.

llvm-svn: 361646
2019-05-24 16:21:38 +00:00
Chris Bieneman e836096f01 [CMake] Fixing errors in r361513
Summary:
I somehow messed this up. libcxx appends the subdirectories itself, so we don't need to add them here.

Also, r361513 broke the "projects" build of libcxx because it always included the extra targets.

Reviewers: lebedev.ri, mclow.lists

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D62336

llvm-svn: 361535
2019-05-23 18:51:52 +00:00
Chris Bieneman c5ec2a2bc1 [CMake] Copy C++ headers before configuring runtimes build
Summary: On some platforms C++ headers are packaged with the compiler not the sysroot. If you don't copy C++ headers into the build include directory during configuraiton of the outer build the C++ check during the runtime configuration may get inaccurate results.

Reviewers: phosek, compnerd, smeenai, EricWF

Reviewed By: compnerd

Subscribers: EricWF, christof, libcxx-commits, mgorny, llvm-commits

Tags: #llvm, #libc

Differential Revision: https://reviews.llvm.org/D62155

llvm-svn: 361513
2019-05-23 17:06:46 +00:00
Chris Bieneman ed00367961 [Runtimes] If LLVM_INCLUDE_TESTS=On depend on gtest
Summary: If we are building the tests for the runtimes we should make them depend on gtest so that gtest is built and ready before we run any of the check-* targets.

Reviewers: phosek, compnerd

Reviewed By: compnerd

Subscribers: mgorny, winksaville, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D62269

llvm-svn: 361436
2019-05-22 21:42:06 +00:00
Petr Hosek 81f433b48c [runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and include/c++
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/$target/c++ and include/c++ directories, leaving resource directory
only for compiler-rt runtimes and Clang builtin headers.

Differential Revision: https://reviews.llvm.org/D59168

llvm-svn: 361432
2019-05-22 21:08:33 +00:00
Petr Hosek fbcce9fe9d [CMake] Replace the sanitizer support in runtimes build with multilib
This is a more generic solution; while the sanitizer support can be used
only for sanitizer instrumented builds, the multilib support can be used
to build other variants such as noexcept which is what we would like to use
in Fuchsia.

The name CMake target name uses the target name, same as for the regular
runtimes build and the name of the multilib, concatenated with '+'. The
libraries are installed in a subdirectory named after the multilib.

Differential Revision: https://reviews.llvm.org/D60926

llvm-svn: 358935
2019-04-22 23:31:39 +00:00