We introduce a new variable LLVM_ENABLE_RUNTIMES which works
similarly to LLVM_ENABLE_PROJECTS and allows specifying runtimes
that will be enabled in the runtimes build.
Differential Revision: https://reviews.llvm.org/D40233
llvm-svn: 319107
The passthrough is useful for setting up the options for the default
build, but we already have a different mechanism to pass CMake flags
to builds for builtins and runtimes targets so this is not really
needed there. Furthermore, when the flags are set for the default
build, with the prefix passthrough set we have to explicitly override
all options in other targets which can be cumbersome.
Differential Revision: https://reviews.llvm.org/D39988
llvm-svn: 318571
Passing lists to functions in CMake is tricky, any list argument
has to be quoted otherwise it'll be expanded. To avoid this issue,
use cmake_parse_arguments in runtime functions and pass lists using
a keyword argument which eliminates any ambiguity when dealing with
lists.
Differential Revision: https://reviews.llvm.org/D40087
llvm-svn: 318457
This is no longer needed for any of the runtimes build and it breaks
in case we don't have the working compiler yet, e.g. when building
a compiler that uses compiler-rt and libc++ as a default runtime,
because these common options check whether these are available.
Differential Revision: https://reviews.llvm.org/D39932
llvm-svn: 318227
Even when building builtins and runtimes for the default target
we shouldn't assume that the just built compiler is already useable.
When the compiler uses compiler-rt and libc++ as the default runtime
and C++ library, it won't be usable until we finish building runtimes.
Differential Revision: https://reviews.llvm.org/D39715
llvm-svn: 318224
The default host target for builtins and runtimes has special behavior
on some platforms, e.g. on Linux both i386 and x86_64 targets are being
built. Specifying "default" as a target name should lead to the same
behavior, which wasn't the case in the past. This patch unifies the
configuration between the non-target and "default" target to produce the
same behavior by moving the default configuration into a function that
can be used from both paths.
Differential Revision: https://reviews.llvm.org/D37450
llvm-svn: 312831
We need to use target specific name for all runtimes targets. Target
specific name means the name of target in the LLVM build is different
from the name in runtimes build (in LLVM build, it's suffixed by the
target itself). Previously we have only used target specific names for
check targets collected through SUB_CHECK_TARGETS, but that's not
sufficient, we need to use target specific names for all targets we're
exposing in LLVM build.
Fixes PR34335.
Differential Revision: https://reviews.llvm.org/D37245
llvm-svn: 312405
Summary:
- `project` is required when `runtime/CMakeList.txt` is the top-level `CMakeList.txt` file. This will establish version and policy settings.
- `-D_FILE_OFFSET_BITS=64` should never be set for Android runtimes.
Reviewers: srhines, pirama, beanz
Subscribers: llvm-commits, srhines, mgorny
Differential Revision: https://reviews.llvm.org/D35648
llvm-svn: 312302
This can be used to build non-sanitized and sanitized versions of
runtimes, where sanitized versions use the just built sanitizer
which in turn may use the non-sanitized version.
Differential Revision: https://reviews.llvm.org/D36348
llvm-svn: 311036
Summary:
`SUB_CHECK_TARGETS` contains all test targets in `SUB_COMPONENTS` when
we load `Components.cmake`. We don't need to add those targets
again and having duplicate targets will break the cmake policy CMP0002.
Reviewers: phosek
Subscribers: mgorny, llvm-commits, srhines, pirama
Differential Revision: https://reviews.llvm.org/D35692
llvm-svn: 308900
Summary:
This makes sure the correct lib path is being used when `CMAKE_CFG_INTDIR` or
`LLVM_LIBDIR_SUFFIX` is set.
Reviewers: beanz
Subscribers: mgorny, srhines, pirama, llvm-commits
Differential Revision: https://reviews.llvm.org/D35318
llvm-svn: 307985
This changes adds support for building runtimes for multiple
different targets using LLVM runtimes directory.
The implementation follow the model used already by the builtins
build which already supports this option. To specify the runtimes
targets to be built, use the LLVM_RUNTIME_TARGETS variable, where
the valuae is the list of targets to build runtimes for. To pass
a per target variable to the runtimes build, you can set
RUNTIMES_<target>_<variable> where <variable> will be passed to the
runtimes build for <target>.
Each runtime target (except for the default one) will be installed
into lib/<target> subdirectory. Build targets will be suffixed with
the target name.
Differential Revision: https://reviews.llvm.org/D32816
llvm-svn: 307731
Many of the test cases in the runtimes require LLVM's testing tools, to
facilitate this working as expected we need to have all the test targets
in the runtimes depend on all LLVM testing tools used in the runtimes.
Differential Revision: https://reviews.llvm.org/D33048
llvm-svn: 307572
This adds an install-builtins target to avoid having to list all
builtins targets explicitly.
Differential Revision: https://reviews.llvm.org/D32710
llvm-svn: 304587
We may not have a working C++ standard library at this point so we
shouldn't rely on it when running CMake checks.
Differential Revision: https://reviews.llvm.org/D31942
llvm-svn: 300260
This change allows cross-compiling compiler-rt builtins for
multiple targets as part of runtimes on Darwin. This functionality
is already supported on other platforms.
Differential Revision: https://reviews.llvm.org/D30957
llvm-svn: 298678
This could be used to either disable the runtimes build altogether
or avoid building them but still generate the build targets.
Differential Revision: https://reviews.llvm.org/D31060
llvm-svn: 298653
All the existing runtimes relies on flags which are set by AddLLVM
and HandleLLVMOptions. In the standalone case, they would include
these themselves, but when being built using LLVM runtimes we should
include these in the top-level runtimes CMake files.
Differential Revision: https://reviews.llvm.org/D28389
llvm-svn: 291590
This change enables building builtins for multiple different targets
using LLVM runtimes directory.
To specify the builtin targets to be built, use the LLVM_BUILTIN_TARGETS
variable, where the value is the list of targets. To pass a per target
variable to the builtin build, you can set BUILTINS_<target>_<variable>
where <variable> will be passed to the builtin build for <target>.
Differential Revision: https://reviews.llvm.org/D26652
llvm-svn: 289491
This patch builds on clang r284648, and allows the runtime directory to make the bootstrap builds depend on the builtin libraries.
This patch also make the bootstrap build depend on configuring the other runtimes because the libcxx headers are copied during configuration. I have left a TODO in the code to remove that once I come up with a better solution.
llvm-svn: 284650
Copy variable LLVM_BUILD_MAIN_SRC_DIR from LLVMConfig.cmake to
LLVM_MAIN_SRC_DIR as it is named for in-tree builds. This ensures that
add_lit_target() can reliably find llvm-lit which is not necessarily
in the PATH.
Differential Revision: https://reviews.llvm.org/D24503
llvm-svn: 281585
My previous attempt at this connected the sub-project check targets to the test-depends target instead of to the check-all target. That resulted in the tests running multiple times on bots that built "test-depends" and "check-all" in separate build invocations.
llvm-svn: 280392
This allows the builtins archives to build into the correct subdirectory under the binary dir. Addresses the issue discussed in D24001.
llvm-svn: 280002
Generating the Components import file is useless if there are no components coming in from the runtimes configuration, so we should skip generation in that case.
This also should fix the configuration error that Renato reported on llvm-dev.
llvm-svn: 279893
This will expose the check targets for runtime project components into the top-level build. It will enable exposing targets like check-asan.
llvm-svn: 279861
We need to explicitly pass LLVM_INCLUDE_TESTS through from the top-level to the runtimes configuration because it isn't in LLVMConfig.cmake
llvm-svn: 279857
This patch adds support to the runtimes build for exposing sub-project targets through the high-level configuration. This will enable exposing the build, check and install targets for sub-project components (i.e. asan, check-asan, install-asan...).
This patch requires minor changes to the runtime projects to take advantage of it, and I'll phase those changes into Compiler-RT shortly.
llvm-svn: 279776
Each runtime project has a top-level target that is the name of the runtime (minus the "lib" prefix if applicable). This creates top-level targets mapping to runtime projects.
llvm-svn: 279160
The subproject interface being used for runtime libraries expects that llvm-config is passed into the subproject for consumption. We currently do this for every subproject, so we should expect that all LLVM ExternalProjects depend on llvm-config for the time being.
Eventually I'd like to see the sub-projects using LLVMConfig.cmake instead of the llvm-config binary, but that will take time to roll out.
llvm-svn: 279155
Summary:
There are a few LLVM projects that produce runtime libraries. Ideally
runtime libraries should be built differently than other projects,
specifically they should be built using the just-built toolchain.
There is support for building compiler-rt in this way from the clang
build. Moving this logic into the LLVM build is interesting because it
provides a simpler way to extend the just-built toolchain to include
LLD and the LLVM object file tools.
Once this functionality is better fleshed out and tested we’ll want to
encapsulate it in a module that can be used for clang standalone
builds, and we’ll want to make it the default way to build compiler-rt.
With this patch applied there is no immediate change in the build.
Moving compiler-rt out from llvm/projects into llvm/runtimes enables
the functionality.
This code has a few improvements over the method provided by
LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is
always invoked, so changes to compiler-rt source files will get built
properly, so this patch can be used for iterative development with
just-built tools.
This first patch only works with compiler-rt. Support for other
runtime projects will be coming in follow-up patches.
Reviewers: chandlerc, bogner
Subscribers: kubabrecka, llvm-commits
Differential Revision: http://reviews.llvm.org/D20992
llvm-svn: 273620
Petr Hosek