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.

469 lines
21 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
# TODO: This file assumes the Clang toolchain so it'd be better if it lived in
# Clang, except there already is clang/runtime directory which contains
# similar although simpler functionality. We should figure out how to merge
# the two files.
# TODO: Selecting runtimes should be always performed inside the runtimes
# build, see runtimes/CMakeLists.txt, except that we currently check whether
# compiler-rt is being built to determine whether to first build builtins
# or not so we need that information in this file as well.
[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][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
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] 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(LLVMExternalProjectUtils)
[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] 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
if(NOT LLVM_BUILD_RUNTIMES)
set(EXTRA_ARGS EXCLUDE_FROM_ALL)
endif()
[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
[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(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.")
[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] 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(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}")
[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
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
endforeach()
endfunction()
[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] 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(builtin_default_target compiler_rt_path)
cmake_parse_arguments(ARG "" "" "DEPENDS" ${ARGN})
[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] 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_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)
[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
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
llvm_ExternalProject_Add(builtins
${compiler_rt_path}/lib/builtins
DEPENDS ${ARG_DEPENDS}
CMAKE_ARGS -DLLVM_LIBRARY_OUTPUT_INTDIR=${LLVM_LIBRARY_DIR}
-DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_TOOLS_BINARY_DIR}
-DLLVM_DEFAULT_TARGET_TRIPLE=${TARGET_TRIPLE}
-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=${LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default}
-DCMAKE_C_COMPILER_WORKS=ON
-DCMAKE_ASM_COMPILER_WORKS=ON
${BUILTINS_CMAKE_ARGS}
PASSTHROUGH_PREFIXES COMPILER_RT
USE_TOOLCHAIN
[PR48898][CMake] Support MinGW Toolchain tool sin llvm_ExternalProject_Add Windows is in the unique position of having two drivers, clang-cl and normal GNU clang, depending on whether a GNU or MSVC target is used. The current implementation with the USE_TOOLCHAIN argument assumes that when CMAKE_SYSTEM_NAME is set to Windows that clang-cl should be used, which is the incorrect choice when targeting a GNU environment. This patch solves this problem by adding an optional TARGET_TRIPLE argument to llvm_ExternalProject_Add, which sets the various CMAKE_<LANG>_COMPILER_TARGET variables. Additionally, if the triple is detected as an MSVC environment, clang-cl and similar MSVC specific tools will be used instead of the GNU tools.
2021-03-03 05:44:51 +08:00
TARGET_TRIPLE ${TARGET_TRIPLE}
[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
${EXTRA_ARGS})
endfunction()
[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
[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(builtin_register_target compiler_rt_path target)
cmake_parse_arguments(ARG "" "" "DEPENDS" ${ARGN})
[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] 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
check_apple_target(${target} builtin)
[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
[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
get_cmake_property(variableNames VARIABLES)
foreach(variableName ${variableNames})
string(FIND "${variableName}" "BUILTINS_${target}" out)
if("${out}" EQUAL 0)
string(REPLACE "BUILTINS_${target}_" "" new_name ${variableName})
string(REPLACE ";" "|" new_value "${${variableName}}")
list(APPEND ${target}_extra_args "-D${new_name}=${new_value}")
[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] 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] 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
llvm_ExternalProject_Add(builtins-${target}
${compiler_rt_path}/lib/builtins
DEPENDS ${ARG_DEPENDS}
CMAKE_ARGS -DLLVM_LIBRARY_OUTPUT_INTDIR=${LLVM_LIBRARY_DIR}
-DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_TOOLS_BINARY_DIR}
-DLLVM_DEFAULT_TARGET_TRIPLE=${target}
-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON
-DCMAKE_C_COMPILER_WORKS=ON
-DCMAKE_ASM_COMPILER_WORKS=ON
-DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON
${${target}_extra_args}
USE_TOOLCHAIN
[PR48898][CMake] Support MinGW Toolchain tool sin llvm_ExternalProject_Add Windows is in the unique position of having two drivers, clang-cl and normal GNU clang, depending on whether a GNU or MSVC target is used. The current implementation with the USE_TOOLCHAIN argument assumes that when CMAKE_SYSTEM_NAME is set to Windows that clang-cl should be used, which is the incorrect choice when targeting a GNU environment. This patch solves this problem by adding an optional TARGET_TRIPLE argument to llvm_ExternalProject_Add, which sets the various CMAKE_<LANG>_COMPILER_TARGET variables. Additionally, if the triple is detected as an MSVC environment, clang-cl and similar MSVC specific tools will be used instead of the GNU tools.
2021-03-03 05:44:51 +08:00
TARGET_TRIPLE ${target}
[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
${EXTRA_ARGS})
endfunction()
[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
[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
# 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.
get_compiler_rt_path(compiler_rt_path)
if(compiler_rt_path)
if(NOT LLVM_BUILTIN_TARGETS)
builtin_default_target(${compiler_rt_path}
DEPENDS clang-resource-headers)
else()
if("default" IN_LIST LLVM_BUILTIN_TARGETS)
builtin_default_target(${compiler_rt_path}
DEPENDS clang-resource-headers)
list(REMOVE_ITEM LLVM_BUILTIN_TARGETS "default")
[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
else()
[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
add_custom_target(builtins)
add_custom_target(install-builtins)
add_custom_target(install-builtins-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
endif()
Hooking up a check-all target for the runtimes projects llvm-svn: 279756
2016-08-26 01:18:41 +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
foreach(target ${LLVM_BUILTIN_TARGETS})
builtin_register_target(${compiler_rt_path} ${target}
DEPENDS clang-resource-headers)
[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
[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
add_dependencies(builtins builtins-${target})
add_dependencies(install-builtins install-builtins-${target})
add_dependencies(install-builtins-stripped install-builtins-${target}-stripped)
[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
endforeach()
[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()
set(deps builtins)
# 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()
endif()
[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] 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 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)
[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
if(projName STREQUAL "libc")
# For now, we will use the name "llvmlibc" for the libc project as it is
# not a full libc yet. Also, if we leave it as is, the "lib" prefix gets
# stripped below and the targets endup having the name "c", "check-c" etc.
set(projName "llvmlibc")
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
string(REPLACE "-" "_" canon_name ${projName})
string(TOUPPER ${canon_name} canon_name)
list(APPEND prefixes ${canon_name})
if (${canon_name} STREQUAL "OPENMP")
list(APPEND prefixes "LIBOMP" "LIBOMPTARGET")
endif()
# 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][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
[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
string(FIND ${projName} "lib" LIB_IDX)
if(LIB_IDX EQUAL 0)
string(SUBSTRING ${projName} 3 -1 projName)
endif()
list(APPEND runtime_names ${projName})
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
[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(runtime_default_target)
cmake_parse_arguments(ARG "" "" "DEPENDS;PREFIXES" ${ARGN})
[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] 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(${LLVM_BINARY_DIR}/runtimes/Components.cmake OPTIONAL)
set(SUB_CHECK_TARGETS ${SUB_CHECK_TARGETS} PARENT_SCOPE)
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${LLVM_BINARY_DIR}/runtimes/Components.cmake)
[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] 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(runtime_name ${runtime_names})
list(APPEND extra_targets
${runtime_name}
install-${runtime_name}
install-${runtime_name}-stripped)
if(LLVM_INCLUDE_TESTS)
list(APPEND test_targets check-${runtime_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
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
endforeach()
foreach(component ${LLVM_RUNTIME_DISTRIBUTION_COMPONENTS})
if(NOT ${component} IN_LIST SUB_COMPONENTS)
list(APPEND extra_targets ${component} install-${component} install-${component}-stripped)
[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
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
endforeach()
[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
if(LLVM_INCLUDE_TESTS)
list(APPEND test_targets runtimes-test-depends check-runtimes)
[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
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
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 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] 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
llvm_ExternalProject_Add(runtimes
${CMAKE_CURRENT_SOURCE_DIR}/../../runtimes
DEPENDS ${ARG_DEPENDS}
# Builtins were built separately above
CMAKE_ARGS -DCOMPILER_RT_BUILD_BUILTINS=Off
-DLLVM_INCLUDE_TESTS=${LLVM_INCLUDE_TESTS}
-DLLVM_DEFAULT_TARGET_TRIPLE=${TARGET_TRIPLE}
-DLLVM_ENABLE_PROJECTS_USED=${LLVM_ENABLE_PROJECTS_USED}
-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=${LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default}
-DCMAKE_C_COMPILER_WORKS=ON
-DCMAKE_CXX_COMPILER_WORKS=ON
-DCMAKE_ASM_COMPILER_WORKS=ON
${RUNTIMES_CMAKE_ARGS}
PASSTHROUGH_PREFIXES LLVM_ENABLE_RUNTIMES
${ARG_PREFIXES}
EXTRA_TARGETS ${extra_targets}
${test_targets}
${SUB_COMPONENTS}
${SUB_CHECK_TARGETS}
${SUB_INSTALL_TARGETS}
USE_TOOLCHAIN
[PR48898][CMake] Support MinGW Toolchain tool sin llvm_ExternalProject_Add Windows is in the unique position of having two drivers, clang-cl and normal GNU clang, depending on whether a GNU or MSVC target is used. The current implementation with the USE_TOOLCHAIN argument assumes that when CMAKE_SYSTEM_NAME is set to Windows that clang-cl should be used, which is the incorrect choice when targeting a GNU environment. This patch solves this problem by adding an optional TARGET_TRIPLE argument to llvm_ExternalProject_Add, which sets the various CMAKE_<LANG>_COMPILER_TARGET variables. Additionally, if the triple is detected as an MSVC environment, clang-cl and similar MSVC specific tools will be used instead of the GNU tools.
2021-03-03 05:44:51 +08:00
TARGET_TRIPLE ${TARGET_TRIPLE}
[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
${EXTRA_ARGS})
endfunction()
[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] 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
# runtime_register_target(target)
# Utility function to register external runtime target.
function(runtime_register_target name target)
cmake_parse_arguments(ARG "" "" "DEPENDS;CMAKE_ARGS" ${ARGN})
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] 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] 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
check_apple_target(${target} runtime)
[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] 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(${name}_deps ${ARG_DEPENDS})
if(NOT name STREQUAL target)
list(APPEND ${name}_deps runtimes-${target})
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
[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(runtime_name ${runtime_names})
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)
if(LLVM_INCLUDE_TESTS)
set(check-${runtime_name}-${name} check-${runtime_name} )
list(APPEND ${name}_test_targets check-${runtime_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
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
endforeach()
Hooking up a check-all target for the runtimes projects llvm-svn: 279756
2016-08-26 01:18:41 +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
foreach(target_name IN LISTS SUB_COMPONENTS SUB_INSTALL_TARGETS)
set(${target_name}-${name} ${target_name})
list(APPEND ${name}_extra_targets ${target_name}-${name})
endforeach()
Hooking up a check-all target for the runtimes projects llvm-svn: 279756
2016-08-26 01:18:41 +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
foreach(component ${LLVM_RUNTIME_DISTRIBUTION_COMPONENTS})
set(${component}-${name} ${component})
set(install-${component}-${name} install-${component})
set(install-${component}-${name}-stripped install-${component}-stripped)
list(APPEND ${name}_extra_targets ${component}-${name} install-${component}-${name} install-${component}-${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
[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
if(LLVM_INCLUDE_TESTS)
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})
foreach(target_name IN LISTS SUB_CHECK_TARGETS)
set(${target_name}-${name} ${target_name})
list(APPEND ${name}_test_targets ${target_name}-${name})
list(APPEND test_targets ${target_name}-${name})
[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] 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(test_targets "${test_targets}" PARENT_SCOPE)
endif()
[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
[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(${name}_extra_args ${ARG_CMAKE_ARGS})
get_cmake_property(variableNames VARIABLES)
foreach(variableName ${variableNames})
string(FIND "${variableName}" "RUNTIMES_${target}_" out)
if("${out}" EQUAL 0)
string(REPLACE "RUNTIMES_${target}_" "" new_name ${variableName})
string(REPLACE ";" "|" new_value "${${variableName}}")
list(APPEND ${name}_extra_args "-D${new_name}=${new_value}")
[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] 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
endforeach()
if(NOT "${name}" STREQUAL "${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
foreach(variableName ${variableNames})
[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
string(FIND "${variableName}" "RUNTIMES_${name}_" 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] 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
string(REPLACE "RUNTIMES_${name}_" "" 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] 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()
[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] 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
if(NOT RUNTIMES_${name}_LLVM_ENABLE_RUNTIMES AND NOT RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES)
string(REPLACE ";" "|" LLVM_ENABLE_RUNTIMES_PASSTHROUGH "${LLVM_ENABLE_RUNTIMES}")
list(APPEND ${name}_extra_args -DLLVM_ENABLE_RUNTIMES=${LLVM_ENABLE_RUNTIMES_PASSTHROUGH})
endif()
[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
[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
llvm_ExternalProject_Add(runtimes-${name}
${CMAKE_CURRENT_SOURCE_DIR}/../../runtimes
DEPENDS ${${name}_deps}
# Builtins were built separately above
CMAKE_ARGS -DCOMPILER_RT_BUILD_BUILTINS=Off
-DLLVM_INCLUDE_TESTS=${LLVM_INCLUDE_TESTS}
-DLLVM_DEFAULT_TARGET_TRIPLE=${target}
-DLLVM_ENABLE_PROJECTS_USED=${LLVM_ENABLE_PROJECTS_USED}
-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON
-DCMAKE_C_COMPILER_WORKS=ON
-DCMAKE_CXX_COMPILER_WORKS=ON
-DCMAKE_ASM_COMPILER_WORKS=ON
-DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON
-DLLVM_RUNTIMES_TARGET=${name}
${${name}_extra_args}
EXTRA_TARGETS ${${name}_extra_targets}
${${name}_test_targets}
USE_TOOLCHAIN
[PR48898][CMake] Support MinGW Toolchain tool sin llvm_ExternalProject_Add Windows is in the unique position of having two drivers, clang-cl and normal GNU clang, depending on whether a GNU or MSVC target is used. The current implementation with the USE_TOOLCHAIN argument assumes that when CMAKE_SYSTEM_NAME is set to Windows that clang-cl should be used, which is the incorrect choice when targeting a GNU environment. This patch solves this problem by adding an optional TARGET_TRIPLE argument to llvm_ExternalProject_Add, which sets the various CMAKE_<LANG>_COMPILER_TARGET variables. Additionally, if the triple is detected as an MSVC environment, clang-cl and similar MSVC specific tools will be used instead of the GNU tools.
2021-03-03 05:44:51 +08:00
TARGET_TRIPLE ${target}
[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
${EXTRA_ARGS})
endfunction()
[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
[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
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)
runtime_default_target(
DEPENDS ${deps}
PREFIXES ${prefixes})
set(test_targets check-runtimes)
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}
PREFIXES ${prefixes})
[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
list(REMOVE_ITEM LLVM_RUNTIME_TARGETS "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
else()
[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
add_custom_target(runtimes)
add_custom_target(runtimes-configure)
add_custom_target(install-runtimes)
add_custom_target(install-runtimes-stripped)
if(LLVM_INCLUDE_TESTS)
add_custom_target(check-runtimes)
add_custom_target(runtimes-test-depends)
set(test_targets "")
endif()
foreach(runtime_name ${runtime_names})
add_custom_target(${runtime_name})
add_custom_target(install-${runtime_name})
add_custom_target(install-${runtime_name}-stripped)
endforeach()
if(LLVM_RUNTIME_DISTRIBUTION_COMPONENTS)
foreach(component ${LLVM_RUNTIME_DISTRIBUTION_COMPONENTS})
add_custom_target(${component})
add_custom_target(install-${component})
add_custom_target(install-${component}-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
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] 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()
[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] 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(name ${LLVM_RUNTIME_TARGETS})
runtime_register_target(${name} ${name}
DEPENDS ${deps})
add_dependencies(runtimes runtimes-${name})
add_dependencies(runtimes-configure runtimes-${name}-configure)
add_dependencies(install-runtimes install-runtimes-${name})
add_dependencies(install-runtimes-stripped install-runtimes-${name}-stripped)
if(LLVM_INCLUDE_TESTS)
add_dependencies(check-runtimes check-runtimes-${name})
add_dependencies(runtimes-test-depends runtimes-test-depends-${name})
endif()
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)
[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()
[runtimes] Fix umbrella component targets When we're building the runtimes for multiple platform targets, we create umbrella build targets for each distribution component, but those targets didn't have any dependencies and were just no-ops. Make the umbrella target depend on the sub-targets for each platform to fix this, which is consistent with the behavior of the umbrella targets for each runtime, and also consistent with the behavior when we've only specified the default target.
2021-06-13 10:47:09 +08:00
foreach(component ${LLVM_RUNTIME_DISTRIBUTION_COMPONENTS})
add_dependencies(${component} ${component}-${name})
add_dependencies(install-${component} install-${component}-${name})
add_dependencies(install-${component}-stripped install-${component}-${name}-stripped)
endforeach()
[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
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] 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(multilib ${LLVM_RUNTIME_MULTILIBS})
foreach(name ${LLVM_RUNTIME_MULTILIB_${multilib}_TARGETS})
runtime_register_target(${name}+${multilib} ${name}
DEPENDS runtimes-${name}
CMAKE_ARGS -DLLVM_RUNTIMES_PREFIX=${name}/
-DLLVM_RUNTIMES_LIBDIR_SUBDIR=${multilib})
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)
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)
[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()
[runtimes] Fix umbrella component targets When we're building the runtimes for multiple platform targets, we create umbrella build targets for each distribution component, but those targets didn't have any dependencies and were just no-ops. Make the umbrella target depend on the sub-targets for each platform to fix this, which is consistent with the behavior of the umbrella targets for each runtime, and also consistent with the behavior when we've only specified the default target.
2021-06-13 10:47:09 +08:00
foreach(component ${LLVM_RUNTIME_DISTRIBUTION_COMPONENTS})
add_dependencies(${component} ${component}-${name}+${multilib})
add_dependencies(install-${component} install-${component}-${name}+${multilib})
add_dependencies(install-${component}-stripped install-${component}-${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()
[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
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
[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
if(NOT LLVM_BUILD_INSTRUMENTED AND CLANG_ENABLE_BOOTSTRAP)
# 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.
add_dependencies(clang-bootstrap-deps runtimes-configure)
# 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)
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
[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
if(LLVM_INCLUDE_TESTS)
set_property(GLOBAL APPEND PROPERTY LLVM_ADDITIONAL_TEST_DEPENDS runtimes-test-depends)
set_property(GLOBAL APPEND PROPERTY LLVM_ADDITIONAL_TEST_TARGETS check-runtimes)
set(RUNTIMES_TEST_DEPENDS
FileCheck
count
llvm-nm
llvm-objdump
llvm-xray
not
obj2yaml
sancov
sanstats
gtest_main
gtest
)
foreach(target ${test_targets} ${SUB_CHECK_TARGETS})
add_dependencies(${target} ${RUNTIMES_TEST_DEPENDS})
endforeach()
[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()