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

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

284 lines
11 KiB
CMake
Raw Normal View History

[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +08:00
# This file handles building LLVM runtime sub-projects.
cmake_minimum_required(VERSION 3.13.4)
Revert "Reapply [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind" This reverts commit 317dc31e53b83c1d2a468d7a541925f0cc7d9dce. After that change, OpenMP doesn't find dependencies in the host system (it fails do find e.g. /usr/lib/x86_64-linux-gnu/libelf.so which it found before), which causes some OpenMP target offloading plugins to not be found. This doesn't break the build, but just causes the AMDGPU OpenMP target plugin to be omitted. See https://reviews.llvm.org/D113253#3181934 for the report of this issue.
2021-12-09 18:54:37 +08:00
project(Runtimes C CXX ASM)
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +08:00
[runtimes] Add the libc project to the list of runtimes. This is possible as the default libc build now works under runtimes build. Differential Revision: https://reviews.llvm.org/D99101
2021-03-23 02:59:49 +08:00
set(LLVM_ALL_RUNTIMES "compiler-rt;libc;libcxx;libcxxabi;libunwind;openmp")
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +08:00
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(runtime_register_component name)
set_property(GLOBAL APPEND PROPERTY SUB_COMPONENTS ${name})
endfunction()
find_package(LLVM PATHS "${LLVM_BINARY_DIR}" NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
find_package(Clang PATHS "${LLVM_BINARY_DIR}" NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
[CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
2022-01-01 15:03:31 +08:00
set(LLVM_COMMON_CMAKE_UTILS "${CMAKE_CURRENT_SOURCE_DIR}/../cmake")
Revert "Reapply [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind" This reverts commit 317dc31e53b83c1d2a468d7a541925f0cc7d9dce. After that change, OpenMP doesn't find dependencies in the host system (it fails do find e.g. /usr/lib/x86_64-linux-gnu/libelf.so which it found before), which causes some OpenMP target offloading plugins to not be found. This doesn't break the build, but just causes the AMDGPU OpenMP target plugin to be omitted. See https://reviews.llvm.org/D113253#3181934 for the report of this issue.
2021-12-09 18:54:37 +08:00
# Add path for custom and the LLVM build's modules to the CMake module path.
list(INSERT CMAKE_MODULE_PATH 0
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
[CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
2022-01-01 15:03:31 +08:00
"${LLVM_COMMON_CMAKE_UTILS}"
"${LLVM_COMMON_CMAKE_UTILS}/Modules"
Revert "Reapply [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind" This reverts commit 317dc31e53b83c1d2a468d7a541925f0cc7d9dce. After that change, OpenMP doesn't find dependencies in the host system (it fails do find e.g. /usr/lib/x86_64-linux-gnu/libelf.so which it found before), which causes some OpenMP target offloading plugins to not be found. This doesn't break the build, but just causes the AMDGPU OpenMP target plugin to be omitted. See https://reviews.llvm.org/D113253#3181934 for the report of this issue.
2021-12-09 18:54:37 +08:00
"${CMAKE_CURRENT_SOURCE_DIR}/../llvm/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/../llvm/cmake/modules"
)
Re-Reland "[benchmarks] Move libcxx's fork of google/benchmark and llvm/utils'" This reverts commit b2fbd45d2395f1f6ef39db72b7156724fc101e40. D114922 fixed the reason of the 2nd revert. This patch also re-applies 39e9f5d3685f3cfca0df072928ad96d973704dff. Differential Revision: https://reviews.llvm.org/D112012
2021-12-08 08:46:55 +08:00
set(LLVM_THIRD_PARTY_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../third-party")
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +08:00
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()
# 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.
get_compiler_rt_path(compiler_rt_path)
if(compiler_rt_path)
list(REMOVE_ITEM runtimes ${compiler_rt_path})
if(NOT DEFINED LLVM_BUILD_COMPILER_RT OR LLVM_BUILD_COMPILER_RT)
list(INSERT runtimes 0 ${compiler_rt_path})
endif()
endif()
Reapply [runtimes] Set more paths when building runtimes standalone These paths are needed when building with per-target runtime directories. (It's possible to fix this by manually setting these when invoking cmake, but one isn't supposed to need to do that.) Also set LLVM_TOOLS_BINARY_DIR while touching this area (as it's also unset in this case) even if it isn't specifically needed by the per-target runtime configuration. Fixed since previous attempt: Don't check if the runtimes directory is the root of the CMake invocation; when the main LLVM CMake build builds runtimes, it does invoke a sub-CMake with this directory as the root too, just as if manually invoking CMake at the runtimes directory. Instead check whether LLVM_TOOLS_BINARY_DIR was set and whether find_package(LLVM) succeeded or not. Differential Revision: https://reviews.llvm.org/D107895
2021-08-11 19:14:31 +08:00
# If building standalone by pointing CMake at this runtimes directory,
# LLVM_BINARY_DIR isn't set, find_package(LLVM) will fail and these
# intermediate paths are unset.
[CMake] Use NOT instead of STREQUAL `<var> STREQUAL ""` fails when `<var>` is unset which can be the case when using runtimes as top-level build. Use `NOT` instead. Differential Revision: https://reviews.llvm.org/D109570
2021-09-10 15:07:07 +08:00
if (NOT LLVM_BINARY_DIR)
Reapply [runtimes] Set more paths when building runtimes standalone These paths are needed when building with per-target runtime directories. (It's possible to fix this by manually setting these when invoking cmake, but one isn't supposed to need to do that.) Also set LLVM_TOOLS_BINARY_DIR while touching this area (as it's also unset in this case) even if it isn't specifically needed by the per-target runtime configuration. Fixed since previous attempt: Don't check if the runtimes directory is the root of the CMake invocation; when the main LLVM CMake build builds runtimes, it does invoke a sub-CMake with this directory as the root too, just as if manually invoking CMake at the runtimes directory. Instead check whether LLVM_TOOLS_BINARY_DIR was set and whether find_package(LLVM) succeeded or not. Differential Revision: https://reviews.llvm.org/D107895
2021-08-11 19:14:31 +08:00
set(LLVM_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
endif()
if (NOT LLVM_FOUND)
set(LLVM_TOOLS_BINARY_DIR ${LLVM_BINARY_DIR}/bin)
set(LLVM_LIBRARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/lib)
endif()
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +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})
set(LLVM_RUNTIME_OUTPUT_INTDIR ${LLVM_TOOLS_BINARY_DIR})
# This variable makes sure that e.g. llvm-lit is found.
[runtimes] Calculate the path to the llvm directory without the LLVM cmake package If building by pointing cmake directly at the llvm-project/runtimes directory, the llvm cmake package files (that provide e.g. LLVM_BUILD_MAIN_SRC_DIR) aren't necessarily available. Instead just use a path relative to the current source dir. Differential Revision: https://reviews.llvm.org/D109717
2021-09-14 03:27:44 +08:00
set(LLVM_MAIN_SRC_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../llvm)
[LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND) Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D107717
2021-09-17 00:27:53 +08:00
set(LLVM_CMAKE_DIR ${LLVM_MAIN_SRC_DIR}/cmake/modules)
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +08:00
# This variable is used by individual runtimes to locate LLVM files.
[runtimes] Calculate the path to the llvm directory without the LLVM cmake package If building by pointing cmake directly at the llvm-project/runtimes directory, the llvm cmake package files (that provide e.g. LLVM_BUILD_MAIN_SRC_DIR) aren't necessarily available. Instead just use a path relative to the current source dir. Differential Revision: https://reviews.llvm.org/D109717
2021-09-14 03:27:44 +08:00
set(LLVM_PATH ${CMAKE_CURRENT_SOURCE_DIR}/../llvm)
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +08:00
include(CheckLibraryExists)
[cmake] Partially deduplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs and llvm We previously had a few varied definitions of this floating around. I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior. My compromise solution is this: - No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt. - Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too. - Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision. In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work. The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as D116521 made clang and LLVM use the common cmake utils. Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D117537
2022-01-22 08:21:19 +08:00
include(LLVMCheckCompilerLinkerFlag)
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +08:00
include(CheckCCompilerFlag)
[runtimes] Check whether -nostdinc++ and -nostdlib++ are supported Don't blindly assume they're supported - GCC doesn't support -nostdlib++. The llvm-project/runtimes directory is supposed to allow building the runtimes standalone from a newly built Clang, and thus should allow building with other compilers too. Differential Revision: https://reviews.llvm.org/D109719
2021-09-14 04:05:23 +08:00
include(CheckCXXCompilerFlag)
Reapply #2 of [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind This does mostly the same as D112126, but for the runtimes cmake files. Most of that is straightforward, but the interdependency between libcxx and libunwind is tricky: Libunwind is built at the same time as libcxx, but libunwind is not installed yet. LIBCXXABI_USE_LLVM_UNWINDER makes libcxx link directly against the just-built libunwind, but the compiler implicit -lunwind isn't found. This patch avoids that by adding --unwindlib=none if supported, if we are going to link explicitly against a newly built unwinder anyway. Since the previous attempt, this no longer uses llvm_enable_language_nolink (and thus doesn't set CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY during the compiler sanity checks). Setting CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY during compiler sanity checks makes cmake not learn about some aspects of the compiler, which can make further find_library or find_package fail. This caused OpenMP to not detect libelf and libffi, disabling some OpenMP target plugins. Instead, require the caller to set CMAKE_{C,CXX}_COMPILER_WORKS=YES when building in a configuration with an incomplete toolchain. Differential Revision: https://reviews.llvm.org/D113253
2021-10-24 06:11:20 +08:00
check_c_compiler_flag("" LLVM_RUNTIMES_LINKING_WORKS)
if (NOT LLVM_RUNTIMES_LINKING_WORKS)
[runtimes] rewrap a comment to 80 columns
2022-02-11 09:56:36 +08:00
# The compiler driver may be implicitly trying to link against libunwind,
# which might not work if libunwind doesn't exist yet. Try to check if
Reapply #2 of [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind This does mostly the same as D112126, but for the runtimes cmake files. Most of that is straightforward, but the interdependency between libcxx and libunwind is tricky: Libunwind is built at the same time as libcxx, but libunwind is not installed yet. LIBCXXABI_USE_LLVM_UNWINDER makes libcxx link directly against the just-built libunwind, but the compiler implicit -lunwind isn't found. This patch avoids that by adding --unwindlib=none if supported, if we are going to link explicitly against a newly built unwinder anyway. Since the previous attempt, this no longer uses llvm_enable_language_nolink (and thus doesn't set CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY during the compiler sanity checks). Setting CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY during compiler sanity checks makes cmake not learn about some aspects of the compiler, which can make further find_library or find_package fail. This caused OpenMP to not detect libelf and libffi, disabling some OpenMP target plugins. Instead, require the caller to set CMAKE_{C,CXX}_COMPILER_WORKS=YES when building in a configuration with an incomplete toolchain. Differential Revision: https://reviews.llvm.org/D113253
2021-10-24 06:11:20 +08:00
# --unwindlib=none is supported, and use that if possible.
# Don't add this if not necessary to fix linking, as it can break using
# e.g. ASAN/TSAN.
[cmake] Partially deduplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs and llvm We previously had a few varied definitions of this floating around. I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior. My compromise solution is this: - No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt. - Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too. - Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision. In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work. The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as D116521 made clang and LLVM use the common cmake utils. Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D117537
2022-01-22 08:21:19 +08:00
llvm_check_compiler_linker_flag(C "--unwindlib=none" LLVM_RUNTIMES_SUPPORT_UNWINDLIB_NONE_FLAG)
Reapply #2 of [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind This does mostly the same as D112126, but for the runtimes cmake files. Most of that is straightforward, but the interdependency between libcxx and libunwind is tricky: Libunwind is built at the same time as libcxx, but libunwind is not installed yet. LIBCXXABI_USE_LLVM_UNWINDER makes libcxx link directly against the just-built libunwind, but the compiler implicit -lunwind isn't found. This patch avoids that by adding --unwindlib=none if supported, if we are going to link explicitly against a newly built unwinder anyway. Since the previous attempt, this no longer uses llvm_enable_language_nolink (and thus doesn't set CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY during the compiler sanity checks). Setting CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY during compiler sanity checks makes cmake not learn about some aspects of the compiler, which can make further find_library or find_package fail. This caused OpenMP to not detect libelf and libffi, disabling some OpenMP target plugins. Instead, require the caller to set CMAKE_{C,CXX}_COMPILER_WORKS=YES when building in a configuration with an incomplete toolchain. Differential Revision: https://reviews.llvm.org/D113253
2021-10-24 06:11:20 +08:00
if (LLVM_RUNTIMES_SUPPORT_UNWINDLIB_NONE_FLAG)
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} --unwindlib=none")
endif()
endif()
[runtimes] Check whether -nostdinc++ and -nostdlib++ are supported Don't blindly assume they're supported - GCC doesn't support -nostdlib++. The llvm-project/runtimes directory is supposed to allow building the runtimes standalone from a newly built Clang, and thus should allow building with other compilers too. Differential Revision: https://reviews.llvm.org/D109719
2021-09-14 04:05:23 +08:00
# Disable use of the installed C++ standard library when building runtimes.
# Check for -nostdlib++ first; if there's no C++ standard library yet,
# all check_cxx_compiler_flag commands will fail until we add -nostdlib++
# (or -nodefaultlibs).
[cmake] Partially deduplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs and llvm We previously had a few varied definitions of this floating around. I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior. My compromise solution is this: - No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt. - Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too. - Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision. In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work. The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as D116521 made clang and LLVM use the common cmake utils. Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D117537
2022-01-22 08:21:19 +08:00
llvm_check_compiler_linker_flag(C "-nostdlib++" LLVM_RUNTIMES_SUPPORT_NOSTDLIBXX_FLAG)
[runtimes] Check whether -nostdinc++ and -nostdlib++ are supported Don't blindly assume they're supported - GCC doesn't support -nostdlib++. The llvm-project/runtimes directory is supposed to allow building the runtimes standalone from a newly built Clang, and thus should allow building with other compilers too. Differential Revision: https://reviews.llvm.org/D109719
2021-09-14 04:05:23 +08:00
if (LLVM_RUNTIMES_SUPPORT_NOSTDLIBXX_FLAG)
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -nostdlib++")
endif()
check_cxx_compiler_flag(-nostdinc++ LLVM_RUNTIMES_SUPPORT_NOSTDINCXX_FLAG)
if (LLVM_RUNTIMES_SUPPORT_NOSTDINCXX_FLAG)
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -nostdinc++")
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +08:00
endif()
# Avoid checking whether the compiler is working.
set(LLVM_COMPILER_CHECKED ON)
# Handle common options used by all runtimes.
include(AddLLVM)
include(HandleLLVMOptions)
[runtimes] Use standalone build only for compiler-rt compiler-rt needs to use standalone build because of the assumptions made by its build, but other runtimes can use non-standalone build. Differential Revision: https://reviews.llvm.org/D97575
2021-02-27 04:52:53 +08:00
find_package(Python3 REQUIRED COMPONENTS Interpreter)
Revert "[runtimes] Use standalone build only for compiler-rt" This reverts commit 4e421b2323b38e94e82ac71e5a4dfd78f6744e87 as this seemed to have broke Python 3 executable detection on some builders.
2021-03-03 08:59:32 +08:00
[libcxxabi/runtimes] Set LLVM_HOST_TRIPLE in runtimes build This allows tests to tell if they're running natively. Those tests are libcxxabi/test/native/arm-linux-eabi. Which were running on Linaro's bots but became unsupported when we switched to the runtimes build. Reviewed By: #libc_abi, phosek Differential Revision: https://reviews.llvm.org/D113663
2021-11-11 20:28:39 +08:00
# Host triple is used by tests to check if they are running natively.
include(GetHostTriple)
get_host_triple(LLVM_HOST_TRIPLE)
set(LLVM_DEFAULT_TARGET_TRIPLE "${LLVM_HOST_TRIPLE}" CACHE STRING
[runtimes] Fix incorrect comment about the purpose of LLVM_DEFAULT_TARGET_TRIPLE 5beec6fb04e7 added LLVM_DEFAULT_TARGET_TRIPLE to the runtimes build with a comment, however I believe that comment had been copied from the LLVM build tree. In the context of the runtimes, LLVM_DEFAULT_TARGET_TRIPLE is used to set what targets we are building for, not the target for which we "generate code". Differential Revision: https://reviews.llvm.org/D114007
2021-11-17 00:43:42 +08:00
"Default target for which the runtimes will be built.")
[runtimes] Initialize LLVM_DEFAULT_TARGET_TRIPLE if not set by the caller Differential Revision: https://reviews.llvm.org/D109716
2021-09-14 03:27:17 +08:00
[libcxx] Add a CI configuration for standalone building in llvm-project/runtimes Generate the llvm-lit script in runtimes/CmakeFiles.txt unless invoked from llvm/runtimes. Differential Revision: https://reviews.llvm.org/D109593
2021-09-10 19:36:13 +08:00
option(LLVM_INCLUDE_TESTS "Generate build targets for the runtimes unit tests." ON)
[runtimes] Use the new "runtimes" build by default and deprecate other builds This commit makes the new "runtimes" build (with <monorepo>/runtimes as the root of the CMake invocation) the default way of building libc++. The other supported way of building libc++ is the "bootstrapping" build, where `<monorepo>/llvm` is used as the root of the CMake invocation. All other ways of building libc++ are deprecated effective immediately. There should be no use-case for building libc++ that isn't supported by one of these two builds, and the two new builds work on all environments and are lightweight. They will also make it possible to greatly simplify the build infrastructure of the runtimes, which is currently way too convoluted. Differential Revision: https://reviews.llvm.org/D111356
2021-10-08 04:19:11 +08:00
option(LLVM_INCLUDE_DOCS "Generate build targets for the runtimes documentation." ON)
option(LLVM_ENABLE_SPHINX "Use Sphinx to generate the runtimes documentation." OFF)
[libcxx] Add a CI configuration for standalone building in llvm-project/runtimes Generate the llvm-lit script in runtimes/CmakeFiles.txt unless invoked from llvm/runtimes. Differential Revision: https://reviews.llvm.org/D109593
2021-09-10 19:36:13 +08:00
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +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()
# This can be used to detect whether we're in the runtimes build.
[CMake] Rename RUNTIMES_BUILD to LLVM_RUNTIMES_BUILD This avoid potential conflict with other internal variables. Differential Revision: https://reviews.llvm.org/D97838
2021-03-03 16:39:50 +08:00
set(LLVM_RUNTIMES_BUILD ON)
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +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)
[runtimes] Use standalone build only for compiler-rt compiler-rt needs to use standalone build because of the assumptions made by its build, but other runtimes can use non-standalone build. Differential Revision: https://reviews.llvm.org/D97575
2021-02-27 04:52:53 +08:00
# TODO: compiler-rt has to use standalone build for now. We tried to remove
# this in D57992 but this broke the build because compiler-rt assumes that
# LLVM and Clang are configured in the same build to set up dependencies. We
# should clean up the compiler-rt build and remove this eventually.
if ("${canon_name}" STREQUAL "COMPILER_RT")
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +08:00
set(${canon_name}_STANDALONE_BUILD ON)
endif()
if(LLVM_RUNTIMES_LIBDIR_SUBDIR)
set(${canon_name}_LIBDIR_SUBDIR "${LLVM_RUNTIMES_LIBDIR_SUBDIR}" CACHE STRING "" FORCE)
endif()
# Setting a variable to let sub-projects detect which other projects
# will be included under here.
set(HAVE_${canon_name} ON)
endforeach()
[runtimes] Make sure LLVM_LIT_ARGS is set before including individual runtimes Otherwise, the individual `check-cxx`, `check-cxxabi` and similar targets will not know about `LLVM_LIT_ARGS`, and we'll end up running lit without any argument. Differential Revision: https://reviews.llvm.org/D112035
2021-10-19 05:54:05 +08:00
if(LLVM_INCLUDE_TESTS)
set(LIT_ARGS_DEFAULT "-sv --show-xfail --show-unsupported")
if (MSVC OR XCODE)
set(LIT_ARGS_DEFAULT "${LIT_ARGS_DEFAULT} --no-progress-bar")
endif()
set(LLVM_LIT_ARGS "${LIT_ARGS_DEFAULT}" CACHE STRING "Default options for lit")
endif()
[llvm-libgcc] initial commit Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function `__GI___backtrace` eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416
2021-08-18 04:23:22 +08:00
# llvm-libgcc incorporates both compiler-rt and libunwind as subprojects with very
# specific flags, which causes clashes when they're independently built too.
if("llvm-libgcc" IN_LIST runtimes)
if("compiler-rt" IN_LIST runtimes OR "compiler-rt" IN_LIST LLVM_ENABLE_PROJECTS)
message(FATAL_ERROR
"Attempting to build both compiler-rt and llvm-libgcc will cause irreconcilable "
"target clashes. Please choose one or the other, but not both.")
endif()
if("libunwind" IN_LIST runtimes)
message(
FATAL_ERROR
"Attempting to build both libunwind and llvm-libgcc will cause irreconcilable "
"target clashes. Please choose one or the other, but not both.")
endif()
endif()
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +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)
# 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)
add_subdirectory(${entry} ${projName})
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})
endforeach()
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.
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}
)
add_custom_target(runtimes-test-depends DEPENDS ${RUNTIMES_LIT_DEPENDS})
[libcxx] Add a CI configuration for standalone building in llvm-project/runtimes Generate the llvm-lit script in runtimes/CmakeFiles.txt unless invoked from llvm/runtimes. Differential Revision: https://reviews.llvm.org/D109593
2021-09-10 19:36:13 +08:00
if (NOT HAVE_LLVM_LIT)
# If built by manually invoking cmake on this directory, we don't have
# llvm-lit. If invoked via llvm/runtimes, the toplevel llvm cmake
# invocation already generated the llvm-lit script.
add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit
${CMAKE_CURRENT_BINARY_DIR}/llvm-lit)
endif()
[CMake] Include runtimes test suites in check-all Prior to this change, we would make check-all depend on check-runtimes which is a target that runs tests in the runtimes build. This means that the runtimes tests are going to run prior to other test suites in check-all, and if one of them fails, we won't run the other test suites at all. To address this issue, we instead collect the list of test suites and their dependencies from the runtimes subbuild, and include them in check-all, so a failure of runtimes test suite doesn't prevent other test suites from being executed. This addresses https://github.com/llvm/llvm-project/issues/54154. Differential Revision: https://reviews.llvm.org/D121276
2022-03-09 16:48:49 +08:00
if(LLVM_RUNTIMES_TARGET)
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/Tests.cmake.in
${LLVM_BINARY_DIR}/runtimes/${LLVM_RUNTIMES_TARGET}/Tests.cmake)
else()
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/Tests.cmake.in
${LLVM_BINARY_DIR}/runtimes/Tests.cmake)
endif()
[CMake] Split the target side of runtimes build Previously, llvm/runtimes/CMakeLists.txt played two different roles: 1. host side which could used to set up the build of runtimes for different targets in the right order; 2. target side to build the runtimes for the specified target. This change splits llvm/runtimes/CMakeLists.txt and moves the target side to runtimes/CMakeLists laying down the foundation for the "A vision for building the runtimes" proposal. From the user perspective, there shouldn't be any visible difference at the moment. Differential Revision: https://reviews.llvm.org/D93408
2020-12-17 02:26:42 +08:00
endif()
get_property(SUB_COMPONENTS GLOBAL PROPERTY SUB_COMPONENTS)
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()
if(TARGET check-${component})
list(APPEND SUB_CHECK_TARGETS check-${component})
endif()
if(TARGET install-${component})
list(APPEND SUB_INSTALL_TARGETS install-${component})
endif()
if(TARGET install-${component}-stripped)
list(APPEND SUB_INSTALL_TARGETS install-${component}-stripped)
endif()
endforeach()
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()
endif()