maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/runtimes/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

657 lines
28 KiB
CMake
Raw Normal View History

[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
# This file handles building LLVM runtime sub-projects.
# Runtimes are different from tools or other drop-in projects because runtimes
# should be built with the LLVM toolchain from the build directory. This file is
# a first step to formalizing runtime build interfaces.
[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-24 01:06:46 +08:00
# Setting CMake minimum required version should be at the very top of the file
# if this is the entry point.
if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
[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-04-22 23:15:05 +08:00
cmake_minimum_required(VERSION 3.13.4)
[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-24 01:06:46 +08:00
project(Runtimes C CXX ASM)
endif()
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
# Find all subdirectories containing CMake projects
file(GLOB entries *)
foreach(entry ${entries})
if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
list(APPEND runtimes ${entry})
endif()
endforeach()
[CMake][runtimes] Support monorepo layout with runtimes build 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
2017-11-28 06:31:11 +08:00
# Side-by-side subprojects layout.
set(LLVM_ALL_RUNTIMES "libcxx;libcxxabi;libunwind;compiler-rt")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build (${LLVM_ALL_RUNTIMES}), or \"all\".")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all" )
set(LLVM_ENABLE_RUNTIMES ${LLVM_ALL_RUNTIMES})
endif()
foreach(proj ${LLVM_ENABLE_RUNTIMES})
set(proj_dir "${CMAKE_CURRENT_SOURCE_DIR}/../../${proj}")
if(IS_DIRECTORY ${proj_dir} AND EXISTS ${proj_dir}/CMakeLists.txt)
list(APPEND runtimes ${proj_dir})
else()
message(FATAL_ERROR "LLVM_ENABLE_RUNTIMES requests ${proj} but directory not found: ${proj_dir}")
endif()
string(TOUPPER "${proj}" canon_name)
STRING(REGEX REPLACE "-" "_" canon_name ${canon_name})
set(LLVM_EXTERNAL_${canon_name}_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../../${proj}")
endforeach()
function(get_compiler_rt_path path)
foreach(entry ${runtimes})
get_filename_component(projName ${entry} NAME)
if("${projName}" MATCHES "compiler-rt")
set(${path} ${entry} PARENT_SCOPE)
return()
endif()
endforeach()
endfunction()
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
# If this file is acting as a top-level CMake invocation, this code path is
# triggered by the external project call for the runtimes target below.
if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
[CMake] Add support for exposing runtime targets 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
2016-08-26 04:49:51 +08:00
function(runtime_register_component name)
set_property(GLOBAL APPEND PROPERTY SUB_COMPONENTS ${name})
endfunction()
[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-04-22 23:15:05 +08:00
cmake_minimum_required(VERSION 3.13.4)
[CMake] Add more runtime configurations. 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
2017-09-01 09:05:59 +08:00
project(Runtimes C CXX ASM)
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
[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 15:34:39 +08:00
find_package(LLVM PATHS "${LLVM_BINARY_DIR}" NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
# Add the root project's CMake modules, and the LLVM build's modules to the
# CMake module path.
list(INSERT CMAKE_MODULE_PATH 0
"${CMAKE_CURRENT_SOURCE_DIR}/../cmake"
[CMake][runtimes] Use -nodefaultlibs for the runtimes build 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
2017-04-14 05:29:03 +08:00
"${CMAKE_CURRENT_SOURCE_DIR}/../cmake/modules"
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
)
[CMake] Ensure that compiler-rt is added first This will enable other runtime projects to detect the presence of sanitizer runtimes by referring to the sanitizer targets directly. llvm-svn: 280162
2016-08-31 05:29:21 +08:00
# Some of the runtimes will conditionally use the compiler-rt sanitizers
# to make this work smoothly we ensure that compiler-rt is added first in
# the list of sub-projects. This allows other sub-projects to have checks
# like `if(TARGET asan)` to enable building with asan.
[CMake][runtimes] Support monorepo layout with runtimes build 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
2017-11-28 06:31:11 +08:00
get_compiler_rt_path(compiler_rt_path)
[CMake] Ensure that compiler-rt is added first This will enable other runtime projects to detect the presence of sanitizer runtimes by referring to the sanitizer targets directly. llvm-svn: 280162
2016-08-31 05:29:21 +08:00
if(compiler_rt_path)
list(REMOVE_ITEM runtimes ${compiler_rt_path})
[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-23 07:31:39 +08:00
if(NOT DEFINED LLVM_BUILD_COMPILER_RT OR LLVM_BUILD_COMPILER_RT)
[CMake][runtimes] Support for building target variants 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
2017-08-17 03:13:45 +08:00
list(INSERT runtimes 0 ${compiler_rt_path})
endif()
[CMake] Ensure that compiler-rt is added first This will enable other runtime projects to detect the presence of sanitizer runtimes by referring to the sanitizer targets directly. llvm-svn: 280162
2016-08-31 05:29:21 +08:00
endif()
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
# Setting these variables will allow the sub-build to put their outputs into
# the library and bin directories of the top-level build.
set(LLVM_LIBRARY_OUTPUT_INTDIR ${LLVM_LIBRARY_DIR})
Hooking up a check-all target for the runtimes projects llvm-svn: 279756
2016-08-26 01:18:41 +08:00
set(LLVM_RUNTIME_OUTPUT_INTDIR ${LLVM_TOOLS_BINARY_DIR})
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
[CMake] Fixing lit for runtimes directory 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
2016-09-15 14:14:13 +08:00
# This variable makes sure that e.g. llvm-lit is found.
set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR})
[CMake] Don't set <PROJECT>_STANDALONE_BUILD We shouldn't be treating runtimes builds as standalone builds since we have enough of the context loaded into the runtimes environment. Differential Revision: https://reviews.llvm.org/D57992 llvm-svn: 353601
2019-02-09 11:06:56 +08:00
set(LLVM_CMAKE_PATH ${LLVM_MAIN_SRC_DIR}/cmake/modules)
[CMake] Fixing lit for runtimes directory 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
2016-09-15 14:14:13 +08:00
[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 09:24:31 +08:00
# This variable is used by individual runtimes to locate LLVM files.
set(LLVM_PATH ${LLVM_BUILD_MAIN_SRC_DIR})
[CMake] Support single target builtins build on Darwin 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
2017-03-24 10:21:11 +08:00
if(APPLE)
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
set(LLVM_ENABLE_LIBCXX ON CACHE BOOL "")
[CMake] Support single target builtins build on Darwin 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
2017-03-24 10:21:11 +08:00
endif()
[CMake][runtimes] Use -nodefaultlibs for the runtimes build 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
2017-04-14 05:29:03 +08:00
include(CheckLibraryExists)
include(CheckCCompilerFlag)
[CMake] Don't override required compiler flags in the runtimes build Ensure that HandleLLVMOptions adds all necessary required flags, including -Wno-error when building with LLVM_ENABLE_WERROR enabled. Differential Revision: https://reviews.llvm.org/D58092 llvm-svn: 353790
2019-02-12 10:11:25 +08:00
# We don't have libc++ (yet).
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -nostdlib++")
[CMake][runtimes] Use -nodefaultlibs for the runtimes build 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
2017-04-14 05:29:03 +08:00
[CMake][runtimes] Process common options in runtimes build This was removed in D39932 but turned out this is actually needed because runtimes such as compiler-rt and libc++ rely on common options processing for setting certain flags such as -ffunction-sections and -fdata-sections. Differential Revision: https://reviews.llvm.org/D45507 llvm-svn: 329778
2018-04-11 13:18:03 +08:00
# Avoid checking whether the compiler is working.
set(LLVM_COMPILER_CHECKED ON)
[build] Remove a stray comment. NFC The CMake change associated with this comment was removed but the comment got left behind. Add a newline instead. llvm-svn: 353793
2019-02-12 10:25:27 +08:00
[CMake][runtimes] Process common options in runtimes build This was removed in D39932 but turned out this is actually needed because runtimes such as compiler-rt and libc++ rely on common options processing for setting certain flags such as -ffunction-sections and -fdata-sections. Differential Revision: https://reviews.llvm.org/D45507 llvm-svn: 329778
2018-04-11 13:18:03 +08:00
# Handle common options used by all runtimes.
include(AddLLVM)
include(HandleLLVMOptions)
[CMake] Don't set <PROJECT>_STANDALONE_BUILD We shouldn't be treating runtimes builds as standalone builds since we have enough of the context loaded into the runtimes environment. Differential Revision: https://reviews.llvm.org/D57992 llvm-svn: 353601
2019-02-09 11:06:56 +08:00
include(FindPythonInterp)
[CMake][runtimes] Process common options in runtimes build This was removed in D39932 but turned out this is actually needed because runtimes such as compiler-rt and libc++ rely on common options processing for setting certain flags such as -ffunction-sections and -fdata-sections. Differential Revision: https://reviews.llvm.org/D45507 llvm-svn: 329778
2018-04-11 13:18:03 +08:00
[CMake] Don't override required compiler flags in the runtimes build Ensure that HandleLLVMOptions adds all necessary required flags, including -Wno-error when building with LLVM_ENABLE_WERROR enabled. Differential Revision: https://reviews.llvm.org/D58092 llvm-svn: 353790
2019-02-12 10:11:25 +08:00
# Remove the -nostdlib++ option we've added earlier.
string(REPLACE "-nostdlib++" "" CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS}")
[CMake][runtimes] Use -nodefaultlibs for the runtimes build 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
2017-04-14 05:29:03 +08:00
[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 10:05:01 +08:00
# Use libtool instead of ar if you are both on an Apple host, and targeting Apple.
if(CMAKE_HOST_APPLE AND APPLE)
include(UseLibtool)
endif()
[CMake] Don't set <PROJECT>_STANDALONE_BUILD We shouldn't be treating runtimes builds as standalone builds since we have enough of the context loaded into the runtimes environment. Differential Revision: https://reviews.llvm.org/D57992 llvm-svn: 353601
2019-02-09 11:06:56 +08:00
# This can be used to detect whether we're in the runtimes build.
set(RUNTIMES_BUILD ON)
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
foreach(entry ${runtimes})
get_filename_component(projName ${entry} NAME)
# TODO: Clean this up as part of an interface standardization
string(REPLACE "-" "_" canon_name ${projName})
string(TOUPPER ${canon_name} canon_name)
[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-30 02:37:49 +08:00
# The subdirectories need to treat this as standalone builds. D57992 tried
# to get rid of this, but the runtimes treat *_STANDALONE_BUILD=OFF as if
# llvm & clang are configured in the same CMake, and setup dependencies
# against their targets.
set(${canon_name}_STANDALONE_BUILD ON)
[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-23 05:08:33 +08:00
if(LLVM_RUNTIMES_LIBDIR_SUBDIR)
set(${canon_name}_LIBDIR_SUBDIR "${LLVM_RUNTIMES_LIBDIR_SUBDIR}" CACHE STRING "" FORCE)
[CMake] Set per-runtime library directory suffix in runtimes build Do not use LLVM_RUNTIMES_LIBDIR_SUFFIX variable which is an internal variable used by the runtimes build from individual runtimes, instead set per-runtime librarhy directory suffix variable which is necessary for the sanitized runtimes build to install libraries into correct location. Differential Revision: https://reviews.llvm.org/D49121 llvm-svn: 336713
2018-07-11 03:13:33 +08:00
endif()
[CMake] Add variables for tracking which runtimes are included This allows sub-projects to have conditionals based on the presence of other projects. llvm-svn: 279172
2016-08-19 06:18:11 +08:00
# Setting a variable to let sub-projects detect which other projects
# will be included under here.
[CMake] Don't set <PROJECT>_STANDALONE_BUILD We shouldn't be treating runtimes builds as standalone builds since we have enough of the context loaded into the runtimes environment. Differential Revision: https://reviews.llvm.org/D57992 llvm-svn: 353601
2019-02-09 11:06:56 +08:00
set(HAVE_${canon_name} ON)
[CMake] Set HAVE_${runtime} before including any subdirectories This should allow us to avoid most order dependence in the runtime library configurations. llvm-svn: 290834
2017-01-03 04:33:33 +08:00
endforeach()
[CMake] Add variables for tracking which runtimes are included This allows sub-projects to have conditionals based on the presence of other projects. llvm-svn: 279172
2016-08-19 06:18:11 +08:00
[CMake] Set HAVE_${runtime} before including any subdirectories This should allow us to avoid most order dependence in the runtime library configurations. llvm-svn: 290834
2017-01-03 04:33:33 +08:00
# We do this in two loops so that HAVE_* is set for each runtime before the
# other runtimes are added.
foreach(entry ${runtimes})
get_filename_component(projName ${entry} NAME)
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
Hooking up a check-all target for the runtimes projects llvm-svn: 279756
2016-08-26 01:18:41 +08:00
# Between each sub-project we want to cache and clear the LIT properties
set_property(GLOBAL PROPERTY LLVM_LIT_TESTSUITES)
set_property(GLOBAL PROPERTY LLVM_LIT_PARAMS)
set_property(GLOBAL PROPERTY LLVM_LIT_DEPENDS)
set_property(GLOBAL PROPERTY LLVM_LIT_EXTRA_ARGS)
[CMake][runtimes] Support monorepo layout with runtimes build 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
2017-11-28 06:31:11 +08:00
add_subdirectory(${entry} ${projName})
Hooking up a check-all target for the runtimes projects llvm-svn: 279756
2016-08-26 01:18:41 +08:00
get_property(LLVM_LIT_TESTSUITES GLOBAL PROPERTY LLVM_LIT_TESTSUITES)
get_property(LLVM_LIT_PARAMS GLOBAL PROPERTY LLVM_LIT_PARAMS)
get_property(LLVM_LIT_DEPENDS GLOBAL PROPERTY LLVM_LIT_DEPENDS)
get_property(LLVM_LIT_EXTRA_ARGS GLOBAL PROPERTY LLVM_LIT_EXTRA_ARGS)
list(APPEND RUNTIMES_LIT_TESTSUITES ${LLVM_LIT_TESTSUITES})
list(APPEND RUNTIMES_LIT_PARAMS ${LLVM_LIT_PARAMS})
list(APPEND RUNTIMES_LIT_DEPENDS ${LLVM_LIT_DEPENDS})
list(APPEND RUNTIMES_LIT_EXTRA_ARGS ${LLVM_LIT_EXTRA_ARGS})
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
endforeach()
[CMake] Add support for exposing runtime targets 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
2016-08-26 04:49:51 +08:00
if(LLVM_INCLUDE_TESTS)
# Add a global check rule now that all subdirectories have been traversed
# and we know the total set of lit testsuites.
[CMake]Use LLVM_LIBRARY_DIR for lib path. 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
2017-07-14 08:35:21 +08:00
[CMake] Add support for exposing runtime targets 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
2016-08-26 04:49:51 +08:00
add_lit_target(check-runtimes
"Running all regression tests"
${RUNTIMES_LIT_TESTSUITES}
PARAMS ${RUNTIMES_LIT_PARAMS}
DEPENDS ${RUNTIMES_LIT_DEPENDS}
ARGS ${RUNTIMES_LIT_EXTRA_ARGS}
)
[CMake] Fixing LLVM_INCLUDE_TESTS for runtimes directory 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
2016-08-27 04:08:57 +08:00
add_custom_target(runtimes-test-depends DEPENDS ${RUNTIMES_LIT_DEPENDS})
[CMake] Add support for exposing runtime targets 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
2016-08-26 04:49:51 +08:00
endif()
get_property(SUB_COMPONENTS GLOBAL PROPERTY SUB_COMPONENTS)
[CMake] Only generate Components.cmake if components are specified 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
2016-08-27 08:19:51 +08:00
if(SUB_COMPONENTS)
list(REMOVE_DUPLICATES SUB_COMPONENTS)
foreach(component ${SUB_COMPONENTS})
if(NOT TARGET ${component})
message(SEND_ERROR "Missing target for runtime component ${component}!")
continue()
endif()
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
if(TARGET check-${component})
list(APPEND SUB_CHECK_TARGETS check-${component})
[CMake] Only generate Components.cmake if components are specified 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
2016-08-27 08:19:51 +08:00
endif()
if(TARGET install-${component})
list(APPEND SUB_INSTALL_TARGETS install-${component})
endif()
[runtimes] Add install-*-stripped targets These should be the only remaining missing install-*-stripped targets. They're modeled after the existing install targets. Differential Revision: https://reviews.llvm.org/D40927 llvm-svn: 320182
2017-12-09 03:42:46 +08:00
if(TARGET install-${component}-stripped)
list(APPEND SUB_INSTALL_TARGETS install-${component}-stripped)
endif()
[CMake] Only generate Components.cmake if components are specified 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
2016-08-27 08:19:51 +08:00
endforeach()
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
if(LLVM_RUNTIMES_TARGET)
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/Components.cmake.in
${LLVM_BINARY_DIR}/runtimes/${LLVM_RUNTIMES_TARGET}/Components.cmake)
else()
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/Components.cmake.in
${LLVM_BINARY_DIR}/runtimes/Components.cmake)
endif()
[CMake] Only generate Components.cmake if components are specified 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
2016-08-27 08:19:51 +08:00
endif()
Hooking up a check-all target for the runtimes projects llvm-svn: 279756
2016-08-26 01:18:41 +08:00
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
else() # if this is included from LLVM's CMake
include(LLVMExternalProjectUtils)
[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-24 02:51:52 +08:00
if (LLVM_EXTERNAL_LIBCXX_SOURCE_DIR AND "libcxx" IN_LIST LLVM_ENABLE_RUNTIMES)
[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-25 00:21:38 +08:00
# This looks wrong, but libcxx's build actually wants the header dir to be
# the root build dir, not the include directory.
[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 53623d4aa710. 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 13:23:43 +08:00
set(LIBCXX_BINARY_DIR ${LLVM_BINARY_DIR})
set(LIBCXX_SOURCE_DIR ${LLVM_EXTERNAL_LIBCXX_SOURCE_DIR})
[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-25 00:21:38 +08:00
set(LIBCXX_HEADER_DIR ${LLVM_BINARY_DIR})
[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-24 01:06:46 +08:00
set(CXX_HEADER_TARGET runtime-libcxx-headers)
add_subdirectory(${LLVM_EXTERNAL_LIBCXX_SOURCE_DIR}/include ${CXX_HEADER_TARGET})
endif()
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
[CMake] Provide an option to disable runtimes build 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
2017-03-24 06:40:10 +08:00
if(NOT LLVM_BUILD_RUNTIMES)
set(EXTRA_ARGS EXCLUDE_FROM_ALL)
endif()
[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-21 03:18:15 +08:00
function(check_apple_target triple builtin_or_runtime)
set(error "\
compiler-rt for Darwin builds for all platforms and architectures using a \
single configuration. Specify only a single darwin triple (e.g. x86_64-apple-darwin) \
in your targets list (and not a triple for a specific platform such as macos). \
You can use variables such as COMPILER_RT_ENABLE_IOS and DARWIN_ios_ARCHS to \
control the specific platforms and architectures to build.")
set(seen_property ${builtin_or_runtime}_darwin_triple_seen)
string(REPLACE "-" ";" triple_components ${triple})
foreach(component ${triple_components})
string(TOLOWER "${component}" component_lower)
if(component_lower MATCHES "^darwin")
get_property(darwin_triple_seen GLOBAL PROPERTY ${seen_property})
if(darwin_triple_seen)
message(FATAL_ERROR "${error}")
endif()
set_property(GLOBAL PROPERTY ${seen_property} YES)
if(NOT RUNTIMES_BUILD_ALLOW_DARWIN)
message(FATAL_ERROR "\
${error} Set RUNTIMES_BUILD_ALLOW_DARWIN to allow a single darwin triple.")
endif()
elseif(component_lower MATCHES "^ios|^macos|^tvos|^watchos")
message(FATAL_ERROR "${error}")
endif()
endforeach()
endfunction()
[CMake][runtimes] Support monorepo layout with runtimes build 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
2017-11-28 06:31:11 +08:00
function(builtin_default_target compiler_rt_path)
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
cmake_parse_arguments(ARG "" "" "DEPENDS" ${ARGN})
[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-05 04:44:40 +08:00
set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default ON)
# AIX should fold 32-bit & 64-bit arch libraries into a single archive.
if (TARGET_TRIPLE MATCHES "aix")
set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default OFF)
endif()
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
llvm_ExternalProject_Add(builtins
[CMake][runtimes] Support monorepo layout with runtimes build 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
2017-11-28 06:31:11 +08:00
${compiler_rt_path}/lib/builtins
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
DEPENDS ${ARG_DEPENDS}
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
CMAKE_ARGS -DLLVM_LIBRARY_OUTPUT_INTDIR=${LLVM_LIBRARY_DIR}
-DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_TOOLS_BINARY_DIR}
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
-DLLVM_DEFAULT_TARGET_TRIPLE=${TARGET_TRIPLE}
[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-05 04:44:40 +08:00
-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=${LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default}
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
-DCMAKE_C_COMPILER_TARGET=${TARGET_TRIPLE}
-DCMAKE_ASM_COMPILER_TARGET=${TARGET_TRIPLE}
[CMake][runtimes] Set compiler as working even for default target 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
2017-11-15 07:47:20 +08:00
-DCMAKE_C_COMPILER_WORKS=ON
-DCMAKE_ASM_COMPILER_WORKS=ON
[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-15 18:05:13 +08:00
${BUILTINS_CMAKE_ARGS}
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
PASSTHROUGH_PREFIXES COMPILER_RT
USE_TOOLCHAIN
${EXTRA_ARGS})
endfunction()
[CMake][runtimes] Support monorepo layout with runtimes build 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
2017-11-28 06:31:11 +08:00
function(builtin_register_target compiler_rt_path target)
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
cmake_parse_arguments(ARG "" "" "DEPENDS" ${ARGN})
[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-21 03:18:15 +08:00
check_apple_target(${target} builtin)
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
get_cmake_property(variableNames VARIABLES)
foreach(variableName ${variableNames})
[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-23 07:31:39 +08:00
string(FIND "${variableName}" "BUILTINS_${target}" out)
if("${out}" EQUAL 0)
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
string(REPLACE "BUILTINS_${target}_" "" new_name ${variableName})
[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 09:04:21 +08:00
string(REPLACE ";" "|" new_value "${${variableName}}")
list(APPEND ${target}_extra_args "-D${new_name}=${new_value}")
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
endif()
endforeach()
llvm_ExternalProject_Add(builtins-${target}
[CMake][runtimes] Support monorepo layout with runtimes build 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
2017-11-28 06:31:11 +08:00
${compiler_rt_path}/lib/builtins
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
DEPENDS ${ARG_DEPENDS}
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
CMAKE_ARGS -DLLVM_LIBRARY_OUTPUT_INTDIR=${LLVM_LIBRARY_DIR}
-DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_TOOLS_BINARY_DIR}
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
-DLLVM_DEFAULT_TARGET_TRIPLE=${target}
-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
-DCMAKE_C_COMPILER_TARGET=${target}
-DCMAKE_ASM_COMPILER_TARGET=${target}
[CMake][runtimes] Set compiler as working even for default target 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
2017-11-15 07:47:20 +08:00
-DCMAKE_C_COMPILER_WORKS=ON
-DCMAKE_ASM_COMPILER_WORKS=ON
-DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
${${target}_extra_args}
USE_TOOLCHAIN
${EXTRA_ARGS})
endfunction()
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
# If compiler-rt is present we need to build the builtin libraries first. This
# is required because the other runtimes need the builtin libraries present
# before the just-built compiler can pass the configuration tests.
[CMake][runtimes] Support monorepo layout with runtimes build 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
2017-11-28 06:31:11 +08:00
get_compiler_rt_path(compiler_rt_path)
if(compiler_rt_path)
[CMake] Support single target builtins build on Darwin 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
2017-03-24 10:21:11 +08:00
if(NOT LLVM_BUILTIN_TARGETS)
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
builtin_default_target(${compiler_rt_path}
[build] Rename clang-headers to clang-resource-headers Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 llvm-svn: 355340
2019-03-05 05:19:53 +08:00
DEPENDS clang-resource-headers)
[CMake] Multi-target builtins build 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
2016-12-13 07:15:10 +08:00
else()
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
if("default" IN_LIST LLVM_BUILTIN_TARGETS)
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
builtin_default_target(${compiler_rt_path}
[build] Rename clang-headers to clang-resource-headers Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 llvm-svn: 355340
2019-03-05 05:19:53 +08:00
DEPENDS clang-resource-headers)
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
list(REMOVE_ITEM LLVM_BUILTIN_TARGETS "default")
else()
add_custom_target(builtins)
add_custom_target(install-builtins)
[runtimes] Add install-*-stripped targets These should be the only remaining missing install-*-stripped targets. They're modeled after the existing install targets. Differential Revision: https://reviews.llvm.org/D40927 llvm-svn: 320182
2017-12-09 03:42:46 +08:00
add_custom_target(install-builtins-stripped)
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
endif()
[CMake] Multi-target builtins build 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
2016-12-13 07:15:10 +08:00
foreach(target ${LLVM_BUILTIN_TARGETS})
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
builtin_register_target(${compiler_rt_path} ${target}
[build] Rename clang-headers to clang-resource-headers Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 llvm-svn: 355340
2019-03-05 05:19:53 +08:00
DEPENDS clang-resource-headers)
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
[CMake] Multi-target builtins build 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
2016-12-13 07:15:10 +08:00
add_dependencies(builtins builtins-${target})
[CMake][runtimes] Add install target for runtimes builtins 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
2017-06-03 03:38:11 +08:00
add_dependencies(install-builtins install-builtins-${target})
[runtimes] Add install-*-stripped targets These should be the only remaining missing install-*-stripped targets. They're modeled after the existing install targets. Differential Revision: https://reviews.llvm.org/D40927 llvm-svn: 320182
2017-12-09 03:42:46 +08:00
add_dependencies(install-builtins-stripped install-builtins-${target}-stripped)
[CMake] Multi-target builtins build 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
2016-12-13 07:15:10 +08:00
endforeach()
endif()
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
set(deps builtins)
[CMake] Make the runtimes directory work with bootstrap builds 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
2016-10-20 05:50:25 +08:00
# We don't need to depend on the builtins if we're building instrumented
# because the next stage will use the same compiler used to build this stage.
if(NOT LLVM_BUILD_INSTRUMENTED AND CLANG_ENABLE_BOOTSTRAP)
add_dependencies(clang-bootstrap-deps builtins)
endif()
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
endif()
# We create a list the names of all the runtime projects in all uppercase and
# with dashes turned to underscores. This gives us the CMake variable prefixes
# for all variables that will apply to runtimes.
foreach(entry ${runtimes})
get_filename_component(projName ${entry} NAME)
string(REPLACE "-" "_" canon_name ${projName})
string(TOUPPER ${canon_name} canon_name)
list(APPEND prefixes ${canon_name})
[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-07 06:38:07 +08:00
# Many compiler-rt options start with SANITIZER_ rather than COMPILER_RT_,
# so when compiler-rt is enabled, consider both.
if(canon_name STREQUAL "COMPILER_RT")
list(APPEND prefixes SANITIZER)
endif()
[CMake] Create convenience targets for runtime projects 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
2016-08-19 05:47:18 +08:00
string(FIND ${projName} "lib" LIB_IDX)
if(LIB_IDX EQUAL 0)
string(SUBSTRING ${projName} 3 -1 projName)
endif()
list(APPEND runtime_names ${projName})
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
endforeach()
[CMake] Support stripping and linking output to .build-id directory When installing runtimes with install-runtimes-stripped, we don't want to just strip them, we also want to preserve the debugging information for potential debugging. To make it possible to later find the stripped debugging information, we want to use the .build-id layout: https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID That is, for libfoo.so with build ID abcdef1234, the debugging information will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy already has support for stripping files and linking the debugging stripped output into the right location. However, CMake doesn't support customizing strip invocation for the *-stripped targets. So instead, we replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with the right command line flags. Differential Revision: https://reviews.llvm.org/D59127 llvm-svn: 355765
2019-03-09 09:26:55 +08:00
if(LLVM_RUNTIME_BUILD_ID_LINK_TARGETS)
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/llvm-strip-link.in
${CMAKE_CURRENT_BINARY_DIR}/llvm-strip-link
@ONLY
)
endif()
[CMake][runtimes] Use cmake_parse_arguments in runtimes functions 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
2017-11-17 05:28:54 +08:00
function(runtime_default_target)
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
cmake_parse_arguments(ARG "" "" "DEPENDS;PREFIXES" ${ARGN})
[CMake][runtimes] Use cmake_parse_arguments in runtimes functions 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
2017-11-17 05:28:54 +08:00
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
include(${LLVM_BINARY_DIR}/runtimes/Components.cmake OPTIONAL)
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 08:25:57 +08:00
set(SUB_CHECK_TARGETS ${SUB_CHECK_TARGETS} PARENT_SCOPE)
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${LLVM_BINARY_DIR}/runtimes/Components.cmake)
foreach(runtime_name ${runtime_names})
list(APPEND extra_targets
${runtime_name}
[runtimes] Add install-*-stripped targets These should be the only remaining missing install-*-stripped targets. They're modeled after the existing install targets. Differential Revision: https://reviews.llvm.org/D40927 llvm-svn: 320182
2017-12-09 03:42:46 +08:00
install-${runtime_name}
install-${runtime_name}-stripped)
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
if(LLVM_INCLUDE_TESTS)
list(APPEND test_targets check-${runtime_name})
endif()
endforeach()
[CMake] Support runtimes in distributions Summary: This patch adds a new internal variable LLVM_RUNTIME_DISTRIBUTION_COMPONENTS which specifies distribution components that are part of runtime projects, and thus should be exposed from runtime configuraitons up into the top-level CMake configurations. This is required for allowing runtime components to be included in LLVM_DISTRIBUTION_COMPONENTS because we verify that the build and install targets exist for every component specified for the distribution. Without this patch runtimes and builtins can only be included in distributions in whole, not by component. Reviewers: phosek Reviewed By: phosek Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46705 llvm-svn: 332631
2018-05-18 00:58:44 +08:00
foreach(component ${LLVM_RUNTIME_DISTRIBUTION_COMPONENTS})
if(NOT ${component} IN_LIST SUB_COMPONENTS)
list(APPEND extra_targets ${component} install-${component} install-${component}-stripped)
endif()
endforeach()
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
if(LLVM_INCLUDE_TESTS)
list(APPEND test_targets runtimes-test-depends check-runtimes)
endif()
[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-05 04:44:40 +08:00
set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default ON)
# AIX should fold 32-bit & 64-bit arch libraries into a single archive.
if (TARGET_TRIPLE MATCHES "aix")
set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default OFF)
endif()
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
llvm_ExternalProject_Add(runtimes
${CMAKE_CURRENT_SOURCE_DIR}
[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-25 00:21:38 +08:00
DEPENDS ${ARG_DEPENDS} ${CXX_HEADER_TARGET}
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
# Builtins were built separately above
CMAKE_ARGS -DCOMPILER_RT_BUILD_BUILTINS=Off
-DLLVM_INCLUDE_TESTS=${LLVM_INCLUDE_TESTS}
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
-DLLVM_DEFAULT_TARGET_TRIPLE=${TARGET_TRIPLE}
[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 09:34:51 +08:00
-DLLVM_ENABLE_PROJECTS_USED=${LLVM_ENABLE_PROJECTS_USED}
[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-05 04:44:40 +08:00
-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=${LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default}
[CMake] Support for cross-compilation when build runtimes When cross-compiling, we cannot use the just built toolchain, instead we need to use the host toolchain which we assume has a support for targeting the selected target platform. We also need to pass the path to the native version of llvm-config to external projects. Differential Revision: https://reviews.llvm.org/D41678 llvm-svn: 322046
2018-01-09 07:50:59 +08:00
-DCMAKE_C_COMPILER_TARGET=${TARGET_TRIPLE}
-DCMAKE_CXX_COMPILER_TARGET=${TARGET_TRIPLE}
-DCMAKE_ASM_COMPILER_TARGET=${TARGET_TRIPLE}
[CMake][runtimes] Set compiler as working even for default target 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
2017-11-15 07:47:20 +08:00
-DCMAKE_C_COMPILER_WORKS=ON
-DCMAKE_CXX_COMPILER_WORKS=ON
-DCMAKE_ASM_COMPILER_WORKS=ON
[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-15 18:05:13 +08:00
${RUNTIMES_CMAKE_ARGS}
[CMake][runtimes] Support monorepo layout with runtimes build 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
2017-11-28 06:31:11 +08:00
PASSTHROUGH_PREFIXES LLVM_ENABLE_RUNTIMES
${ARG_PREFIXES}
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
EXTRA_TARGETS ${extra_targets}
${test_targets}
${SUB_COMPONENTS}
${SUB_CHECK_TARGETS}
${SUB_INSTALL_TARGETS}
USE_TOOLCHAIN
${EXTRA_ARGS})
endfunction()
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
# runtime_register_target(target)
# Utility function to register external runtime target.
[CMake][runtimes] Use cmake_parse_arguments in runtimes functions 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
2017-11-17 05:28:54 +08:00
function(runtime_register_target name target)
[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 10:24:22 +08:00
cmake_parse_arguments(ARG "" "" "DEPENDS;CMAKE_ARGS" ${ARGN})
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
include(${LLVM_BINARY_DIR}/runtimes/${name}/Components.cmake OPTIONAL)
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${LLVM_BINARY_DIR}/runtimes/${name}/Components.cmake)
[CMake][runtimes] Support for building target variants 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
2017-08-17 03:13:45 +08:00
[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-21 03:18:15 +08:00
check_apple_target(${target} runtime)
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
set(${name}_deps ${ARG_DEPENDS})
[CMake][runtimes] Support for building target variants 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
2017-08-17 03:13:45 +08:00
if(NOT name STREQUAL target)
list(APPEND ${name}_deps runtimes-${target})
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
endif()
Hooking up a check-all target for the runtimes projects llvm-svn: 279756
2016-08-26 01:18:41 +08:00
foreach(runtime_name ${runtime_names})
[CMake] Use variables rather than ":" delimiters This is a more idiomatic CMake. Differential Revision: https://reviews.llvm.org/D37644 llvm-svn: 335703
2018-06-27 11:14:41 +08:00
set(${runtime_name}-${name} ${runtime_name})
set(install-${runtime_name}-${name} install-${runtime_name})
set(install-${runtime_name}-${name}-stripped install-${runtime_name}-stripped)
list(APPEND ${name}_extra_targets ${runtime_name}-${name} install-${runtime_name}-${name} install-${runtime_name}-${name}-stripped)
[CMake] Dependencies for tests in "runtimes" 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
2017-07-11 03:23:28 +08:00
if(LLVM_INCLUDE_TESTS)
[CMake] Use variables rather than ":" delimiters This is a more idiomatic CMake. Differential Revision: https://reviews.llvm.org/D37644 llvm-svn: 335703
2018-06-27 11:14:41 +08:00
set(check-${runtime_name}-${name} check-${runtime_name} )
list(APPEND ${name}_test_targets check-${runtime_name}-${name})
[CMake] Dependencies for tests in "runtimes" 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
2017-07-11 03:23:28 +08:00
endif()
Hooking up a check-all target for the runtimes projects llvm-svn: 279756
2016-08-26 01:18:41 +08:00
endforeach()
[CMake][runtimes] Use target specific name for all runtimes targets 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
2017-09-02 10:28:03 +08:00
foreach(target_name IN LISTS SUB_COMPONENTS SUB_INSTALL_TARGETS)
[CMake] Use variables rather than ":" delimiters This is a more idiomatic CMake. Differential Revision: https://reviews.llvm.org/D37644 llvm-svn: 335703
2018-06-27 11:14:41 +08:00
set(${target_name}-${name} ${target_name})
list(APPEND ${name}_extra_targets ${target_name}-${name})
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
endforeach()
[CMake] Support runtimes in distributions Summary: This patch adds a new internal variable LLVM_RUNTIME_DISTRIBUTION_COMPONENTS which specifies distribution components that are part of runtime projects, and thus should be exposed from runtime configuraitons up into the top-level CMake configurations. This is required for allowing runtime components to be included in LLVM_DISTRIBUTION_COMPONENTS because we verify that the build and install targets exist for every component specified for the distribution. Without this patch runtimes and builtins can only be included in distributions in whole, not by component. Reviewers: phosek Reviewed By: phosek Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46705 llvm-svn: 332631
2018-05-18 00:58:44 +08:00
foreach(component ${LLVM_RUNTIME_DISTRIBUTION_COMPONENTS})
[CMake] Use variables rather than ":" delimiters This is a follow up to D37644, this block was missed in that change. Differential Revision: https://reviews.llvm.org/D58093 llvm-svn: 354194
2019-02-16 11:57:35 +08:00
set(${component}-${name} ${component})
[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-23 14:16:28 +08:00
set(install-${component}-${name} install-${component})
[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-23 14:28:14 +08:00
set(install-${component}-${name}-stripped install-${component}-stripped)
list(APPEND ${name}_extra_targets ${component}-${name} install-${component}-${name} install-${component}-${name}-stripped)
[CMake] Support runtimes in distributions Summary: This patch adds a new internal variable LLVM_RUNTIME_DISTRIBUTION_COMPONENTS which specifies distribution components that are part of runtime projects, and thus should be exposed from runtime configuraitons up into the top-level CMake configurations. This is required for allowing runtime components to be included in LLVM_DISTRIBUTION_COMPONENTS because we verify that the build and install targets exist for every component specified for the distribution. Without this patch runtimes and builtins can only be included in distributions in whole, not by component. Reviewers: phosek Reviewed By: phosek Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46705 llvm-svn: 332631
2018-05-18 00:58:44 +08:00
endforeach()
[CMake] Fixing LLVM_INCLUDE_TESTS for runtimes directory 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
2016-08-27 04:08:57 +08:00
if(LLVM_INCLUDE_TESTS)
[CMake] Use variables rather than ":" delimiters This is a more idiomatic CMake. Differential Revision: https://reviews.llvm.org/D37644 llvm-svn: 335703
2018-06-27 11:14:41 +08:00
set(runtimes-test-depends-${name} runtimes-test-depends)
set(check-runtimes-${name} check-runtimes)
list(APPEND ${name}_test_targets runtimes-test-depends-${name} check-runtimes-${name})
[CMake][runtimes] Support for building target variants 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
2017-08-17 03:13:45 +08:00
foreach(target_name IN LISTS SUB_CHECK_TARGETS)
[CMake] Use variables rather than ":" delimiters This is a more idiomatic CMake. Differential Revision: https://reviews.llvm.org/D37644 llvm-svn: 335703
2018-06-27 11:14:41 +08:00
set(${target_name}-${name} ${target_name})
list(APPEND ${name}_test_targets ${target_name}-${name})
list(APPEND test_targets ${target_name}-${name})
[CMake] Expose runtime component check targets 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
2016-08-27 04:34:11 +08:00
endforeach()
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
set(test_targets "${test_targets}" PARENT_SCOPE)
[CMake] Fixing LLVM_INCLUDE_TESTS for runtimes directory 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
2016-08-27 04:08:57 +08:00
endif()
[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 10:24:22 +08:00
set(${name}_extra_args ${ARG_CMAKE_ARGS})
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
get_cmake_property(variableNames VARIABLES)
foreach(variableName ${variableNames})
[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-18 07:16:34 +08:00
string(FIND "${variableName}" "RUNTIMES_${target}_" out)
[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-23 07:31:39 +08:00
if("${out}" EQUAL 0)
[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-18 07:16:34 +08:00
string(REPLACE "RUNTIMES_${target}_" "" new_name ${variableName})
[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 09:04:21 +08:00
string(REPLACE ";" "|" new_value "${${variableName}}")
list(APPEND ${name}_extra_args "-D${new_name}=${new_value}")
[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-23 07:31:39 +08:00
endif()
[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-18 07:16:34 +08:00
endforeach()
[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-10 22:18:30 +08:00
if(NOT "${name}" STREQUAL "${target}")
foreach(variableName ${variableNames})
string(FIND "${variableName}" "RUNTIMES_${name}_" out)
if("${out}" EQUAL 0)
string(REPLACE "RUNTIMES_${name}_" "" new_name ${variableName})
string(REPLACE ";" "|" new_value "${${variableName}}")
list(APPEND ${name}_extra_args "-D${new_name}=${new_value}")
endif()
endforeach()
endif()
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
[build] Fix LLVM_ENABLE_RUNTIMES override condition I forgot to add parentheses in fa44d72b9e43, though I prefer the expanded form anyway.
2020-01-30 05:40:36 +08:00
if(NOT RUNTIMES_${name}_LLVM_ENABLE_RUNTIMES AND NOT RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES)
[build] Fix runtimes build after 2e745ba6b0ba 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-30 04:16:40 +08:00
string(REPLACE ";" "|" LLVM_ENABLE_RUNTIMES_PASSTHROUGH "${LLVM_ENABLE_RUNTIMES}")
list(APPEND ${name}_extra_args -DLLVM_ENABLE_RUNTIMES=${LLVM_ENABLE_RUNTIMES_PASSTHROUGH})
endif()
[CMake] Support stripping and linking output to .build-id directory When installing runtimes with install-runtimes-stripped, we don't want to just strip them, we also want to preserve the debugging information for potential debugging. To make it possible to later find the stripped debugging information, we want to use the .build-id layout: https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID That is, for libfoo.so with build ID abcdef1234, the debugging information will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy already has support for stripping files and linking the debugging stripped output into the right location. However, CMake doesn't support customizing strip invocation for the *-stripped targets. So instead, we replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with the right command line flags. Differential Revision: https://reviews.llvm.org/D59127 llvm-svn: 355765
2019-03-09 09:26:55 +08:00
if(target IN_LIST LLVM_RUNTIME_BUILD_ID_LINK_TARGETS)
list(APPEND EXTRA_ARGS STRIP_TOOL ${CMAKE_CURRENT_BINARY_DIR}/llvm-strip-link)
endif()
[CMake][runtimes] Support for building target variants 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
2017-08-17 03:13:45 +08:00
llvm_ExternalProject_Add(runtimes-${name}
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
${CMAKE_CURRENT_SOURCE_DIR}
[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-25 00:21:38 +08:00
DEPENDS ${${name}_deps} ${CXX_HEADER_TARGET}
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
# Builtins were built separately above
CMAKE_ARGS -DCOMPILER_RT_BUILD_BUILTINS=Off
[CMake] Fixing LLVM_INCLUDE_TESTS for runtimes directory 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
2016-08-27 04:08:57 +08:00
-DLLVM_INCLUDE_TESTS=${LLVM_INCLUDE_TESTS}
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
-DLLVM_DEFAULT_TARGET_TRIPLE=${target}
[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 09:34:51 +08:00
-DLLVM_ENABLE_PROJECTS_USED=${LLVM_ENABLE_PROJECTS_USED}
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
-DCMAKE_C_COMPILER_TARGET=${target}
-DCMAKE_CXX_COMPILER_TARGET=${target}
-DCMAKE_ASM_COMPILER_TARGET=${target}
-DCMAKE_C_COMPILER_WORKS=ON
-DCMAKE_CXX_COMPILER_WORKS=ON
-DCMAKE_ASM_COMPILER_WORKS=ON
-DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
-DLLVM_RUNTIMES_TARGET=${name}
[CMake][runtimes] Support for building target variants 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
2017-08-17 03:13:45 +08:00
${${name}_extra_args}
EXTRA_TARGETS ${${name}_extra_targets}
${${name}_test_targets}
[CMake] Provide an option to disable runtimes build 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
2017-03-24 06:40:10 +08:00
USE_TOOLCHAIN
${EXTRA_ARGS})
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
endfunction()
if(runtimes)
# Create a runtimes target that uses this file as its top-level CMake file.
# The runtimes target is a configuration of all the runtime libraries
# together in a single CMake invocaiton.
if(NOT LLVM_RUNTIME_TARGETS)
[CMake][runtimes] Use cmake_parse_arguments in runtimes functions 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
2017-11-17 05:28:54 +08:00
runtime_default_target(
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
DEPENDS ${deps}
PREFIXES ${prefixes})
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 08:25:57 +08:00
set(test_targets check-runtimes)
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
else()
if("default" IN_LIST LLVM_RUNTIME_TARGETS)
[CMake][runtimes] Use cmake_parse_arguments in runtimes functions 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
2017-11-17 05:28:54 +08:00
runtime_default_target(
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
DEPENDS ${deps}
[CMake][runtimes] Use cmake_parse_arguments in runtimes functions 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
2017-11-17 05:28:54 +08:00
PREFIXES ${prefixes})
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
list(REMOVE_ITEM LLVM_RUNTIME_TARGETS "default")
else()
add_custom_target(runtimes)
add_custom_target(runtimes-configure)
add_custom_target(install-runtimes)
[runtimes] Add install-*-stripped targets These should be the only remaining missing install-*-stripped targets. They're modeled after the existing install targets. Differential Revision: https://reviews.llvm.org/D40927 llvm-svn: 320182
2017-12-09 03:42:46 +08:00
add_custom_target(install-runtimes-stripped)
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
if(LLVM_INCLUDE_TESTS)
[CMake][runtimes] Use the same configuration for non-target and "default" target 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
2017-09-09 06:26:50 +08:00
add_custom_target(check-runtimes)
add_custom_target(runtimes-test-depends)
set(test_targets "")
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
endif()
[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 10:24:57 +08:00
foreach(runtime_name ${runtime_names})
add_custom_target(${runtime_name})
add_custom_target(install-${runtime_name})
add_custom_target(install-${runtime_name}-stripped)
endforeach()
[CMake] Support runtimes in distributions Summary: This patch adds a new internal variable LLVM_RUNTIME_DISTRIBUTION_COMPONENTS which specifies distribution components that are part of runtime projects, and thus should be exposed from runtime configuraitons up into the top-level CMake configurations. This is required for allowing runtime components to be included in LLVM_DISTRIBUTION_COMPONENTS because we verify that the build and install targets exist for every component specified for the distribution. Without this patch runtimes and builtins can only be included in distributions in whole, not by component. Reviewers: phosek Reviewed By: phosek Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46705 llvm-svn: 332631
2018-05-18 00:58:44 +08:00
if(LLVM_RUNTIME_DISTRIBUTION_COMPONENTS)
foreach(component ${LLVM_RUNTIME_DISTRIBUTION_COMPONENTS})
add_custom_target(${component})
add_custom_target(install-${component})
[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-23 14:28:14 +08:00
add_custom_target(install-${component}-stripped)
[CMake] Support runtimes in distributions Summary: This patch adds a new internal variable LLVM_RUNTIME_DISTRIBUTION_COMPONENTS which specifies distribution components that are part of runtime projects, and thus should be exposed from runtime configuraitons up into the top-level CMake configurations. This is required for allowing runtime components to be included in LLVM_DISTRIBUTION_COMPONENTS because we verify that the build and install targets exist for every component specified for the distribution. Without this patch runtimes and builtins can only be included in distributions in whole, not by component. Reviewers: phosek Reviewed By: phosek Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46705 llvm-svn: 332631
2018-05-18 00:58:44 +08:00
endforeach()
endif()
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
endif()
[CMake][runtimes] Support for building target variants 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
2017-08-17 03:13:45 +08:00
foreach(name ${LLVM_RUNTIME_TARGETS})
[CMake] Provide direct support for building sanitized runtimes This avoids having to rely on magic separators and special parsing. Differential Revision: https://reviews.llvm.org/D48061 llvm-svn: 335704
2018-06-27 11:35:53 +08:00
runtime_register_target(${name} ${name}
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
DEPENDS ${deps})
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
[CMake][runtimes] Support for building target variants 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
2017-08-17 03:13:45 +08:00
add_dependencies(runtimes runtimes-${name})
add_dependencies(runtimes-configure runtimes-${name}-configure)
add_dependencies(install-runtimes install-runtimes-${name})
[runtimes] Add install-*-stripped targets These should be the only remaining missing install-*-stripped targets. They're modeled after the existing install targets. Differential Revision: https://reviews.llvm.org/D40927 llvm-svn: 320182
2017-12-09 03:42:46 +08:00
add_dependencies(install-runtimes-stripped install-runtimes-${name}-stripped)
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
if(LLVM_INCLUDE_TESTS)
[CMake][runtimes] Support for building target variants 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
2017-08-17 03:13:45 +08:00
add_dependencies(check-runtimes check-runtimes-${name})
add_dependencies(runtimes-test-depends runtimes-test-depends-${name})
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
endif()
[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 10:24:57 +08:00
foreach(runtime_name ${runtime_names})
add_dependencies(${runtime_name} ${runtime_name}-${name})
add_dependencies(install-${runtime_name} install-${runtime_name}-${name})
add_dependencies(install-${runtime_name}-stripped install-${runtime_name}-${name}-stripped)
endforeach()
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
endforeach()
[CMake] Provide direct support for building sanitized runtimes This avoids having to rely on magic separators and special parsing. Differential Revision: https://reviews.llvm.org/D48061 llvm-svn: 335704
2018-06-27 11:35:53 +08:00
[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-23 07:31:39 +08:00
foreach(multilib ${LLVM_RUNTIME_MULTILIBS})
foreach(name ${LLVM_RUNTIME_MULTILIB_${multilib}_TARGETS})
runtime_register_target(${name}+${multilib} ${name}
[CMake][runtimes] Set clang-header dependency for builtins compiler-rt builtins depend on clang headers, but that dependency wasn't explicitly stated in the build system and we were relying on the transitive depenendecy via clang. However, when we're cross-compiling clang, we'll be using host compiler instead and that depenendecy is missing, breaking the build. Differential Revision: https://reviews.llvm.org/D58471 llvm-svn: 354524
2019-02-21 07:06:10 +08:00
DEPENDS runtimes-${name}
[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-23 07:31:39 +08:00
CMAKE_ARGS -DLLVM_RUNTIMES_PREFIX=${name}/
[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-23 05:08:33 +08:00
-DLLVM_RUNTIMES_LIBDIR_SUBDIR=${multilib})
[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-23 07:31:39 +08:00
add_dependencies(runtimes runtimes-${name}+${multilib})
add_dependencies(runtimes-configure runtimes-${name}+${multilib}-configure)
add_dependencies(install-runtimes install-runtimes-${name}+${multilib})
add_dependencies(install-runtimes-stripped install-runtimes-${name}+${multilib}-stripped)
[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 10:24:57 +08:00
foreach(runtime_name ${runtime_names})
add_dependencies(${runtime_name} ${runtime_name}-${name}+${multilib})
add_dependencies(install-${runtime_name} install-${runtime_name}-${name}+${multilib})
add_dependencies(install-${runtime_name}-stripped install-${runtime_name}-${name}+${multilib}-stripped)
endforeach()
[CMake] Provide direct support for building sanitized runtimes This avoids having to rely on magic separators and special parsing. Differential Revision: https://reviews.llvm.org/D48061 llvm-svn: 335704
2018-06-27 11:35:53 +08:00
endforeach()
endforeach()
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
endif()
[CMake] Make the runtimes directory work with bootstrap builds 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
2016-10-20 05:50:25 +08:00
if(NOT LLVM_BUILD_INSTRUMENTED AND CLANG_ENABLE_BOOTSTRAP)
[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-17 08:08:07 +08:00
# TODO: This is a hack needed because the libcxx headers are copied into the
# build directory during configuration. Without that step the clang in the
# build directory cannot find the C++ headers in certain configurations.
# I need to build a mechanism for runtime projects to provide CMake code
# that executes at LLVM configuration time to handle this case.
[CMake] Make the runtimes directory work with bootstrap builds 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
2016-10-20 05:50:25 +08:00
add_dependencies(clang-bootstrap-deps runtimes-configure)
[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-17 08:08:07 +08:00
# We need to add the runtimes as a dependency because compiler-rt can be
# built as part of runtimes and we need the profile runtime for PGO
add_dependencies(clang-bootstrap-deps runtimes)
[CMake] Make the runtimes directory work with bootstrap builds 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
2016-10-20 05:50:25 +08:00
endif()
[CMake] Fixing LLVM_INCLUDE_TESTS for runtimes directory 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
2016-08-27 04:08:57 +08:00
if(LLVM_INCLUDE_TESTS)
[CMake] Connecting check-all and test-depends targets correctly 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
2016-09-02 02:26:01 +08:00
set_property(GLOBAL APPEND PROPERTY LLVM_ADDITIONAL_TEST_DEPENDS runtimes-test-depends)
set_property(GLOBAL APPEND PROPERTY LLVM_ADDITIONAL_TEST_TARGETS check-runtimes)
[CMake] Dependencies for tests in "runtimes" 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
2017-07-11 03:23:28 +08:00
set(RUNTIMES_TEST_DEPENDS
FileCheck
count
llvm-nm
llvm-objdump
llvm-xray
not
obj2yaml
sancov
sanstats
[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-23 05:42:06 +08:00
gtest_main
gtest
[CMake] Dependencies for tests in "runtimes" 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
2017-07-11 03:23:28 +08:00
)
[CMake] Support multi-target runtimes build 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
2017-07-12 07:41:15 +08:00
foreach(target ${test_targets} ${SUB_CHECK_TARGETS})
[CMake] Dependencies for tests in "runtimes" 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
2017-07-11 03:23:28 +08:00
add_dependencies(${target} ${RUNTIMES_TEST_DEPENDS})
endforeach()
[CMake] Fixing LLVM_INCLUDE_TESTS for runtimes directory 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
2016-08-27 04:08:57 +08:00
endif()
[CMake] Add LLVM runtimes directory 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
2016-06-24 06:07:21 +08:00
endif()
endif()