maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/compiler-rt/cmake/Modules/CompilerRTUtils.cmake

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

601 lines
23 KiB
CMake
Raw Normal View History

[CMake] Adding some missing CMake includes. NFC. This happens to be working now because the includes exist in another CMake file that is included before this one. That will change with upcoming refactoring. llvm-svn: 267912
2016-04-29 02:22:01 +08:00
include(CMakePushCheckState)
include(CheckSymbolExists)
CMake: create AddCompilerRT module and implement convenience add_compiler_rt_object_library function llvm-svn: 172826
2013-01-19 00:05:21 +08:00
# Because compiler-rt spends a lot of time setting up custom compile flags,
# define a handy helper function for it. The compile flags setting in CMake
# has serious issues that make its syntax challenging at best.
function(set_target_compile_flags target)
Cmake variables are global, which is why we would get crud like /machine:X86 in the list of compiler options for MSVC. Clear out the variable before attempting to enumerate arguments and set them. llvm-svn: 220522
2014-10-24 06:13:52 +08:00
set(argstring "")
CMake: create AddCompilerRT module and implement convenience add_compiler_rt_object_library function llvm-svn: 172826
2013-01-19 00:05:21 +08:00
foreach(arg ${ARGN})
set(argstring "${argstring} ${arg}")
endforeach()
set_property(TARGET ${target} PROPERTY COMPILE_FLAGS "${argstring}")
endfunction()
function(set_target_link_flags target)
Cmake variables are global, which is why we would get crud like /machine:X86 in the list of compiler options for MSVC. Clear out the variable before attempting to enumerate arguments and set them. llvm-svn: 220522
2014-10-24 06:13:52 +08:00
set(argstring "")
CMake: create AddCompilerRT module and implement convenience add_compiler_rt_object_library function llvm-svn: 172826
2013-01-19 00:05:21 +08:00
foreach(arg ${ARGN})
set(argstring "${argstring} ${arg}")
endforeach()
set_property(TARGET ${target} PROPERTY LINK_FLAGS "${argstring}")
endfunction()
Add a CMake option COMPILER_RT_DEBUG for building runtimes with full debug info. Differential Revision: http://llvm-reviews.chandlerc.com/D1984 llvm-svn: 193449
2013-10-26 07:03:34 +08:00
# Set the variable var_PYBOOL to True if var holds a true-ish string,
# otherwise set it to False.
macro(pythonize_bool var)
if (${var})
set(${var}_PYBOOL True)
else()
set(${var}_PYBOOL False)
endif()
endmacro()
[CMake] Simplify setting compile flag disabling RTTI llvm-svn: 201547
2014-02-18 15:52:40 +08:00
[CMake] Make append_if semantics similar to those used in LLVM llvm-svn: 203773
2014-03-13 17:31:36 +08:00
# Appends value to all lists in ARGN, if the condition is true.
[compiler-rt] compiler-rt's CMake append_if function clashes with LLVM's, let's rename it to append_list_if Doing s/append_if/append_list_if/, no functional change. http://reviews.llvm.org/D5739 llvm-svn: 219860
2014-10-16 06:47:54 +08:00
macro(append_list_if condition value)
[CMake] Make append_if semantics similar to those used in LLVM llvm-svn: 203773
2014-03-13 17:31:36 +08:00
if(${condition})
foreach(list ${ARGN})
list(APPEND ${list} ${value})
endforeach()
[CMake] Simplify setting compile flag disabling RTTI llvm-svn: 201547
2014-02-18 15:52:40 +08:00
endif()
endmacro()
[CMake] Use /W3 instead of -Wall on Windows. Remove add_definitions abuse. llvm-svn: 203786
2014-03-13 19:31:10 +08:00
# Appends value to all strings in ARGN, if the condition is true.
macro(append_string_if condition value)
if(${condition})
foreach(str ${ARGN})
set(${str} "${${str}} ${value}")
endforeach()
endif()
endmacro()
[cmake] Address Samsonov's post-commit review of r262723 Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17896 llvm-svn: 262770
2016-03-05 18:01:04 +08:00
macro(append_rtti_flag polarity list)
[cmake] Fix append_rtti_flag macro and bad var name llvm-svn: 279450
2016-08-23 02:30:37 +08:00
if(${polarity})
[cmake] Address Samsonov's post-commit review of r262723 Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17896 llvm-svn: 262770
2016-03-05 18:01:04 +08:00
append_list_if(COMPILER_RT_HAS_FRTTI_FLAG -frtti ${list})
append_list_if(COMPILER_RT_HAS_GR_FLAG /GR ${list})
else()
append_list_if(COMPILER_RT_HAS_FNO_RTTI_FLAG -fno-rtti ${list})
append_list_if(COMPILER_RT_HAS_GR_FLAG /GR- ${list})
endif()
[CMake] Simplify setting compile flag disabling RTTI llvm-svn: 201547
2014-02-18 15:52:40 +08:00
endmacro()
[ASan] Only include rpc headers if they are available. Reviewed at http://reviews.llvm.org/D8698 llvm-svn: 234470
2015-04-09 16:06:49 +08:00
[compiler-rt] list_union() is actually an intersect operation. Rename it. Summary: Given: set(T1 a b c) set(T2 b c d) message("T1=${T1}") message("T2=${T2}") list_union(T3 T1 T2) message("T3=${T3}") cmake emitted: T1=a;b;c T2=b;c;d T3=b;c Reviewers: beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16580 llvm-svn: 258916
2016-01-27 17:28:01 +08:00
macro(list_intersect output input1 input2)
[CMake] Add experimental support for building compiler-rt for iOS Summary: This is a reunification of three separate reviews D11073, D11082, D11083. Having them separate was not constructive even though the patches were smaller because it led to fragmented conversations, and this is really all about one change. This patch incorporates feedback from samsonov, and refactors the hacky darwin code out of the root CMakeLists.txt and int config-ix.cmake. Reviewers: zaks.anna, bogner, kubabrecka, chandlerc, samsonov Subscribers: jevinskie, filcab, llvm-commits Differential Revision: http://reviews.llvm.org/D11820 llvm-svn: 244948
2015-08-14 04:38:16 +08:00
set(${output})
foreach(it ${${input1}})
list(FIND ${input2} ${it} index)
if( NOT (index EQUAL -1))
list(APPEND ${output} ${it})
endif()
endforeach()
endmacro()
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-18 00:57:38 +08:00
build: allow building a specific set of sanitizers Introduce a new CMake option `COMPILER_RT_SANITIZERS_TO_BUILD` which takes either a special token `all` (default) which will preserve the current behaviour or a CMake list of sanitizers to build. It will still perform the normal checks if the sanitizer is requested. It only permits a further means to exclude a particular sanitizer. This gives finer grained control than `COMPILER_RT_BUILD_SANITIZERS` which only gives an all or nothing control. llvm-svn: 279253
2016-08-19 23:13:21 +08:00
function(list_replace input_list old new)
set(replaced_list)
foreach(item ${${input_list}})
if(${item} STREQUAL ${old})
list(APPEND replaced_list ${new})
else()
list(APPEND replaced_list ${item})
endif()
endforeach()
set(${input_list} "${replaced_list}" PARENT_SCOPE)
endfunction()
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-18 00:57:38 +08:00
# Takes ${ARGN} and puts only supported architectures in @out_var list.
function(filter_available_targets out_var)
set(archs ${${out_var}})
foreach(arch ${ARGN})
list(FIND COMPILER_RT_SUPPORTED_ARCH ${arch} ARCH_INDEX)
if(NOT (ARCH_INDEX EQUAL -1) AND CAN_TARGET_${arch})
list(APPEND archs ${arch})
endif()
endforeach()
set(${out_var} ${archs} PARENT_SCOPE)
endfunction()
[compiler-rt] Support building builtins for a single target This is used when building builtins for multiple targets as part of LLVM runtimes. Differential Revision: https://reviews.llvm.org/D26653 llvm-svn: 289489
2016-12-13 07:14:02 +08:00
# Add $arch as supported with no additional flags.
macro(add_default_target_arch arch)
set(TARGET_${arch}_CFLAGS "")
set(CAN_TARGET_${arch} 1)
list(APPEND COMPILER_RT_SUPPORTED_ARCH ${arch})
endmacro()
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-18 00:57:38 +08:00
function(check_compile_definition def argstring out_var)
if("${def}" STREQUAL "")
set(${out_var} TRUE PARENT_SCOPE)
return()
endif()
cmake_push_check_state()
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} ${argstring}")
check_symbol_exists(${def} "" ${out_var})
cmake_pop_check_state()
endfunction()
# test_target_arch(<arch> <def> <target flags...>)
# Checks if architecture is supported: runs host compiler with provided
# flags to verify that:
# 1) <def> is defined (if non-empty)
# 2) simple file can be successfully built.
# If successful, saves target flags for this architecture.
macro(test_target_arch arch def)
set(TARGET_${arch}_CFLAGS ${ARGN})
Make cmake link flag naming consistent Summary: The build system was inconsistent in its naming conventions for link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS, for consistency with cmake's LINK_FLAGS property. This patch should make it easier to search the source code for uses of link flags, as well as providing the benefit of improved style and consistency. Reviewers: compnerd, beanz Subscribers: kubabrecka, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28506 llvm-svn: 291539
2017-01-10 12:33:04 +08:00
set(TARGET_${arch}_LINK_FLAGS ${ARGN})
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-18 00:57:38 +08:00
set(argstring "")
foreach(arg ${ARGN})
set(argstring "${argstring} ${arg}")
endforeach()
check_compile_definition("${def}" "${argstring}" HAS_${arch}_DEF)
[compiler-rt][cmake] Don't reset CAN_TARGET_${arch} on every cmake invocation. Allowing this variable to be cached makes it possible to repair the MIPS buildbots in lieu of either fixing the mips64 sanitizer issues or fixing the detection of mips64 support (which I think was changed by r268977 but didn't take effect on this buildbot until the last couple days) so that it returns to not being built on these buildbots. llvm-svn: 276402
2016-07-22 18:15:09 +08:00
if(NOT DEFINED CAN_TARGET_${arch})
if(NOT HAS_${arch}_DEF)
set(CAN_TARGET_${arch} FALSE)
elseif(TEST_COMPILE_ONLY)
[CMake] Fix broken uses of `try_compile_only()` and improve the function. Summary: There were existing calls to `try_compile_only()` with arguments not prefixed by `SOURCE` or `FLAGS`. These were silently being ignored. It looks like the `SOURCE` and `FLAGS` arguments were first introduced in r278454. One implication of this is that for a builtins only build for Darwin (see `darwin_test_archs()`) it would mean we weren't actually passing `-arch <arch>` to the compiler). This would result in compiler-rt claiming all supplied architectures could be targetted provided the compiler could build for Clang's default architecture. This patch fixes this in several ways. * Fixes all incorrect calls to `try_compile_only()`. * Adds code to `try_compile_only()` to check for unhandled arguments and raises a fatal error if this occurs. This should stop any incorrect calls in the future. * Improve the documentation on `try_compile_only()` which seemed completely wrong. rdar://problem/48928526 Reviewers: beanz, fjricci, dsanders, kubamracek, yln, dcoughlin Subscribers: mgorny, jdoerfert, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D59429 llvm-svn: 356295
2019-03-16 04:14:46 +08:00
try_compile_only(CAN_TARGET_${arch} FLAGS ${TARGET_${arch}_CFLAGS})
[compiler-rt][cmake] Don't reset CAN_TARGET_${arch} on every cmake invocation. Allowing this variable to be cached makes it possible to repair the MIPS buildbots in lieu of either fixing the mips64 sanitizer issues or fixing the detection of mips64 support (which I think was changed by r268977 but didn't take effect on this buildbot until the last couple days) so that it returns to not being built on these buildbots. llvm-svn: 276402
2016-07-22 18:15:09 +08:00
else()
[CMake] Rename back SIMPLE_SOURCE to compile as C++ This was changed in rL276151 and causes problems if the C++ compiler does not support the same arches as the C compiler. For the builtins, only the C compiler is tested in try_compile_only. Additionally, -fno-exceptions is passed in (if available) to work around the case where no libunwind is available. Differential Revision: https://reviews.llvm.org/D23654 llvm-svn: 282054
2016-09-21 13:44:06 +08:00
set(FLAG_NO_EXCEPTIONS "")
if(COMPILER_RT_HAS_FNO_EXCEPTIONS_FLAG)
set(FLAG_NO_EXCEPTIONS " -fno-exceptions ")
endif()
[compiler-rt] respect CMAKE_EXE_LINKER_FLAGS in compiler and library tests Summary: check_cxx_compiler_flag and check_library_exists could fail because they ignored CMAKE_EXE_LINKER_FLAGS and therefore would always fail to produce executables. Cmake policy CMP0056 fixes this, but was explicitly set to OLD in our CMakeLists because it caused problems with test_target_arch. This change sets the policy to NEW to fix the problem with the compiler and library tests, and temporarily clears CMAKE_EXE_LINKER_FLAGS inside test_target_arch to emulate the old behavior there. This allows, for example, LTO builds that require lld to succeed. Reviewers: davidxl, beanz Reviewed By: beanz Subscribers: fjricci, dberris, mgorny, mehdi_amini, tejohnson, rnk, llvm-commits Differential Revision: https://reviews.llvm.org/D31098 llvm-svn: 298413
2017-03-22 02:25:35 +08:00
set(SAVED_CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS})
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${argstring}")
Revert "[CMake] Use a different source depending on C++ support" This reverts commit r332924 and followup r332936 silencing a warning. The change breaks the build on x86 if there is no 32-bit version of the C++ libraries, see discussion in https://reviews.llvm.org/D47169. llvm-svn: 334903
2018-06-17 17:51:33 +08:00
try_compile(CAN_TARGET_${arch} ${CMAKE_BINARY_DIR} ${SIMPLE_SOURCE}
[CMake] Rename back SIMPLE_SOURCE to compile as C++ This was changed in rL276151 and causes problems if the C++ compiler does not support the same arches as the C compiler. For the builtins, only the C compiler is tested in try_compile_only. Additionally, -fno-exceptions is passed in (if available) to work around the case where no libunwind is available. Differential Revision: https://reviews.llvm.org/D23654 llvm-svn: 282054
2016-09-21 13:44:06 +08:00
COMPILE_DEFINITIONS "${TARGET_${arch}_CFLAGS} ${FLAG_NO_EXCEPTIONS}"
[compiler-rt] respect CMAKE_EXE_LINKER_FLAGS in compiler and library tests Summary: check_cxx_compiler_flag and check_library_exists could fail because they ignored CMAKE_EXE_LINKER_FLAGS and therefore would always fail to produce executables. Cmake policy CMP0056 fixes this, but was explicitly set to OLD in our CMakeLists because it caused problems with test_target_arch. This change sets the policy to NEW to fix the problem with the compiler and library tests, and temporarily clears CMAKE_EXE_LINKER_FLAGS inside test_target_arch to emulate the old behavior there. This allows, for example, LTO builds that require lld to succeed. Reviewers: davidxl, beanz Reviewed By: beanz Subscribers: fjricci, dberris, mgorny, mehdi_amini, tejohnson, rnk, llvm-commits Differential Revision: https://reviews.llvm.org/D31098 llvm-svn: 298413
2017-03-22 02:25:35 +08:00
OUTPUT_VARIABLE TARGET_${arch}_OUTPUT)
set(CMAKE_EXE_LINKER_FLAGS ${SAVED_CMAKE_EXE_LINKER_FLAGS})
[compiler-rt][cmake] Don't reset CAN_TARGET_${arch} on every cmake invocation. Allowing this variable to be cached makes it possible to repair the MIPS buildbots in lieu of either fixing the mips64 sanitizer issues or fixing the detection of mips64 support (which I think was changed by r268977 but didn't take effect on this buildbot until the last couple days) so that it returns to not being built on these buildbots. llvm-svn: 276402
2016-07-22 18:15:09 +08:00
endif()
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-18 00:57:38 +08:00
endif()
if(${CAN_TARGET_${arch}})
list(APPEND COMPILER_RT_SUPPORTED_ARCH ${arch})
[compiler-rt] Fix target architecture matching Summary: Use stricter comparisons for architecture. This prevents cmake from failing for sysroots which can only compile armhf and not arm, since arm MATCHES armhf is true, while arm STREQUAL armhf is false. Reviewers: beanz, compnerd Subscribers: aemerson, llvm-commits Differential Revision: https://reviews.llvm.org/D22473 llvm-svn: 276148
2016-07-21 02:06:31 +08:00
elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" STREQUAL "${arch}" AND
[CMake] [NFC] Move macro definitions out of config-ix.cmake This change should have no functional impact, it just moves some macro definitions out of config-ix.cmake into CompilerRTUtils.cmake. This step will allow these macros to be re-used by the separated builtin build. llvm-svn: 261108
2016-02-18 00:57:38 +08:00
COMPILER_RT_HAS_EXPLICIT_DEFAULT_TARGET_TRIPLE)
# Bail out if we cannot target the architecture we plan to test.
message(FATAL_ERROR "Cannot compile for ${arch}:\n${TARGET_${arch}_OUTPUT}")
endif()
endmacro()
[CMake] detect_target_arch needs to be moved to Utils This macro is called from the base config, so it can't live in config-ix, it needs to be in the utils. I suspect the only reason this hasn't caused problems is that nobody is building the Android builtins from the builtins subdirectory. llvm-svn: 271693
2016-06-04 01:34:02 +08:00
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-15 06:04:30 +08:00
macro(detect_target_arch)
check_symbol_exists(__arm__ "" __ARM)
check_symbol_exists(__aarch64__ "" __AARCH64)
check_symbol_exists(__x86_64__ "" __X86_64)
check_symbol_exists(__i386__ "" __I386)
check_symbol_exists(__mips__ "" __MIPS)
check_symbol_exists(__mips64__ "" __MIPS64)
[compiler-rt][AIX] Add CMake support for 32-bit Power builds This patch enables support for building compiler-rt builtins for 32-bit Power arch on AIX. For now, we leave out the specialized ppc builtin implementations for 128-bit long double and friends since those will need some special handling for AIX. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D87383
2020-09-03 23:40:13 +08:00
check_symbol_exists(__powerpc__ "" __PPC)
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-15 06:04:30 +08:00
check_symbol_exists(__powerpc64__ "" __PPC64)
check_symbol_exists(__powerpc64le__ "" __PPC64LE)
check_symbol_exists(__riscv "" __RISCV)
check_symbol_exists(__s390x__ "" __S390X)
check_symbol_exists(__sparc "" __SPARC)
check_symbol_exists(__sparcv9 "" __SPARCV9)
check_symbol_exists(__wasm32__ "" __WEBASSEMBLY32)
check_symbol_exists(__wasm64__ "" __WEBASSEMBLY64)
check_symbol_exists(__ve__ "" __VE)
if(__ARM)
add_default_target_arch(arm)
elseif(__AARCH64)
add_default_target_arch(aarch64)
elseif(__X86_64)
[compiler-rt] Add platform detection support for x32 Currently, the compiler-rt build system checks only whether __X86_64 is defined to determine whether the default compiler-rt target arch is x86_64. Since x32 defines __X86_64 as well, we must also check that the default pointer size is eight bytes and not four bytes to properly detect a 64-bit x86_64 compiler-rt default target arch. Reviewed By: hvdijk, vitalybuka Differential Revision: https://reviews.llvm.org/D99988
2021-06-12 02:44:04 +08:00
if(CMAKE_SIZEOF_VOID_P EQUAL "4")
add_default_target_arch(x32)
elseif(CMAKE_SIZEOF_VOID_P EQUAL "8")
add_default_target_arch(x86_64)
else()
message(FATAL_ERROR "Unsupported pointer size for X86_64")
endif()
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-15 06:04:30 +08:00
elseif(__I386)
add_default_target_arch(i386)
elseif(__MIPS64) # must be checked before __MIPS
add_default_target_arch(mips64)
elseif(__MIPS)
add_default_target_arch(mips)
[compiler-rt][AIX] Add CMake support for 32-bit Power builds This patch enables support for building compiler-rt builtins for 32-bit Power arch on AIX. For now, we leave out the specialized ppc builtin implementations for 128-bit long double and friends since those will need some special handling for AIX. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D87383
2020-09-03 23:40:13 +08:00
elseif(__PPC64) # must be checked before __PPC
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-15 06:04:30 +08:00
add_default_target_arch(powerpc64)
elseif(__PPC64LE)
add_default_target_arch(powerpc64le)
[compiler-rt][AIX] Add CMake support for 32-bit Power builds This patch enables support for building compiler-rt builtins for 32-bit Power arch on AIX. For now, we leave out the specialized ppc builtin implementations for 128-bit long double and friends since those will need some special handling for AIX. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D87383
2020-09-03 23:40:13 +08:00
elseif(__PPC)
add_default_target_arch(powerpc)
Revert "[compiler-rt][Android] Stop using detect_target_arch" This reverts commit 9b7e24c2a5b32e25b773bc8b4ca84dbda995d959. See comments in https://reviews.llvm.org/D82148.
2020-07-15 06:04:30 +08:00
elseif(__RISCV)
if(CMAKE_SIZEOF_VOID_P EQUAL "4")
add_default_target_arch(riscv32)
elseif(CMAKE_SIZEOF_VOID_P EQUAL "8")
add_default_target_arch(riscv64)
else()
message(FATAL_ERROR "Unsupport XLEN for RISC-V")
endif()
elseif(__S390X)
add_default_target_arch(s390x)
elseif(__SPARCV9)
add_default_target_arch(sparcv9)
elseif(__SPARC)
add_default_target_arch(sparc)
elseif(__WEBASSEMBLY32)
add_default_target_arch(wasm32)
elseif(__WEBASSEMBLY64)
add_default_target_arch(wasm64)
elseif(__VE)
add_default_target_arch(ve)
endif()
endmacro()
[CMake][Compiler-rt] Compute `LLVM_MAIN_SRC_DIR` assuming the monorepo layout. When doing a standalone compiler-rt build we currently rely on getting information from the `llvm-config` binary. Previously we would rely on calling `llvm-config --src-root` to find the LLVM sources. Unfortunately the returned path could easily be wrong if the sources were built on another machine. Now that compiler-rt is part of a monorepo we can easily fix this problem by finding the LLVM source tree next to `compiler-rt` in the monorepo. We do this regardless of whether or not the `llvm-config` binary is available which moves us one step closer to not requiring `llvm-config` to be available. To try avoid anyone breaking anyone who relies on the current behavior, if the path assuming the monorepo layout doesn't exist we invoke `llvm-config --src-root` to get the path. A deprecation warning is emitted if this path is taken because we should remove this path in the future given that other runtimes already assume the monorepo layout. We also now emit a warning if `LLVM_MAIN_SRC_DIR` does not exist. The intention is that this should be a hard error in future but to avoid breaking existing users we'll keep this as a warning for now. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99620
2021-03-31 03:50:59 +08:00
function(get_compiler_rt_root_source_dir ROOT_DIR_VAR)
# Compute the path to the root of the Compiler-RT source tree
# regardless of how the project was configured.
#
# This function is useful because using `${CMAKE_SOURCE_DIR}`
# is error prone due to the numerous ways Compiler-RT can be
# configured.
#
# `ROOT_DIR_VAR` - the name of the variable to write the result to.
#
# TODO(dliew): When CMake min version is 3.17 or newer use
# `CMAKE_CURRENT_FUNCTION_LIST_DIR` instead.
if ("${ROOT_DIR_VAR}" STREQUAL "")
message(FATAL_ERROR "ROOT_DIR_VAR cannot be empty")
endif()
# Compiler-rt supports different source root paths.
# Handle each case here.
set(PATH_TO_COMPILER_RT_SOURCE_ROOT "")
if (DEFINED CompilerRTBuiltins_SOURCE_DIR)
# Compiler-RT Builtins standalone build.
# `llvm-project/compiler-rt/lib/builtins`
set(PATH_TO_COMPILER_RT_SOURCE_ROOT "${CompilerRTBuiltins_SOURCE_DIR}/../../")
elseif(DEFINED CompilerRT_SOURCE_DIR)
# Compiler-RT standalone build.
# `llvm-project/compiler-rt`
set(PATH_TO_COMPILER_RT_SOURCE_ROOT "${CompilerRT_SOURCE_DIR}")
elseif (EXISTS "${CMAKE_SOURCE_DIR}/../compiler-rt")
# In tree build with LLVM as the root project.
# See `llvm-project/projects/`.
# Assumes monorepo layout.
set(PATH_TO_COMPILER_RT_SOURCE_ROOT "${CMAKE_SOURCE_DIR}/../compiler-rt")
else()
message(FATAL_ERROR "Unhandled Compiler-RT source root configuration.")
endif()
get_filename_component(ROOT_DIR "${PATH_TO_COMPILER_RT_SOURCE_ROOT}" ABSOLUTE)
if (NOT EXISTS "${ROOT_DIR}")
message(FATAL_ERROR "Path \"${ROOT_DIR}\" doesn't exist")
endif()
# Sanity check: Make sure we can locate the current source file via the
# computed path.
set(PATH_TO_CURRENT_FILE "${ROOT_DIR}/cmake/Modules/CompilerRTUtils.cmake")
if (NOT EXISTS "${PATH_TO_CURRENT_FILE}")
message(FATAL_ERROR "Could not find \"${PATH_TO_CURRENT_FILE}\"")
endif()
set("${ROOT_DIR_VAR}" "${ROOT_DIR}" PARENT_SCOPE)
endfunction()
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 13:51:05 +08:00
macro(load_llvm_config)
if (NOT LLVM_CONFIG_PATH)
find_program(LLVM_CONFIG_PATH "llvm-config"
DOC "Path to llvm-config binary")
if (NOT LLVM_CONFIG_PATH)
[CMake] Allow building builtins standalone out of tree without any llvm-config available This is the same as libcxxabi/libcxx do. Differential Revision: https://reviews.llvm.org/D50134 llvm-svn: 338818
2018-08-03 13:50:33 +08:00
message(WARNING "UNSUPPORTED COMPILER-RT CONFIGURATION DETECTED: "
"llvm-config not found.\n"
"Reconfigure with -DLLVM_CONFIG_PATH=path/to/llvm-config.")
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 13:51:05 +08:00
endif()
endif()
[CMake][Compiler-rt] Compute `LLVM_MAIN_SRC_DIR` assuming the monorepo layout. When doing a standalone compiler-rt build we currently rely on getting information from the `llvm-config` binary. Previously we would rely on calling `llvm-config --src-root` to find the LLVM sources. Unfortunately the returned path could easily be wrong if the sources were built on another machine. Now that compiler-rt is part of a monorepo we can easily fix this problem by finding the LLVM source tree next to `compiler-rt` in the monorepo. We do this regardless of whether or not the `llvm-config` binary is available which moves us one step closer to not requiring `llvm-config` to be available. To try avoid anyone breaking anyone who relies on the current behavior, if the path assuming the monorepo layout doesn't exist we invoke `llvm-config --src-root` to get the path. A deprecation warning is emitted if this path is taken because we should remove this path in the future given that other runtimes already assume the monorepo layout. We also now emit a warning if `LLVM_MAIN_SRC_DIR` does not exist. The intention is that this should be a hard error in future but to avoid breaking existing users we'll keep this as a warning for now. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99620
2021-03-31 03:50:59 +08:00
# Compute path to LLVM sources assuming the monorepo layout.
# We don't set `LLVM_MAIN_SRC_DIR` directly to avoid overriding a user provided
# CMake cache value.
get_compiler_rt_root_source_dir(COMPILER_RT_ROOT_SRC_PATH)
get_filename_component(LLVM_MAIN_SRC_DIR_DEFAULT "${COMPILER_RT_ROOT_SRC_PATH}/../llvm" ABSOLUTE)
if (NOT EXISTS "${LLVM_MAIN_SRC_DIR_DEFAULT}")
# TODO(dliew): Remove this legacy fallback path.
message(WARNING
"LLVM source tree not found at \"${LLVM_MAIN_SRC_DIR_DEFAULT}\". "
"You are not using the monorepo layout. This configuration is DEPRECATED.")
endif()
[CMake][Compiler-rt] Make it possible to configure standalone compiler-rt without `LLVMConfig.cmake`. Previously it wasn't possible to configure a standalone compiler-rt build if the `LLVMConfig.cmake` file isn't present in a shipped toolchain. This patch adds a fallback behaviour for when `LLVMConfig.cmake` is not available in the toolchain being used for configure. The fallback behaviour mocks out the bare minimum required to make a configure succeed when the host is Darwin. Support for other platforms could be added in future patches. The new code path is taken either in one of the following cases: * `llvm-config` is not available. * `llvm-config` is available but it provides an invalid path for the CMake files. The motivation here is to be able to generate the compiler-rt lit test suites for an arbitrary LLVM toolchain and then run the tests against it. The invocation to do this looks something like. ``` CC=/path/to/cc \ CXX=/path/to/c++ \ cmake \ -G Ninja \ -DLLVM_CONFIG_PATH=/path/to/llvm-config \ -DCOMPILER_RT_INCLUDE_TESTS=ON \ /path/to/llvm-project/compiler-rt # Note we don't compile compiler-rt in this workflow. bin/llvm-lit -v test/path/to/generated/test_suite ``` A possible alternative approach is to configure the `cmake/modules/LLVMConfig.cmake.in` file in the LLVM source tree and then include it. This approach was not taken because it is more complicated. An interesting side benefit of this patch is that it is now possible to configure on Darwin without `llvm-config` being available by configuring with `-DLLVM_CONFIG_PATH=""`. This moves us a step closer to a world where no LLVM build artefacts are required to build compiler-rt. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99621
2021-03-31 04:47:07 +08:00
set(FOUND_LLVM_CMAKE_PATH FALSE)
[CMake] Allow building builtins standalone out of tree without any llvm-config available This is the same as libcxxabi/libcxx do. Differential Revision: https://reviews.llvm.org/D50134 llvm-svn: 338818
2018-08-03 13:50:33 +08:00
if (LLVM_CONFIG_PATH)
execute_process(
[XRay][compiler-rt] FDRLogWriter Abstraction Summary: This change introduces an `FDRLogWriter` type which is responsible for serialising metadata and function records to character buffers. This is the first step in a refactoring of the implementation of the FDR runtime to allow for more granular testing of the individual components of the implementation. The main contribution of this change is a means of hiding the details of how specific records are written to a buffer, and for managing the extents of these buffers. We make use of C++ features (templates and some metaprogramming) to reduce repetition in the act of writing out specific kinds of records to the buffer. In this process, we make a number of changes across both LLVM and compiler-rt to allow us to use the `Trace` abstraction defined in the LLVM project in the testing of the runtime implementation. This gives us a closer end-to-end test which version-locks the runtime implementation with the loading implementation in LLVM. We also allow using gmock in compiler-rt unit tests, by adding the requisite definitions in the `AddCompilerRT.cmake` module. We also add the terminfo library detection along with inclusion of the appropriate compiler flags for header include lookup. Finally, we've gone ahead and updated the FDR logging implementation to use the FDRLogWriter for the lowest-level record-writing details. Following patches will isolate the state machine transitions which manage the set-up and tear-down of the buffers we're using in multiple threads. Reviewers: mboerger, eizan Subscribers: mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52220 llvm-svn: 342617
2018-09-20 13:22:37 +08:00
COMMAND ${LLVM_CONFIG_PATH} "--obj-root" "--bindir" "--libdir" "--src-root" "--includedir"
[CMake] Allow building builtins standalone out of tree without any llvm-config available This is the same as libcxxabi/libcxx do. Differential Revision: https://reviews.llvm.org/D50134 llvm-svn: 338818
2018-08-03 13:50:33 +08:00
RESULT_VARIABLE HAD_ERROR
OUTPUT_VARIABLE CONFIG_OUTPUT)
if (HAD_ERROR)
message(FATAL_ERROR "llvm-config failed with status ${HAD_ERROR}")
endif()
string(REGEX REPLACE "[ \t]*[\r\n]+[ \t]*" ";" CONFIG_OUTPUT ${CONFIG_OUTPUT})
list(GET CONFIG_OUTPUT 0 BINARY_DIR)
list(GET CONFIG_OUTPUT 1 TOOLS_BINARY_DIR)
list(GET CONFIG_OUTPUT 2 LIBRARY_DIR)
list(GET CONFIG_OUTPUT 3 MAIN_SRC_DIR)
[XRay][compiler-rt] FDRLogWriter Abstraction Summary: This change introduces an `FDRLogWriter` type which is responsible for serialising metadata and function records to character buffers. This is the first step in a refactoring of the implementation of the FDR runtime to allow for more granular testing of the individual components of the implementation. The main contribution of this change is a means of hiding the details of how specific records are written to a buffer, and for managing the extents of these buffers. We make use of C++ features (templates and some metaprogramming) to reduce repetition in the act of writing out specific kinds of records to the buffer. In this process, we make a number of changes across both LLVM and compiler-rt to allow us to use the `Trace` abstraction defined in the LLVM project in the testing of the runtime implementation. This gives us a closer end-to-end test which version-locks the runtime implementation with the loading implementation in LLVM. We also allow using gmock in compiler-rt unit tests, by adding the requisite definitions in the `AddCompilerRT.cmake` module. We also add the terminfo library detection along with inclusion of the appropriate compiler flags for header include lookup. Finally, we've gone ahead and updated the FDR logging implementation to use the FDRLogWriter for the lowest-level record-writing details. Following patches will isolate the state machine transitions which manage the set-up and tear-down of the buffers we're using in multiple threads. Reviewers: mboerger, eizan Subscribers: mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52220 llvm-svn: 342617
2018-09-20 13:22:37 +08:00
list(GET CONFIG_OUTPUT 4 INCLUDE_DIR)
[cmake] Support overriding llvm-config query results Support overriding LLVM_* variables obtained from llvm-config when doing stand-alone builds. The override of LLVM_MAIN_SRC_DIR is necessary to provide LLVM sources when the initial directory used to build LLVM does no longer exist when compiler-rt is built stand-alone. This is especially the case when building the projects separately in temporary directories with unpredictable names. The code is based on existing CMakeLists.txt from clang. Alike clang, it extends the override to all queried variables. Differential Revision: https://reviews.llvm.org/D24005 llvm-svn: 281461
2016-09-14 21:42:31 +08:00
[CMake] Allow building builtins standalone out of tree without any llvm-config available This is the same as libcxxabi/libcxx do. Differential Revision: https://reviews.llvm.org/D50134 llvm-svn: 338818
2018-08-03 13:50:33 +08:00
set(LLVM_BINARY_DIR ${BINARY_DIR} CACHE PATH "Path to LLVM build tree")
set(LLVM_LIBRARY_DIR ${LIBRARY_DIR} CACHE PATH "Path to llvm/lib")
[XRay][compiler-rt] FDRLogWriter Abstraction Summary: This change introduces an `FDRLogWriter` type which is responsible for serialising metadata and function records to character buffers. This is the first step in a refactoring of the implementation of the FDR runtime to allow for more granular testing of the individual components of the implementation. The main contribution of this change is a means of hiding the details of how specific records are written to a buffer, and for managing the extents of these buffers. We make use of C++ features (templates and some metaprogramming) to reduce repetition in the act of writing out specific kinds of records to the buffer. In this process, we make a number of changes across both LLVM and compiler-rt to allow us to use the `Trace` abstraction defined in the LLVM project in the testing of the runtime implementation. This gives us a closer end-to-end test which version-locks the runtime implementation with the loading implementation in LLVM. We also allow using gmock in compiler-rt unit tests, by adding the requisite definitions in the `AddCompilerRT.cmake` module. We also add the terminfo library detection along with inclusion of the appropriate compiler flags for header include lookup. Finally, we've gone ahead and updated the FDR logging implementation to use the FDRLogWriter for the lowest-level record-writing details. Following patches will isolate the state machine transitions which manage the set-up and tear-down of the buffers we're using in multiple threads. Reviewers: mboerger, eizan Subscribers: mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52220 llvm-svn: 342617
2018-09-20 13:22:37 +08:00
set(LLVM_TOOLS_BINARY_DIR ${TOOLS_BINARY_DIR} CACHE PATH "Path to llvm/bin")
set(LLVM_INCLUDE_DIR ${INCLUDE_DIR} CACHE PATH "Paths to LLVM headers")
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 13:51:05 +08:00
[CMake][Compiler-rt] Compute `LLVM_MAIN_SRC_DIR` assuming the monorepo layout. When doing a standalone compiler-rt build we currently rely on getting information from the `llvm-config` binary. Previously we would rely on calling `llvm-config --src-root` to find the LLVM sources. Unfortunately the returned path could easily be wrong if the sources were built on another machine. Now that compiler-rt is part of a monorepo we can easily fix this problem by finding the LLVM source tree next to `compiler-rt` in the monorepo. We do this regardless of whether or not the `llvm-config` binary is available which moves us one step closer to not requiring `llvm-config` to be available. To try avoid anyone breaking anyone who relies on the current behavior, if the path assuming the monorepo layout doesn't exist we invoke `llvm-config --src-root` to get the path. A deprecation warning is emitted if this path is taken because we should remove this path in the future given that other runtimes already assume the monorepo layout. We also now emit a warning if `LLVM_MAIN_SRC_DIR` does not exist. The intention is that this should be a hard error in future but to avoid breaking existing users we'll keep this as a warning for now. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99620
2021-03-31 03:50:59 +08:00
if (NOT EXISTS "${LLVM_MAIN_SRC_DIR_DEFAULT}")
# TODO(dliew): Remove this legacy fallback path.
message(WARNING
"Consulting llvm-config for the LLVM source path "
"as a fallback. This behavior will be removed in the future.")
# We don't set `LLVM_MAIN_SRC_DIR` directly to avoid overriding a user
# provided CMake cache value.
set(LLVM_MAIN_SRC_DIR_DEFAULT "${MAIN_SRC_DIR}")
message(STATUS "Using LLVM source path (${LLVM_MAIN_SRC_DIR_DEFAULT}) from llvm-config")
endif()
[XRay] Clean up XRay build configuration Summary: This change spans both LLVM and compiler-rt, where we do the following: - Add XRay to the LLVMBuild system, to allow for distributing the XRay trace loading library along with the LLVM distributions. - Use `llvm-config` better in the compiler-rt XRay implementation, to depend on the potentially already-distributed LLVM XRay library. While this is tested with the standalone compiler-rt build, it does require that the LLVMXRay library (and LLVMSupport as well) are available during the build. In case the static libraries are available, the unit tests will build and work fine. We're still having issues with attempting to use a shared library version of the LLVMXRay library since the shared library might not be accessible from the standard shared library lookup paths. The larger change here is the inclusion of the LLVMXRay library in the distribution, which allows for building tools around the XRay traces and profiles that the XRay runtime already generates. Reviewers: echristo, beanz Subscribers: mgorny, hiraditya, mboerger, llvm-commits Differential Revision: https://reviews.llvm.org/D52349 llvm-svn: 342859
2018-09-24 13:28:01 +08:00
# Detect if we have the LLVMXRay and TestingSupport library installed and
# available from llvm-config.
execute_process(
[xray] [tests] Detect and handle missing LLVMTestingSupport gracefully Add a code to properly test for presence of LLVMTestingSupport library when performing a stand-alone build, and skip tests requiring it when it is not present. Since the library is not installed, llvm-config reported empty --libs for it and the tests failed to link with undefined references. Skipping the two fdr_* test files is better than failing to build, and should be good enough until we find a better solution. NB: both installing LLVMTestingSupport and building it automatically from within compiler-rt sources are non-trivial. The former due to dependency on gtest, the latter due to tight integration with LLVM source tree. Differential Revision: https://reviews.llvm.org/D55891 llvm-svn: 349899
2018-12-21 21:37:30 +08:00
COMMAND ${LLVM_CONFIG_PATH} "--ldflags" "--libs" "xray"
[XRay] Clean up XRay build configuration Summary: This change spans both LLVM and compiler-rt, where we do the following: - Add XRay to the LLVMBuild system, to allow for distributing the XRay trace loading library along with the LLVM distributions. - Use `llvm-config` better in the compiler-rt XRay implementation, to depend on the potentially already-distributed LLVM XRay library. While this is tested with the standalone compiler-rt build, it does require that the LLVMXRay library (and LLVMSupport as well) are available during the build. In case the static libraries are available, the unit tests will build and work fine. We're still having issues with attempting to use a shared library version of the LLVMXRay library since the shared library might not be accessible from the standard shared library lookup paths. The larger change here is the inclusion of the LLVMXRay library in the distribution, which allows for building tools around the XRay traces and profiles that the XRay runtime already generates. Reviewers: echristo, beanz Subscribers: mgorny, hiraditya, mboerger, llvm-commits Differential Revision: https://reviews.llvm.org/D52349 llvm-svn: 342859
2018-09-24 13:28:01 +08:00
RESULT_VARIABLE HAD_ERROR
[CMake][XRay] Silence llvm-config error when checking library support Otherwise this propagates all the way to CMake and results in an error during configuration. We check and handle the result and report warning separately so this is not changing the behavior. Differential Revision: https://reviews.llvm.org/D58086 llvm-svn: 353784
2019-02-12 09:09:07 +08:00
OUTPUT_VARIABLE CONFIG_OUTPUT
ERROR_QUIET)
[XRay] Clean up XRay build configuration Summary: This change spans both LLVM and compiler-rt, where we do the following: - Add XRay to the LLVMBuild system, to allow for distributing the XRay trace loading library along with the LLVM distributions. - Use `llvm-config` better in the compiler-rt XRay implementation, to depend on the potentially already-distributed LLVM XRay library. While this is tested with the standalone compiler-rt build, it does require that the LLVMXRay library (and LLVMSupport as well) are available during the build. In case the static libraries are available, the unit tests will build and work fine. We're still having issues with attempting to use a shared library version of the LLVMXRay library since the shared library might not be accessible from the standard shared library lookup paths. The larger change here is the inclusion of the LLVMXRay library in the distribution, which allows for building tools around the XRay traces and profiles that the XRay runtime already generates. Reviewers: echristo, beanz Subscribers: mgorny, hiraditya, mboerger, llvm-commits Differential Revision: https://reviews.llvm.org/D52349 llvm-svn: 342859
2018-09-24 13:28:01 +08:00
if (HAD_ERROR)
message(WARNING "llvm-config finding xray failed with status ${HAD_ERROR}")
set(COMPILER_RT_HAS_LLVMXRAY FALSE)
else()
string(REGEX REPLACE "[ \t]*[\r\n]+[ \t]*" ";" CONFIG_OUTPUT ${CONFIG_OUTPUT})
list(GET CONFIG_OUTPUT 0 LDFLAGS)
list(GET CONFIG_OUTPUT 1 LIBLIST)
[CMake][compiler-rt] Replace Windows backslashes with CMake ones XRay builds uses llvm-config to obtain the ldflags and libs and then passes those to CMake. Unfortunately, this breaks on Windows because CMake tries to interpret backslashes followed by certain characters as flags. We need to rewrite these into forward slashes that are used by CMake (even on Windows). Differential Revision: https://reviews.llvm.org/D73523
2020-01-28 11:20:02 +08:00
file(TO_CMAKE_PATH "${LDFLAGS}" LDFLAGS)
file(TO_CMAKE_PATH "${LIBLIST}" LIBLIST)
[XRay] Clean up XRay build configuration Summary: This change spans both LLVM and compiler-rt, where we do the following: - Add XRay to the LLVMBuild system, to allow for distributing the XRay trace loading library along with the LLVM distributions. - Use `llvm-config` better in the compiler-rt XRay implementation, to depend on the potentially already-distributed LLVM XRay library. While this is tested with the standalone compiler-rt build, it does require that the LLVMXRay library (and LLVMSupport as well) are available during the build. In case the static libraries are available, the unit tests will build and work fine. We're still having issues with attempting to use a shared library version of the LLVMXRay library since the shared library might not be accessible from the standard shared library lookup paths. The larger change here is the inclusion of the LLVMXRay library in the distribution, which allows for building tools around the XRay traces and profiles that the XRay runtime already generates. Reviewers: echristo, beanz Subscribers: mgorny, hiraditya, mboerger, llvm-commits Differential Revision: https://reviews.llvm.org/D52349 llvm-svn: 342859
2018-09-24 13:28:01 +08:00
set(LLVM_XRAY_LDFLAGS ${LDFLAGS} CACHE STRING "Linker flags for LLVMXRay library")
set(LLVM_XRAY_LIBLIST ${LIBLIST} CACHE STRING "Library list for LLVMXRay")
set(COMPILER_RT_HAS_LLVMXRAY TRUE)
endif()
[xray] [tests] Detect and handle missing LLVMTestingSupport gracefully Add a code to properly test for presence of LLVMTestingSupport library when performing a stand-alone build, and skip tests requiring it when it is not present. Since the library is not installed, llvm-config reported empty --libs for it and the tests failed to link with undefined references. Skipping the two fdr_* test files is better than failing to build, and should be good enough until we find a better solution. NB: both installing LLVMTestingSupport and building it automatically from within compiler-rt sources are non-trivial. The former due to dependency on gtest, the latter due to tight integration with LLVM source tree. Differential Revision: https://reviews.llvm.org/D55891 llvm-svn: 349899
2018-12-21 21:37:30 +08:00
set(COMPILER_RT_HAS_LLVMTESTINGSUPPORT FALSE)
execute_process(
COMMAND ${LLVM_CONFIG_PATH} "--ldflags" "--libs" "testingsupport"
RESULT_VARIABLE HAD_ERROR
[CMake][XRay] Silence llvm-config error when checking library support Otherwise this propagates all the way to CMake and results in an error during configuration. We check and handle the result and report warning separately so this is not changing the behavior. Differential Revision: https://reviews.llvm.org/D58086 llvm-svn: 353784
2019-02-12 09:09:07 +08:00
OUTPUT_VARIABLE CONFIG_OUTPUT
ERROR_QUIET)
[xray] [tests] Detect and handle missing LLVMTestingSupport gracefully Add a code to properly test for presence of LLVMTestingSupport library when performing a stand-alone build, and skip tests requiring it when it is not present. Since the library is not installed, llvm-config reported empty --libs for it and the tests failed to link with undefined references. Skipping the two fdr_* test files is better than failing to build, and should be good enough until we find a better solution. NB: both installing LLVMTestingSupport and building it automatically from within compiler-rt sources are non-trivial. The former due to dependency on gtest, the latter due to tight integration with LLVM source tree. Differential Revision: https://reviews.llvm.org/D55891 llvm-svn: 349899
2018-12-21 21:37:30 +08:00
if (HAD_ERROR)
message(WARNING "llvm-config finding testingsupport failed with status ${HAD_ERROR}")
[compiler-rt] Don't print warning about missing testingsupport if not including tests Reviewers: samsonov, vitalybuka Reviewed By: vitalybuka Subscribers: dberris, mgorny, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D77375
2020-04-09 17:18:42 +08:00
elseif(COMPILER_RT_INCLUDE_TESTS)
[xray] [tests] Detect and handle missing LLVMTestingSupport gracefully Add a code to properly test for presence of LLVMTestingSupport library when performing a stand-alone build, and skip tests requiring it when it is not present. Since the library is not installed, llvm-config reported empty --libs for it and the tests failed to link with undefined references. Skipping the two fdr_* test files is better than failing to build, and should be good enough until we find a better solution. NB: both installing LLVMTestingSupport and building it automatically from within compiler-rt sources are non-trivial. The former due to dependency on gtest, the latter due to tight integration with LLVM source tree. Differential Revision: https://reviews.llvm.org/D55891 llvm-svn: 349899
2018-12-21 21:37:30 +08:00
string(REGEX REPLACE "[ \t]*[\r\n]+[ \t]*" ";" CONFIG_OUTPUT ${CONFIG_OUTPUT})
list(GET CONFIG_OUTPUT 0 LDFLAGS)
list(GET CONFIG_OUTPUT 1 LIBLIST)
if (LIBLIST STREQUAL "")
message(WARNING "testingsupport library not installed, some tests will be skipped")
else()
[CMake][compiler-rt] Replace Windows backslashes with CMake ones XRay builds uses llvm-config to obtain the ldflags and libs and then passes those to CMake. Unfortunately, this breaks on Windows because CMake tries to interpret backslashes followed by certain characters as flags. We need to rewrite these into forward slashes that are used by CMake (even on Windows). Differential Revision: https://reviews.llvm.org/D73523
2020-01-28 11:20:02 +08:00
file(TO_CMAKE_PATH "${LDFLAGS}" LDFLAGS)
file(TO_CMAKE_PATH "${LIBLIST}" LIBLIST)
[xray] [tests] Detect and handle missing LLVMTestingSupport gracefully Add a code to properly test for presence of LLVMTestingSupport library when performing a stand-alone build, and skip tests requiring it when it is not present. Since the library is not installed, llvm-config reported empty --libs for it and the tests failed to link with undefined references. Skipping the two fdr_* test files is better than failing to build, and should be good enough until we find a better solution. NB: both installing LLVMTestingSupport and building it automatically from within compiler-rt sources are non-trivial. The former due to dependency on gtest, the latter due to tight integration with LLVM source tree. Differential Revision: https://reviews.llvm.org/D55891 llvm-svn: 349899
2018-12-21 21:37:30 +08:00
set(LLVM_TESTINGSUPPORT_LDFLAGS ${LDFLAGS} CACHE STRING "Linker flags for LLVMTestingSupport library")
set(LLVM_TESTINGSUPPORT_LIBLIST ${LIBLIST} CACHE STRING "Library list for LLVMTestingSupport")
set(COMPILER_RT_HAS_LLVMTESTINGSUPPORT TRUE)
endif()
endif()
[CMake] Allow building builtins standalone out of tree without any llvm-config available This is the same as libcxxabi/libcxx do. Differential Revision: https://reviews.llvm.org/D50134 llvm-svn: 338818
2018-08-03 13:50:33 +08:00
# Make use of LLVM CMake modules.
# --cmakedir is supported since llvm r291218 (4.0 release)
execute_process(
COMMAND ${LLVM_CONFIG_PATH} --cmakedir
RESULT_VARIABLE HAD_ERROR
OUTPUT_VARIABLE CONFIG_OUTPUT)
if(NOT HAD_ERROR)
string(STRIP "${CONFIG_OUTPUT}" LLVM_CMAKE_PATH_FROM_LLVM_CONFIG)
file(TO_CMAKE_PATH ${LLVM_CMAKE_PATH_FROM_LLVM_CONFIG} LLVM_CMAKE_PATH)
else()
file(TO_CMAKE_PATH ${LLVM_BINARY_DIR} LLVM_BINARY_DIR_CMAKE_STYLE)
set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR_CMAKE_STYLE}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
endif()
[cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from llvm-config. Fallback to local reconstruction if llvm-config does not support this option. llvm-svn: 291504
2017-01-10 07:23:56 +08:00
[Compiler-rt] Fix bug when considering CMake path returned by llvm-config. The previous check was wrong because it only checks that the LLVM CMake directory exists. However, it's possible that the directory exists but the `LLVMConfig.cmake` file does not. When this happens we would incorectly try to include the non-existant file. To fix this we make the check stricter by checking that the file we want to include actually exists. This is a follow up to fd28517d878e1d3d14f492ab659aabdf729fd331. rdar://76870467
2021-04-21 02:54:04 +08:00
set(LLVM_CMAKE_INCLUDE_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
if (EXISTS "${LLVM_CMAKE_INCLUDE_FILE}")
[CMake][Compiler-rt] Make it possible to configure standalone compiler-rt without `LLVMConfig.cmake`. Previously it wasn't possible to configure a standalone compiler-rt build if the `LLVMConfig.cmake` file isn't present in a shipped toolchain. This patch adds a fallback behaviour for when `LLVMConfig.cmake` is not available in the toolchain being used for configure. The fallback behaviour mocks out the bare minimum required to make a configure succeed when the host is Darwin. Support for other platforms could be added in future patches. The new code path is taken either in one of the following cases: * `llvm-config` is not available. * `llvm-config` is available but it provides an invalid path for the CMake files. The motivation here is to be able to generate the compiler-rt lit test suites for an arbitrary LLVM toolchain and then run the tests against it. The invocation to do this looks something like. ``` CC=/path/to/cc \ CXX=/path/to/c++ \ cmake \ -G Ninja \ -DLLVM_CONFIG_PATH=/path/to/llvm-config \ -DCOMPILER_RT_INCLUDE_TESTS=ON \ /path/to/llvm-project/compiler-rt # Note we don't compile compiler-rt in this workflow. bin/llvm-lit -v test/path/to/generated/test_suite ``` A possible alternative approach is to configure the `cmake/modules/LLVMConfig.cmake.in` file in the LLVM source tree and then include it. This approach was not taken because it is more complicated. An interesting side benefit of this patch is that it is now possible to configure on Darwin without `llvm-config` being available by configuring with `-DLLVM_CONFIG_PATH=""`. This moves us a step closer to a world where no LLVM build artefacts are required to build compiler-rt. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99621
2021-03-31 04:47:07 +08:00
list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")
# Get some LLVM variables from LLVMConfig.
[Compiler-rt] Fix bug when considering CMake path returned by llvm-config. The previous check was wrong because it only checks that the LLVM CMake directory exists. However, it's possible that the directory exists but the `LLVMConfig.cmake` file does not. When this happens we would incorectly try to include the non-existant file. To fix this we make the check stricter by checking that the file we want to include actually exists. This is a follow up to fd28517d878e1d3d14f492ab659aabdf729fd331. rdar://76870467
2021-04-21 02:54:04 +08:00
include("${LLVM_CMAKE_INCLUDE_FILE}")
[CMake][Compiler-rt] Make it possible to configure standalone compiler-rt without `LLVMConfig.cmake`. Previously it wasn't possible to configure a standalone compiler-rt build if the `LLVMConfig.cmake` file isn't present in a shipped toolchain. This patch adds a fallback behaviour for when `LLVMConfig.cmake` is not available in the toolchain being used for configure. The fallback behaviour mocks out the bare minimum required to make a configure succeed when the host is Darwin. Support for other platforms could be added in future patches. The new code path is taken either in one of the following cases: * `llvm-config` is not available. * `llvm-config` is available but it provides an invalid path for the CMake files. The motivation here is to be able to generate the compiler-rt lit test suites for an arbitrary LLVM toolchain and then run the tests against it. The invocation to do this looks something like. ``` CC=/path/to/cc \ CXX=/path/to/c++ \ cmake \ -G Ninja \ -DLLVM_CONFIG_PATH=/path/to/llvm-config \ -DCOMPILER_RT_INCLUDE_TESTS=ON \ /path/to/llvm-project/compiler-rt # Note we don't compile compiler-rt in this workflow. bin/llvm-lit -v test/path/to/generated/test_suite ``` A possible alternative approach is to configure the `cmake/modules/LLVMConfig.cmake.in` file in the LLVM source tree and then include it. This approach was not taken because it is more complicated. An interesting side benefit of this patch is that it is now possible to configure on Darwin without `llvm-config` being available by configuring with `-DLLVM_CONFIG_PATH=""`. This moves us a step closer to a world where no LLVM build artefacts are required to build compiler-rt. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99621
2021-03-31 04:47:07 +08:00
set(FOUND_LLVM_CMAKE_PATH TRUE)
else()
set(FOUND_LLVM_CMAKE_PATH FALSE)
[Compiler-rt] Fix bug when considering CMake path returned by llvm-config. The previous check was wrong because it only checks that the LLVM CMake directory exists. However, it's possible that the directory exists but the `LLVMConfig.cmake` file does not. When this happens we would incorectly try to include the non-existant file. To fix this we make the check stricter by checking that the file we want to include actually exists. This is a follow up to fd28517d878e1d3d14f492ab659aabdf729fd331. rdar://76870467
2021-04-21 02:54:04 +08:00
message(WARNING "LLVM CMake path (${LLVM_CMAKE_INCLUDE_FILE}) reported by llvm-config does not exist")
[CMake][Compiler-rt] Make it possible to configure standalone compiler-rt without `LLVMConfig.cmake`. Previously it wasn't possible to configure a standalone compiler-rt build if the `LLVMConfig.cmake` file isn't present in a shipped toolchain. This patch adds a fallback behaviour for when `LLVMConfig.cmake` is not available in the toolchain being used for configure. The fallback behaviour mocks out the bare minimum required to make a configure succeed when the host is Darwin. Support for other platforms could be added in future patches. The new code path is taken either in one of the following cases: * `llvm-config` is not available. * `llvm-config` is available but it provides an invalid path for the CMake files. The motivation here is to be able to generate the compiler-rt lit test suites for an arbitrary LLVM toolchain and then run the tests against it. The invocation to do this looks something like. ``` CC=/path/to/cc \ CXX=/path/to/c++ \ cmake \ -G Ninja \ -DLLVM_CONFIG_PATH=/path/to/llvm-config \ -DCOMPILER_RT_INCLUDE_TESTS=ON \ /path/to/llvm-project/compiler-rt # Note we don't compile compiler-rt in this workflow. bin/llvm-lit -v test/path/to/generated/test_suite ``` A possible alternative approach is to configure the `cmake/modules/LLVMConfig.cmake.in` file in the LLVM source tree and then include it. This approach was not taken because it is more complicated. An interesting side benefit of this patch is that it is now possible to configure on Darwin without `llvm-config` being available by configuring with `-DLLVM_CONFIG_PATH=""`. This moves us a step closer to a world where no LLVM build artefacts are required to build compiler-rt. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99621
2021-03-31 04:47:07 +08:00
endif()
[Compiler-rt] Fix bug when considering CMake path returned by llvm-config. The previous check was wrong because it only checks that the LLVM CMake directory exists. However, it's possible that the directory exists but the `LLVMConfig.cmake` file does not. When this happens we would incorectly try to include the non-existant file. To fix this we make the check stricter by checking that the file we want to include actually exists. This is a follow up to fd28517d878e1d3d14f492ab659aabdf729fd331. rdar://76870467
2021-04-21 02:54:04 +08:00
unset(LLVM_CMAKE_INCLUDE_FILE)
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 13:51:05 +08:00
[CMake] Allow building builtins standalone out of tree without any llvm-config available This is the same as libcxxabi/libcxx do. Differential Revision: https://reviews.llvm.org/D50134 llvm-svn: 338818
2018-08-03 13:50:33 +08:00
set(LLVM_LIBRARY_OUTPUT_INTDIR
${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
endif()
[CMake][Compiler-rt] Compute `LLVM_MAIN_SRC_DIR` assuming the monorepo layout. When doing a standalone compiler-rt build we currently rely on getting information from the `llvm-config` binary. Previously we would rely on calling `llvm-config --src-root` to find the LLVM sources. Unfortunately the returned path could easily be wrong if the sources were built on another machine. Now that compiler-rt is part of a monorepo we can easily fix this problem by finding the LLVM source tree next to `compiler-rt` in the monorepo. We do this regardless of whether or not the `llvm-config` binary is available which moves us one step closer to not requiring `llvm-config` to be available. To try avoid anyone breaking anyone who relies on the current behavior, if the path assuming the monorepo layout doesn't exist we invoke `llvm-config --src-root` to get the path. A deprecation warning is emitted if this path is taken because we should remove this path in the future given that other runtimes already assume the monorepo layout. We also now emit a warning if `LLVM_MAIN_SRC_DIR` does not exist. The intention is that this should be a hard error in future but to avoid breaking existing users we'll keep this as a warning for now. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99620
2021-03-31 03:50:59 +08:00
# Finally set the cache variable now that `llvm-config` has also had a chance
# to set `LLVM_MAIN_SRC_DIR_DEFAULT`.
set(LLVM_MAIN_SRC_DIR "${LLVM_MAIN_SRC_DIR_DEFAULT}" CACHE PATH "Path to LLVM source tree")
message(STATUS "LLVM_MAIN_SRC_DIR: \"${LLVM_MAIN_SRC_DIR}\"")
if (NOT EXISTS "${LLVM_MAIN_SRC_DIR}")
# TODO(dliew): Make this a hard error
message(WARNING "LLVM_MAIN_SRC_DIR (${LLVM_MAIN_SRC_DIR}) does not exist. "
"You can override the inferred path by adding "
"`-DLLVM_MAIN_SRC_DIR=<path_to_llvm_src>` to your CMake invocation "
"where `<path_to_llvm_src>` is the path to the `llvm` directory in "
"the `llvm-project` repo. "
"This will be treated as error in the future.")
endif()
[CMake][Compiler-rt] Make it possible to configure standalone compiler-rt without `LLVMConfig.cmake`. Previously it wasn't possible to configure a standalone compiler-rt build if the `LLVMConfig.cmake` file isn't present in a shipped toolchain. This patch adds a fallback behaviour for when `LLVMConfig.cmake` is not available in the toolchain being used for configure. The fallback behaviour mocks out the bare minimum required to make a configure succeed when the host is Darwin. Support for other platforms could be added in future patches. The new code path is taken either in one of the following cases: * `llvm-config` is not available. * `llvm-config` is available but it provides an invalid path for the CMake files. The motivation here is to be able to generate the compiler-rt lit test suites for an arbitrary LLVM toolchain and then run the tests against it. The invocation to do this looks something like. ``` CC=/path/to/cc \ CXX=/path/to/c++ \ cmake \ -G Ninja \ -DLLVM_CONFIG_PATH=/path/to/llvm-config \ -DCOMPILER_RT_INCLUDE_TESTS=ON \ /path/to/llvm-project/compiler-rt # Note we don't compile compiler-rt in this workflow. bin/llvm-lit -v test/path/to/generated/test_suite ``` A possible alternative approach is to configure the `cmake/modules/LLVMConfig.cmake.in` file in the LLVM source tree and then include it. This approach was not taken because it is more complicated. An interesting side benefit of this patch is that it is now possible to configure on Darwin without `llvm-config` being available by configuring with `-DLLVM_CONFIG_PATH=""`. This moves us a step closer to a world where no LLVM build artefacts are required to build compiler-rt. rdar://76016632 Differential Revision: https://reviews.llvm.org/D99621
2021-03-31 04:47:07 +08:00
if (NOT FOUND_LLVM_CMAKE_PATH)
# This configuration tries to configure without the prescence of `LLVMConfig.cmake`. It is
# intended for testing purposes (generating the lit test suites) and will likely not support
# a build of the runtimes in compiler-rt.
include(CompilerRTMockLLVMCMakeConfig)
compiler_rt_mock_llvm_cmake_config()
endif()
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 13:51:05 +08:00
endmacro()
macro(construct_compiler_rt_default_triple)
[compiler-rt] Support building builtins for a single target This is used when building builtins for multiple targets as part of LLVM runtimes. Differential Revision: https://reviews.llvm.org/D26653 llvm-svn: 289489
2016-12-13 07:14:02 +08:00
if(COMPILER_RT_DEFAULT_TARGET_ONLY)
if(DEFINED COMPILER_RT_DEFAULT_TARGET_TRIPLE)
message(FATAL_ERROR "COMPILER_RT_DEFAULT_TARGET_TRIPLE isn't supported when building for default target only")
endif()
set(COMPILER_RT_DEFAULT_TARGET_TRIPLE ${CMAKE_C_COMPILER_TARGET})
else()
set(COMPILER_RT_DEFAULT_TARGET_TRIPLE ${TARGET_TRIPLE} CACHE STRING
"Default triple for which compiler-rt runtimes will be built.")
endif()
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 13:51:05 +08:00
if(DEFINED COMPILER_RT_TEST_TARGET_TRIPLE)
# Backwards compatibility: this variable used to be called
# COMPILER_RT_TEST_TARGET_TRIPLE.
set(COMPILER_RT_DEFAULT_TARGET_TRIPLE ${COMPILER_RT_TEST_TARGET_TRIPLE})
endif()
string(REPLACE "-" ";" TARGET_TRIPLE_LIST ${COMPILER_RT_DEFAULT_TARGET_TRIPLE})
list(GET TARGET_TRIPLE_LIST 0 COMPILER_RT_DEFAULT_TARGET_ARCH)
[compiler-rt] Normalize i?86 to i386 and armv* to arm for COMPILER_RT_DEFAULT_TARGET_ARCH This corresponds to getArchNameForCompilerRTLib in clang; any 32 bit x86 architecture triple (except on android, but those exceptions are already handled in compiler-rt on a different level) get the compiler rt library names with i386; arm targets get either "arm" or "armhf". (Mapping to "armhf" is handled in the toplevel CMakeLists.txt.) Differential Revision: https://reviews.llvm.org/D98173
2021-03-08 19:38:52 +08:00
# Map various forms of the architecture names to the canonical forms
# (as they are used by clang, see getArchNameForCompilerRTLib).
if("${COMPILER_RT_DEFAULT_TARGET_ARCH}" MATCHES "^i.86$")
# Android uses i686, but that's remapped at a later stage.
set(COMPILER_RT_DEFAULT_TARGET_ARCH "i386")
endif()
[CMake] Load LLVMConfig for standalone build of builtins Therefore move some code into reusable macros. Differential Revision: https://reviews.llvm.org/D22866 llvm-svn: 277418
2016-08-02 13:51:05 +08:00
# Determine if test target triple is specified explicitly, and doesn't match the
# default.
if(NOT COMPILER_RT_DEFAULT_TARGET_TRIPLE STREQUAL TARGET_TRIPLE)
set(COMPILER_RT_HAS_EXPLICIT_DEFAULT_TARGET_TRIPLE TRUE)
else()
set(COMPILER_RT_HAS_EXPLICIT_DEFAULT_TARGET_TRIPLE FALSE)
endif()
endmacro()
[builtins] Prevent duplicate definitions for overridden functions Summary: Some architecture-specific function overrides (for example, i386/ashrdi3.S) duplicate generic functions (in that case, ashrdi3.c). Prevent duplicate definitions by filtering out the generic files before compiling. Reviewers: compnerd, beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D37166 llvm-svn: 312140
2017-08-31 01:12:57 +08:00
[builtins] Cleanup generic-file filtering Split filter_builtin_sources into two functions: - filter_builtin_sources that removes generic files when an arch-specific file is selected. - darwin_filter_builtin_sources that implements the EXCLUDE/INCLUDE lists (using the files in lib/builtins/Darwin-excludes). darwin_filter_builtin_sources delegates to filter_builtin_sources. Previously, lib/builtins/CMakeLists.txt had a number of calls to filter_builtin_sources (with a confusing/broken use of the `excluded_list` parameter), as well as a redundant arch-vs-generic filtering for the non-Apple code path at the end of the file. Replace all of this with a single call to filter_builtin_sources. Remove i686_SOURCES. Previously, this list contained only the arch-specific files common to 32-bit and 64-bit x86, which is a strange set. Normally the ${ARCH}_SOURCES list contains everything needed for the arch. "i686" isn't in ALL_BUILTIN_SUPPORTED_ARCH. NFCI, but i686_SOURCES won't be defined, and the order of files in ${arch}_SOURCES lists will change. Differential Revision: https://reviews.llvm.org/D82151
2020-06-19 14:59:36 +08:00
# Filter out generic versions of routines that are re-implemented in an
# architecture specific manner. This prevents multiple definitions of the same
# symbols, making the symbol selection non-deterministic.
#
# We follow the convention that a source file that exists in a sub-directory
# (e.g. `ppc/divtc3.c`) is architecture-specific and that if a generic
# implementation exists it will be a top-level source file with the same name
# modulo the file extension (e.g. `divtc3.c`).
function(filter_builtin_sources inout_var name)
set(intermediate ${${inout_var}})
foreach(_file ${intermediate})
get_filename_component(_file_dir ${_file} DIRECTORY)
if (NOT "${_file_dir}" STREQUAL "")
# Architecture specific file. If a generic version exists, print a notice
# and ensure that it is removed from the file list.
[builtins] Prevent duplicate definitions for overridden functions Summary: Some architecture-specific function overrides (for example, i386/ashrdi3.S) duplicate generic functions (in that case, ashrdi3.c). Prevent duplicate definitions by filtering out the generic files before compiling. Reviewers: compnerd, beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D37166 llvm-svn: 312140
2017-08-31 01:12:57 +08:00
get_filename_component(_name ${_file} NAME)
[builtins] Cleanup generic-file filtering Split filter_builtin_sources into two functions: - filter_builtin_sources that removes generic files when an arch-specific file is selected. - darwin_filter_builtin_sources that implements the EXCLUDE/INCLUDE lists (using the files in lib/builtins/Darwin-excludes). darwin_filter_builtin_sources delegates to filter_builtin_sources. Previously, lib/builtins/CMakeLists.txt had a number of calls to filter_builtin_sources (with a confusing/broken use of the `excluded_list` parameter), as well as a redundant arch-vs-generic filtering for the non-Apple code path at the end of the file. Replace all of this with a single call to filter_builtin_sources. Remove i686_SOURCES. Previously, this list contained only the arch-specific files common to 32-bit and 64-bit x86, which is a strange set. Normally the ${ARCH}_SOURCES list contains everything needed for the arch. "i686" isn't in ALL_BUILTIN_SUPPORTED_ARCH. NFCI, but i686_SOURCES won't be defined, and the order of files in ${arch}_SOURCES lists will change. Differential Revision: https://reviews.llvm.org/D82151
2020-06-19 14:59:36 +08:00
string(REGEX REPLACE "\\.S$" ".c" _cname "${_name}")
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/${_cname}")
message(STATUS "For ${name} builtins preferring ${_file} to ${_cname}")
list(REMOVE_ITEM intermediate ${_cname})
endif()
endif()
endforeach()
set(${inout_var} ${intermediate} PARENT_SCOPE)
[builtins] Prevent duplicate definitions for overridden functions Summary: Some architecture-specific function overrides (for example, i386/ashrdi3.S) duplicate generic functions (in that case, ashrdi3.c). Prevent duplicate definitions by filtering out the generic files before compiling. Reviewers: compnerd, beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D37166 llvm-svn: 312140
2017-08-31 01:12:57 +08:00
endfunction()
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
function(get_compiler_rt_target arch variable)
[CMake] Don't parse target triple except for arch compiler-rt CMake build currently tries to parse the triple and then put it back together, but doing so inherently tricky, and doing so from CMake is just crazy and currently doesn't handle triples that have more than three components. Fortunatelly, the CMake really only needs the architecture part, which is typically the first component, to construct variants for other architectures. This means we can keep the rest of the triple as is and avoid the parsing altogether. Differential Revision: https://reviews.llvm.org/D50548 llvm-svn: 339701
2018-08-15 02:01:19 +08:00
string(FIND ${COMPILER_RT_DEFAULT_TARGET_TRIPLE} "-" dash_index)
string(SUBSTRING ${COMPILER_RT_DEFAULT_TARGET_TRIPLE} ${dash_index} -1 triple_suffix)
[compiler-rt] Use exact spelling when building for default target When building for default target only, use exact target spelling when deriving the name for the per-target runtime directory. This is necessary for AArch32 where the CMake build by default rewrites the architecture which leads to unexpected results. Differential Revision: https://reviews.llvm.org/D54612 llvm-svn: 347022
2018-11-16 12:14:23 +08:00
if(COMPILER_RT_DEFAULT_TARGET_ONLY)
# Use exact spelling when building only for the target specified to CMake.
set(target "${COMPILER_RT_DEFAULT_TARGET_TRIPLE}")
elseif(ANDROID AND ${arch} STREQUAL "i386")
[builtins][Android] Fix 386->686 adjustment At this point in this code: - COMPILER_RT_DEFAULT_TARGET_TRIPLE is "i686-linux-android" - arch is "i386" The get_compiler_rt_target function currently turns that into: i686-android-linux-android The ${COMPILER_RT_OS_SUFFIX} is "-android" and redundant, so stop adding it. The get_compiler_rt_target() function is used for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR mode that isn't normally used with Android. Differential Revision: https://reviews.llvm.org/D82150
2020-06-19 14:57:08 +08:00
set(target "i686${triple_suffix}")
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
else()
[CMake] Don't parse target triple except for arch compiler-rt CMake build currently tries to parse the triple and then put it back together, but doing so inherently tricky, and doing so from CMake is just crazy and currently doesn't handle triples that have more than three components. Fortunatelly, the CMake really only needs the architecture part, which is typically the first component, to construct variants for other architectures. This means we can keep the rest of the triple as is and avoid the parsing altogether. Differential Revision: https://reviews.llvm.org/D50548 llvm-svn: 339701
2018-08-15 02:01:19 +08:00
set(target "${arch}${triple_suffix}")
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
endif()
set(${variable} ${target} PARENT_SCOPE)
endfunction()
function(get_compiler_rt_install_dir arch install_dir)
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
get_compiler_rt_target(${arch} target)
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
set(${install_dir} ${COMPILER_RT_INSTALL_LIBRARY_DIR}/${target} PARENT_SCOPE)
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
else()
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
set(${install_dir} ${COMPILER_RT_INSTALL_LIBRARY_DIR} PARENT_SCOPE)
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
endif()
endfunction()
function(get_compiler_rt_output_dir arch output_dir)
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
get_compiler_rt_target(${arch} target)
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
set(${output_dir} ${COMPILER_RT_OUTPUT_LIBRARY_DIR}/${target} PARENT_SCOPE)
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
else()
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
set(${output_dir} ${COMPILER_RT_OUTPUT_LIBRARY_DIR} PARENT_SCOPE)
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
endif()
endfunction()
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 21:00:17 +08:00
# compiler_rt_process_sources(
# <OUTPUT_VAR>
# <SOURCE_FILE> ...
# [ADDITIONAL_HEADERS <header> ...]
# )
#
# Process the provided sources and write the list of new sources
# into `<OUTPUT_VAR>`.
#
# ADDITIONAL_HEADERS - Adds the supplied header to list of sources for IDEs.
#
# This function is very similar to `llvm_process_sources()` but exists here
# because we need to support standalone builds of compiler-rt.
function(compiler_rt_process_sources OUTPUT_VAR)
cmake_parse_arguments(
ARG
""
""
"ADDITIONAL_HEADERS"
${ARGN}
)
set(sources ${ARG_UNPARSED_ARGUMENTS})
set(headers "")
if (XCODE OR MSVC_IDE OR CMAKE_EXTRA_GENERATOR)
# For IDEs we need to tell CMake about header files.
# Otherwise they won't show up in UI.
set(headers ${ARG_ADDITIONAL_HEADERS})
list(LENGTH headers headers_length)
if (${headers_length} GREATER 0)
set_source_files_properties(${headers}
PROPERTIES HEADER_FILE_ONLY ON)
endif()
endif()
set("${OUTPUT_VAR}" ${sources} ${headers} PARENT_SCOPE)
endfunction()
[compiler-rt] Create install targets for Darwin libraries Darwin targets were generating CMake install rules but not the corresponding install targets. Centralize the existing install target creation to a function and use that function for both Darwin and non-Darwin builds. Differential Revision: https://reviews.llvm.org/D61541 llvm-svn: 360181
2019-05-08 03:00:37 +08:00
# Create install targets for a library and its parent component (if specified).
function(add_compiler_rt_install_targets name)
cmake_parse_arguments(ARG "" "PARENT_TARGET" "" ${ARGN})
if(ARG_PARENT_TARGET AND NOT TARGET install-${ARG_PARENT_TARGET})
# The parent install target specifies the parent component to scrape up
# anything not installed by the individual install targets, and to handle
# installation when running the multi-configuration generators.
add_custom_target(install-${ARG_PARENT_TARGET}
DEPENDS ${ARG_PARENT_TARGET}
COMMAND "${CMAKE_COMMAND}"
-DCMAKE_INSTALL_COMPONENT=${ARG_PARENT_TARGET}
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
add_custom_target(install-${ARG_PARENT_TARGET}-stripped
DEPENDS ${ARG_PARENT_TARGET}
COMMAND "${CMAKE_COMMAND}"
-DCMAKE_INSTALL_COMPONENT=${ARG_PARENT_TARGET}
-DCMAKE_INSTALL_DO_STRIP=1
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
set_target_properties(install-${ARG_PARENT_TARGET} PROPERTIES
FOLDER "Compiler-RT Misc")
set_target_properties(install-${ARG_PARENT_TARGET}-stripped PROPERTIES
FOLDER "Compiler-RT Misc")
add_dependencies(install-compiler-rt install-${ARG_PARENT_TARGET})
add_dependencies(install-compiler-rt-stripped install-${ARG_PARENT_TARGET}-stripped)
endif()
# We only want to generate per-library install targets if you aren't using
# an IDE because the extra targets get cluttered in IDEs.
if(NOT CMAKE_CONFIGURATION_TYPES)
add_custom_target(install-${name}
DEPENDS ${name}
COMMAND "${CMAKE_COMMAND}"
-DCMAKE_INSTALL_COMPONENT=${name}
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
add_custom_target(install-${name}-stripped
DEPENDS ${name}
COMMAND "${CMAKE_COMMAND}"
-DCMAKE_INSTALL_COMPONENT=${name}
-DCMAKE_INSTALL_DO_STRIP=1
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake")
# If you have a parent target specified, we bind the new install target
# to the parent install target.
if(LIB_PARENT_TARGET)
add_dependencies(install-${LIB_PARENT_TARGET} install-${name})
add_dependencies(install-${LIB_PARENT_TARGET}-stripped install-${name}-stripped)
endif()
endif()
endfunction()