RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 18:54:02 +01:00
Code Issues Projects Releases Wiki Activity
a6523f1436
llvm-mirror/cmake/modules/LLVMExternalProjectUtils.cmake

281 lines
9.9 KiB
CMake
Raw Normal View History

[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
include(ExternalProject)
# llvm_ExternalProject_BuildCmd(out_var target)
# Utility function for constructing command lines for external project targets
[CMake] Make llvm_ExternalProject always call the build action This makes it so that when running 'ninja test-suite' from the top-level LLVM ninja build it *always* re-runs the ninja command in the test-suite directory. This mechanism is required because the top-level ninja file doesn't have a view into the subdirectory dependency tree, so it can't know what, if anything, needs to be rebuilt. llvm-svn: 265863
2016-04-09 00:46:04 +02:00
function(llvm_ExternalProject_BuildCmd out_var target bin_dir)
[CMake] Cleanup LLVM_OPTIMIZED_TABLEGEN This cleanup removes the need for the native support library to have its own target. That target was only needed because makefile builds were tripping over each other if two tablegen targets were building at the same time. This causes problems because the parallel make invocations through CMake can't communicate with each other. This is fixed by invoking make directly instead of through CMake which is how we handle this in External Project invocations. The other part of the cleanup is to mark the custom commands as USES_TERMINAL. This is a bit of a hack, but we need to ensure that Ninja generators don't invoke multiple tablegen targets in the same build dir in parallel, because that too would be bad. Marking as USES_TERMINAL does have some downside for Ninja because it results in decreased parallelism, but correct builds are worth the minor loss and LLVM_OPTIMZIED_TABLEGEN is such a huge win, it is worth it. llvm-svn: 280748
2016-09-06 22:27:07 +02:00
cmake_parse_arguments(ARG "" "CONFIGURATION" "" ${ARGN})
if(NOT ARG_CONFIGURATION)
[cmake] Remove use of deprecated generator expression. NFC Use $<CONFIG> instead of $<CONFIGURATION>, since the latter has been deprecated since CMake 3.0, and the former is entirely equivalent. llvm-svn: 357338
2019-03-30 02:35:01 +01:00
set(ARG_CONFIGURATION "$<CONFIG>")
[CMake] Cleanup LLVM_OPTIMIZED_TABLEGEN This cleanup removes the need for the native support library to have its own target. That target was only needed because makefile builds were tripping over each other if two tablegen targets were building at the same time. This causes problems because the parallel make invocations through CMake can't communicate with each other. This is fixed by invoking make directly instead of through CMake which is how we handle this in External Project invocations. The other part of the cleanup is to mark the custom commands as USES_TERMINAL. This is a bit of a hack, but we need to ensure that Ninja generators don't invoke multiple tablegen targets in the same build dir in parallel, because that too would be bad. Marking as USES_TERMINAL does have some downside for Ninja because it results in decreased parallelism, but correct builds are worth the minor loss and LLVM_OPTIMZIED_TABLEGEN is such a huge win, it is worth it. llvm-svn: 280748
2016-09-06 22:27:07 +02:00
endif()
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
if (CMAKE_GENERATOR MATCHES "Make")
# Use special command for Makefiles to support parallelism.
[CMake] Cleanup LLVM_OPTIMIZED_TABLEGEN This cleanup removes the need for the native support library to have its own target. That target was only needed because makefile builds were tripping over each other if two tablegen targets were building at the same time. This causes problems because the parallel make invocations through CMake can't communicate with each other. This is fixed by invoking make directly instead of through CMake which is how we handle this in External Project invocations. The other part of the cleanup is to mark the custom commands as USES_TERMINAL. This is a bit of a hack, but we need to ensure that Ninja generators don't invoke multiple tablegen targets in the same build dir in parallel, because that too would be bad. Marking as USES_TERMINAL does have some downside for Ninja because it results in decreased parallelism, but correct builds are worth the minor loss and LLVM_OPTIMZIED_TABLEGEN is such a huge win, it is worth it. llvm-svn: 280748
2016-09-06 22:27:07 +02:00
set(${out_var} "$(MAKE)" "-C" "${bin_dir}" "${target}" PARENT_SCOPE)
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
else()
[CMake] Make llvm_ExternalProject always call the build action This makes it so that when running 'ninja test-suite' from the top-level LLVM ninja build it *always* re-runs the ninja command in the test-suite directory. This mechanism is required because the top-level ninja file doesn't have a view into the subdirectory dependency tree, so it can't know what, if anything, needs to be rebuilt. llvm-svn: 265863
2016-04-09 00:46:04 +02:00
set(${out_var} ${CMAKE_COMMAND} --build ${bin_dir} --target ${target}
[CMake] Cleanup LLVM_OPTIMIZED_TABLEGEN This cleanup removes the need for the native support library to have its own target. That target was only needed because makefile builds were tripping over each other if two tablegen targets were building at the same time. This causes problems because the parallel make invocations through CMake can't communicate with each other. This is fixed by invoking make directly instead of through CMake which is how we handle this in External Project invocations. The other part of the cleanup is to mark the custom commands as USES_TERMINAL. This is a bit of a hack, but we need to ensure that Ninja generators don't invoke multiple tablegen targets in the same build dir in parallel, because that too would be bad. Marking as USES_TERMINAL does have some downside for Ninja because it results in decreased parallelism, but correct builds are worth the minor loss and LLVM_OPTIMZIED_TABLEGEN is such a huge win, it is worth it. llvm-svn: 280748
2016-09-06 22:27:07 +02:00
--config ${ARG_CONFIGURATION} PARENT_SCOPE)
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
endif()
endfunction()
# llvm_ExternalProject_Add(name source_dir ...
# USE_TOOLCHAIN
# Use just-built tools (see TOOLCHAIN_TOOLS)
# EXCLUDE_FROM_ALL
# Exclude this project from the all target
# NO_INSTALL
# Don't generate install targets for this project
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
# ALWAYS_CLEAN
# Always clean the sub-project before building
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
# CMAKE_ARGS arguments...
# Optional cmake arguments to pass when configuring the project
# TOOLCHAIN_TOOLS targets...
# Targets for toolchain tools (defaults to clang;lld)
# DEPENDS targets...
# Targets that this project depends on
# EXTRA_TARGETS targets...
# Extra targets in the subproject to generate targets for
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
# PASSTHROUGH_PREFIXES prefix...
# Extra variable prefixes (name is always included) to pass down
[CMake] Support stripping and linking output to .build-id directory When installing runtimes with install-runtimes-stripped, we don't want to just strip them, we also want to preserve the debugging information for potential debugging. To make it possible to later find the stripped debugging information, we want to use the .build-id layout: https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID That is, for libfoo.so with build ID abcdef1234, the debugging information will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy already has support for stripping files and linking the debugging stripped output into the right location. However, CMake doesn't support customizing strip invocation for the *-stripped targets. So instead, we replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with the right command line flags. Differential Revision: https://reviews.llvm.org/D59127 llvm-svn: 355765
2019-03-09 02:26:55 +01:00
# STRIP_TOOL path
# Use provided strip tool instead of the default one.
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
# )
function(llvm_ExternalProject_Add name source_dir)
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
cmake_parse_arguments(ARG
"USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL;ALWAYS_CLEAN"
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
"SOURCE_DIR"
[CMake] Support stripping and linking output to .build-id directory When installing runtimes with install-runtimes-stripped, we don't want to just strip them, we also want to preserve the debugging information for potential debugging. To make it possible to later find the stripped debugging information, we want to use the .build-id layout: https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID That is, for libfoo.so with build ID abcdef1234, the debugging information will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy already has support for stripping files and linking the debugging stripped output into the right location. However, CMake doesn't support customizing strip invocation for the *-stripped targets. So instead, we replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with the right command line flags. Differential Revision: https://reviews.llvm.org/D59127 llvm-svn: 355765
2019-03-09 02:26:55 +01:00
"CMAKE_ARGS;TOOLCHAIN_TOOLS;RUNTIME_LIBRARIES;DEPENDS;EXTRA_TARGETS;PASSTHROUGH_PREFIXES;STRIP_TOOL"
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
${ARGN})
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
canonicalize_tool_name(${name} nameCanon)
if(NOT ARG_TOOLCHAIN_TOOLS)
set(ARG_TOOLCHAIN_TOOLS clang lld)
[CMake] Multi-target builtins build This change enables building builtins for multiple different targets using LLVM runtimes directory. To specify the builtin targets to be built, use the LLVM_BUILTIN_TARGETS variable, where the value is the list of targets. To pass a per target variable to the builtin build, you can set BUILTINS_<target>_<variable> where <variable> will be passed to the builtin build for <target>. Differential Revision: https://reviews.llvm.org/D26652 llvm-svn: 289491
2016-12-13 00:15:10 +01:00
if(NOT APPLE AND NOT WIN32)
[CMake] Pass additional CMake tools to external projects This is needed when the external projects try to use other tools besides just the compiler and the linker. Differential Revision: https://reviews.llvm.org/D47833 llvm-svn: 334136
2018-06-06 23:43:37 +02:00
list(APPEND ARG_TOOLCHAIN_TOOLS llvm-ar llvm-ranlib llvm-nm llvm-objcopy llvm-objdump llvm-strip)
[CMake] Multi-target builtins build This change enables building builtins for multiple different targets using LLVM runtimes directory. To specify the builtin targets to be built, use the LLVM_BUILTIN_TARGETS variable, where the value is the list of targets. To pass a per target variable to the builtin build, you can set BUILTINS_<target>_<variable> where <variable> will be passed to the builtin build for <target>. Differential Revision: https://reviews.llvm.org/D26652 llvm-svn: 289491
2016-12-13 00:15:10 +01:00
endif()
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
endif()
foreach(tool ${ARG_TOOLCHAIN_TOOLS})
if(TARGET ${tool})
list(APPEND TOOLCHAIN_TOOLS ${tool})
list(APPEND TOOLCHAIN_BINS $<TARGET_FILE:${tool}>)
endif()
endforeach()
if(NOT ARG_RUNTIME_LIBRARIES)
set(ARG_RUNTIME_LIBRARIES compiler-rt libcxx)
endif()
foreach(lib ${ARG_RUNTIME_LIBRARIES})
if(TARGET ${lib})
list(APPEND RUNTIME_LIBRARIES ${lib})
endif()
endforeach()
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
if(ARG_ALWAYS_CLEAN)
set(always_clean clean)
endif()
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
list(FIND TOOLCHAIN_TOOLS clang FOUND_CLANG)
if(FOUND_CLANG GREATER -1)
set(CLANG_IN_TOOLCHAIN On)
endif()
if(RUNTIME_LIBRARIES AND CLANG_IN_TOOLCHAIN)
list(APPEND TOOLCHAIN_BINS ${RUNTIME_LIBRARIES})
endif()
set(STAMP_DIR ${CMAKE_CURRENT_BINARY_DIR}/${name}-stamps/)
set(BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/${name}-bins/)
add_custom_target(${name}-clear
COMMAND ${CMAKE_COMMAND} -E remove_directory ${BINARY_DIR}
COMMAND ${CMAKE_COMMAND} -E remove_directory ${STAMP_DIR}
COMMENT "Clobbering ${name} build and stamp directories"
[CMake] Cleanup uses of USES_TERMINAL Now that we are on CMake 3.4.3 we no longer need a version check around this. llvm-svn: 272211
2016-06-09 00:19:25 +02:00
USES_TERMINAL
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
)
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
# Find all variables that start with a prefix and propagate them through
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
get_cmake_property(variableNames VARIABLES)
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
list(APPEND ARG_PASSTHROUGH_PREFIXES ${nameCanon})
foreach(prefix ${ARG_PASSTHROUGH_PREFIXES})
foreach(variableName ${variableNames})
if(variableName MATCHES "^${prefix}")
[CMake] Don't use comma as an alternate separator Using comma can break in cases when we're passing flags that already use comma as a separator. Fixes PR35504. Differential Revision: https://reviews.llvm.org/D40761 llvm-svn: 319719
2017-12-05 01:15:18 +01:00
string(REPLACE ";" "|" value "${${variableName}}")
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
list(APPEND PASSTHROUGH_VARIABLES
-D${variableName}=${value})
endif()
endforeach()
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
endforeach()
[CMake] Support for cross-compilation when build runtimes When cross-compiling, we cannot use the just built toolchain, instead we need to use the host toolchain which we assume has a support for targeting the selected target platform. We also need to pass the path to the native version of llvm-config to external projects. Differential Revision: https://reviews.llvm.org/D41678 llvm-svn: 322046
2018-01-09 00:50:59 +01:00
if(ARG_USE_TOOLCHAIN AND NOT CMAKE_CROSSCOMPILING)
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
if(CLANG_IN_TOOLCHAIN)
set(compiler_args -DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang
-DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang++)
endif()
[CMake] Pass additional CMake tools to external projects This is needed when the external projects try to use other tools besides just the compiler and the linker. Differential Revision: https://reviews.llvm.org/D47833 llvm-svn: 334136
2018-06-06 23:43:37 +02:00
if(lld IN_LIST TOOLCHAIN_TOOLS)
list(APPEND compiler_args -DCMAKE_LINKER=${LLVM_RUNTIME_OUTPUT_INTDIR}/ld.lld)
endif()
[CMake] Multi-target builtins build This change enables building builtins for multiple different targets using LLVM runtimes directory. To specify the builtin targets to be built, use the LLVM_BUILTIN_TARGETS variable, where the value is the list of targets. To pass a per target variable to the builtin build, you can set BUILTINS_<target>_<variable> where <variable> will be passed to the builtin build for <target>. Differential Revision: https://reviews.llvm.org/D26652 llvm-svn: 289491
2016-12-13 00:15:10 +01:00
if(llvm-ar IN_LIST TOOLCHAIN_TOOLS)
list(APPEND compiler_args -DCMAKE_AR=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-ar)
endif()
if(llvm-ranlib IN_LIST TOOLCHAIN_TOOLS)
list(APPEND compiler_args -DCMAKE_RANLIB=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-ranlib)
endif()
[CMake] Pass additional CMake tools to external projects This is needed when the external projects try to use other tools besides just the compiler and the linker. Differential Revision: https://reviews.llvm.org/D47833 llvm-svn: 334136
2018-06-06 23:43:37 +02:00
if(llvm-nm IN_LIST TOOLCHAIN_TOOLS)
list(APPEND compiler_args -DCMAKE_NM=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-nm)
endif()
if(llvm-objdump IN_LIST TOOLCHAIN_TOOLS)
list(APPEND compiler_args -DCMAKE_OBJDUMP=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-objdump)
endif()
if(llvm-objcopy IN_LIST TOOLCHAIN_TOOLS)
list(APPEND compiler_args -DCMAKE_OBJCOPY=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-objcopy)
endif()
[CMake] Support stripping and linking output to .build-id directory When installing runtimes with install-runtimes-stripped, we don't want to just strip them, we also want to preserve the debugging information for potential debugging. To make it possible to later find the stripped debugging information, we want to use the .build-id layout: https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID That is, for libfoo.so with build ID abcdef1234, the debugging information will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy already has support for stripping files and linking the debugging stripped output into the right location. However, CMake doesn't support customizing strip invocation for the *-stripped targets. So instead, we replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with the right command line flags. Differential Revision: https://reviews.llvm.org/D59127 llvm-svn: 355765
2019-03-09 02:26:55 +01:00
if(llvm-strip IN_LIST TOOLCHAIN_TOOLS AND NOT ARG_STRIP_TOOL)
[CMake] Pass additional CMake tools to external projects This is needed when the external projects try to use other tools besides just the compiler and the linker. Differential Revision: https://reviews.llvm.org/D47833 llvm-svn: 334136
2018-06-06 23:43:37 +02:00
list(APPEND compiler_args -DCMAKE_STRIP=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-strip)
endif()
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
list(APPEND ARG_DEPENDS ${TOOLCHAIN_TOOLS})
endif()
[CMake] Support stripping and linking output to .build-id directory When installing runtimes with install-runtimes-stripped, we don't want to just strip them, we also want to preserve the debugging information for potential debugging. To make it possible to later find the stripped debugging information, we want to use the .build-id layout: https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID That is, for libfoo.so with build ID abcdef1234, the debugging information will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy already has support for stripping files and linking the debugging stripped output into the right location. However, CMake doesn't support customizing strip invocation for the *-stripped targets. So instead, we replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with the right command line flags. Differential Revision: https://reviews.llvm.org/D59127 llvm-svn: 355765
2019-03-09 02:26:55 +01:00
if(ARG_STRIP_TOOL)
list(APPEND compiler_args -DCMAKE_STRIP=${ARG_STRIP_TOOL})
endif()
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${name}-clobber-stamp
DEPENDS ${ARG_DEPENDS}
COMMAND ${CMAKE_COMMAND} -E touch ${BINARY_DIR}/CMakeCache.txt
COMMAND ${CMAKE_COMMAND} -E touch ${STAMP_DIR}/${name}-mkdir
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_CURRENT_BINARY_DIR}/${name}-clobber-stamp
COMMENT "Clobbering bootstrap build and stamp directories"
)
add_custom_target(${name}-clobber
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${name}-clobber-stamp)
if(ARG_EXCLUDE_FROM_ALL)
[CMake] Cleanup ExternalProject usage of CMake 3.x features All the ExternalProject features in use here are supported by CMake 3.4.3, so we don't need these version checks anymore. llvm-svn: 272327
2016-06-10 00:41:36 +02:00
set(exclude EXCLUDE_FROM_ALL 1)
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
endif()
[cmake] Only pass CMAKE_SYSROOT if non-empty In my build environment (cmake 3.6.1 and gcc 4.8.5 on CentOS 7), having an empty CMAKE_SYSROOT in the cache results in --sysroot="" being passed to all compile commands, and then the compiler errors out because of the empty sysroot. Only set CMAKE_SYSROOT if non-empty to avoid this. Differential Revision: https://reviews.llvm.org/D40934 llvm-svn: 320183
2017-12-08 20:42:47 +01:00
if(CMAKE_SYSROOT)
set(sysroot_arg -DCMAKE_SYSROOT=${CMAKE_SYSROOT})
endif()
[CMake] Support for cross-compilation when build runtimes When cross-compiling, we cannot use the just built toolchain, instead we need to use the host toolchain which we assume has a support for targeting the selected target platform. We also need to pass the path to the native version of llvm-config to external projects. Differential Revision: https://reviews.llvm.org/D41678 llvm-svn: 322046
2018-01-09 00:50:59 +01:00
if(CMAKE_CROSSCOMPILING)
set(compiler_args -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
[CMake] Pass additional CMake tools to external projects This is needed when the external projects try to use other tools besides just the compiler and the linker. Differential Revision: https://reviews.llvm.org/D47833 llvm-svn: 334136
2018-06-06 23:43:37 +02:00
-DCMAKE_LINKER=${CMAKE_LINKER}
[CMake] Support for cross-compilation when build runtimes When cross-compiling, we cannot use the just built toolchain, instead we need to use the host toolchain which we assume has a support for targeting the selected target platform. We also need to pass the path to the native version of llvm-config to external projects. Differential Revision: https://reviews.llvm.org/D41678 llvm-svn: 322046
2018-01-09 00:50:59 +01:00
-DCMAKE_AR=${CMAKE_AR}
[CMake] Pass additional CMake tools to external projects This is needed when the external projects try to use other tools besides just the compiler and the linker. Differential Revision: https://reviews.llvm.org/D47833 llvm-svn: 334136
2018-06-06 23:43:37 +02:00
-DCMAKE_RANLIB=${CMAKE_RANLIB}
-DCMAKE_NM=${CMAKE_NM}
-DCMAKE_OBJCOPY=${CMAKE_OBJCOPY}
-DCMAKE_OBJDUMP=${CMAKE_OBJDUMP}
-DCMAKE_STRIP=${CMAKE_STRIP})
[cmake] Don't build Native llvm-config when cross compiling if passed by user. Summary: Rename LLVM_CONFIG_EXE to LLVM_CONFIG_PATH, and avoid building it if passed in by user. This is the same way CLANG_TABLEGEN and LLVM_TABLEGEN are handled, e.g., when -DLLVM_OPTIMIZED_TABLEGEN=ON is passed. Differential Revision: https://reviews.llvm.org/D41806 llvm-svn: 323053
2018-01-21 01:29:00 +01:00
set(llvm_config_path ${LLVM_CONFIG_PATH})
[CMake] Support cross-compiling with multi-stage builds When using multi-stage builds, we would like support cross-compilation. Example is 2-stage build when the first stage is compiled for host while the second stage is compiled for the target. Normally, the second stage would be also used for compiling runtimes, but that's not possible when cross-compiling, so we use the first stage compiler instead. However, we still want to use the second stage paths. To do so, we set the -resource-dir of the first stage compiler to point to the resource directory of the second stage. We also need compiler tools that support the target architecture. These tools are not guaranteed to be present on the host, but in case of multi-stage build, we can build these tools in the first stage. Differential Revision: https://reviews.llvm.org/D54461 llvm-svn: 347025
2018-11-16 05:46:48 +01:00
if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
string(REGEX MATCH "[0-9]+\\.[0-9]+(\\.[0-9]+)?" CLANG_VERSION
${PACKAGE_VERSION})
set(resource_dir "${LLVM_LIBRARY_DIR}/clang/${CLANG_VERSION}")
set(flag_types ASM C CXX MODULE_LINKER SHARED_LINKER EXE_LINKER)
foreach(type ${flag_types})
set(${type}_flag -DCMAKE_${type}_FLAGS=-resource-dir=${resource_dir})
endforeach()
string(REPLACE ";" "|" flag_string "${flag_types}")
foreach(arg ${ARG_CMAKE_ARGS})
if(arg MATCHES "^-DCMAKE_(${flag_string})_FLAGS")
foreach(type ${flag_types})
if(arg MATCHES "^-DCMAKE_${type}_FLAGS")
string(REGEX REPLACE "^-DCMAKE_${type}_FLAGS=(.*)$" "\\1" flag_value "${arg}")
set(${type}_flag "${${type}_flag} ${flag_value}")
endif()
endforeach()
else()
list(APPEND cmake_args ${arg})
endif()
endforeach()
foreach(type ${flag_types})
list(APPEND cmake_args ${${type}_flag})
endforeach()
endif()
[CMake] Support for cross-compilation when build runtimes When cross-compiling, we cannot use the just built toolchain, instead we need to use the host toolchain which we assume has a support for targeting the selected target platform. We also need to pass the path to the native version of llvm-config to external projects. Differential Revision: https://reviews.llvm.org/D41678 llvm-svn: 322046
2018-01-09 00:50:59 +01:00
else()
set(llvm_config_path "$<TARGET_FILE:llvm-config>")
[CMake] Support cross-compiling with multi-stage builds When using multi-stage builds, we would like support cross-compilation. Example is 2-stage build when the first stage is compiled for host while the second stage is compiled for the target. Normally, the second stage would be also used for compiling runtimes, but that's not possible when cross-compiling, so we use the first stage compiler instead. However, we still want to use the second stage paths. To do so, we set the -resource-dir of the first stage compiler to point to the resource directory of the second stage. We also need compiler tools that support the target architecture. These tools are not guaranteed to be present on the host, but in case of multi-stage build, we can build these tools in the first stage. Differential Revision: https://reviews.llvm.org/D54461 llvm-svn: 347025
2018-11-16 05:46:48 +01:00
set(cmake_args ${ARG_CMAKE_ARGS})
[CMake] Support for cross-compilation when build runtimes When cross-compiling, we cannot use the just built toolchain, instead we need to use the host toolchain which we assume has a support for targeting the selected target platform. We also need to pass the path to the native version of llvm-config to external projects. Differential Revision: https://reviews.llvm.org/D41678 llvm-svn: 322046
2018-01-09 00:50:59 +01:00
endif()
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
ExternalProject_Add(${name}
[CMake] Make llvm-config implicit dependency for subprojects The subproject interface being used for runtime libraries expects that llvm-config is passed into the subproject for consumption. We currently do this for every subproject, so we should expect that all LLVM ExternalProjects depend on llvm-config for the time being. Eventually I'd like to see the sub-projects using LLVMConfig.cmake instead of the llvm-config binary, but that will take time to roll out. llvm-svn: 279155
2016-08-18 23:41:21 +02:00
DEPENDS ${ARG_DEPENDS} llvm-config
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
${name}-clobber
PREFIX ${CMAKE_BINARY_DIR}/projects/${name}
SOURCE_DIR ${source_dir}
STAMP_DIR ${STAMP_DIR}
BINARY_DIR ${BINARY_DIR}
${exclude}
CMAKE_ARGS ${${nameCanon}_CMAKE_ARGS}
${compiler_args}
-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
[cmake] Only pass CMAKE_SYSROOT if non-empty In my build environment (cmake 3.6.1 and gcc 4.8.5 on CentOS 7), having an empty CMAKE_SYSROOT in the cache results in --sysroot="" being passed to all compile commands, and then the compiler errors out because of the empty sysroot. Only set CMAKE_SYSROOT if non-empty to avoid this. Differential Revision: https://reviews.llvm.org/D40934 llvm-svn: 320183
2017-12-08 20:42:47 +01:00
${sysroot_arg}
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
-DLLVM_BINARY_DIR=${PROJECT_BINARY_DIR}
[CMake] Support for cross-compilation when build runtimes When cross-compiling, we cannot use the just built toolchain, instead we need to use the host toolchain which we assume has a support for targeting the selected target platform. We also need to pass the path to the native version of llvm-config to external projects. Differential Revision: https://reviews.llvm.org/D41678 llvm-svn: 322046
2018-01-09 00:50:59 +01:00
-DLLVM_CONFIG_PATH=${llvm_config_path}
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
-DLLVM_ENABLE_WERROR=${LLVM_ENABLE_WERROR}
[CMake] Pass LLVM_HOST_TRIPLE to external projects LLVM runtimes rely on LLVM_HOST_TRIPLE being set in their builds and tests so make sure it's being passed down. Differential Revision: https://reviews.llvm.org/D40515 llvm-svn: 319109
2017-11-27 23:50:48 +01:00
-DLLVM_HOST_TRIPLE=${LLVM_HOST_TRIPLE}
[CMake] Pass LLVM_HAVE_LINK_VERSION_SCRIPT to external projects Some external projects depend on this LLVM CMake variable. Differential Revision: https://reviews.llvm.org/D41205 llvm-svn: 320658
2017-12-14 00:49:51 +01:00
-DLLVM_HAVE_LINK_VERSION_SCRIPT=${LLVM_HAVE_LINK_VERSION_SCRIPT}
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
-DPACKAGE_VERSION=${PACKAGE_VERSION}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
Generate a compile_commands.json DB for external projects. compile_commands.json file is very useful both for tooling and for reproducible builds. For files generated from recursive CMake invocation this information was not previously generated. Differential Review: https://reviews.llvm.org/D35219 llvm-svn: 308698
2017-07-21 01:46:46 +02:00
-DCMAKE_EXPORT_COMPILE_COMMANDS=1
[CMake] Support cross-compiling with multi-stage builds When using multi-stage builds, we would like support cross-compilation. Example is 2-stage build when the first stage is compiled for host while the second stage is compiled for the target. Normally, the second stage would be also used for compiling runtimes, but that's not possible when cross-compiling, so we use the first stage compiler instead. However, we still want to use the second stage paths. To do so, we set the -resource-dir of the first stage compiler to point to the resource directory of the second stage. We also need compiler tools that support the target architecture. These tools are not guaranteed to be present on the host, but in case of multi-stage build, we can build these tools in the first stage. Differential Revision: https://reviews.llvm.org/D54461 llvm-svn: 347025
2018-11-16 05:46:48 +01:00
${cmake_args}
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
${PASSTHROUGH_VARIABLES}
INSTALL_COMMAND ""
STEP_TARGETS configure build
[CMake] Cleanup ExternalProject usage of CMake 3.x features All the ExternalProject features in use here are supported by CMake 3.4.3, so we don't need these version checks anymore. llvm-svn: 272327
2016-06-10 00:41:36 +02:00
BUILD_ALWAYS 1
USES_TERMINAL_CONFIGURE 1
USES_TERMINAL_BUILD 1
USES_TERMINAL_INSTALL 1
[CMake] Don't use comma as an alternate separator Using comma can break in cases when we're passing flags that already use comma as a separator. Fixes PR35504. Differential Revision: https://reviews.llvm.org/D40761 llvm-svn: 319719
2017-12-05 01:15:18 +01:00
LIST_SEPARATOR |
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
)
if(ARG_USE_TOOLCHAIN)
set(force_deps DEPENDS ${TOOLCHAIN_BINS})
endif()
[CMake] Make llvm_ExternalProject always call the build action This makes it so that when running 'ninja test-suite' from the top-level LLVM ninja build it *always* re-runs the ninja command in the test-suite directory. This mechanism is required because the top-level ninja file doesn't have a view into the subdirectory dependency tree, so it can't know what, if anything, needs to be rebuilt. llvm-svn: 265863
2016-04-09 00:46:04 +02:00
llvm_ExternalProject_BuildCmd(run_clean clean ${BINARY_DIR})
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
ExternalProject_Add_Step(${name} clean
COMMAND ${run_clean}
COMMENT "Cleaning ${name}..."
DEPENDEES configure
${force_deps}
WORKING_DIRECTORY ${BINARY_DIR}
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-24 00:07:21 +02:00
EXCLUDE_FROM_MAIN 1
[CMake] Cleanup ExternalProject usage of CMake 3.x features All the ExternalProject features in use here are supported by CMake 3.4.3, so we don't need these version checks anymore. llvm-svn: 272327
2016-06-10 00:41:36 +02:00
USES_TERMINAL 1
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
)
ExternalProject_Add_StepTargets(${name} clean)
if(ARG_USE_TOOLCHAIN)
add_dependencies(${name}-clean ${name}-clobber)
set_target_properties(${name}-clean PROPERTIES
SOURCES ${CMAKE_CURRENT_BINARY_DIR}/${name}-clobber-stamp)
endif()
if(NOT ARG_NO_INSTALL)
[CMake] Pass CMAKE_INSTALL_DO_STRIP to external projects This is necessary to make install-<target>-stripped work for external projects such as runtimes. Differential Revision: https://reviews.llvm.org/D49335 llvm-svn: 337115
2018-07-15 04:12:25 +02:00
install(CODE "execute_process\(COMMAND \${CMAKE_COMMAND} -DCMAKE_INSTALL_PREFIX=\${CMAKE_INSTALL_PREFIX} -DCMAKE_INSTALL_DO_STRIP=\${CMAKE_INSTALL_DO_STRIP} -P ${BINARY_DIR}/cmake_install.cmake\)"
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
COMPONENT ${name})
[llvm] Add stripped installation targets CMake's generated installation scripts support `CMAKE_INSTALL_DO_STRIP` to enable stripping the installed binaries. LLVM's build system doesn't expose this option to the `install-` targets, but it's useful in conjunction with `install-distribution`. Add a new function to create the install targets, which creates both the regular install target and a second install target that strips during installation. Change the creation of all installation targets to use this new function. Stripping doesn't make a whole lot of sense for some installation targets (e.g. the LLVM headers), but consistency doesn't hurt. I'll make other repositories (e.g. clang, compiler-rt) use this in a follow-up, and then add an `install-distribution-stripped` target to actually accomplish the end goal of creating a stripped distribution. I don't want to do that step yet because the creation of that target would depend on the presence of the `install-*-stripped` target for each distribution component, and the distribution components from other repositories will be missing that target right now. Differential Revision: https://reviews.llvm.org/D40620 llvm-svn: 319480
2017-11-30 22:48:26 +01:00
add_llvm_install_targets(install-${name}
DEPENDS ${name}
COMPONENT ${name})
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
endif()
# Add top-level targets
foreach(target ${ARG_EXTRA_TARGETS})
[CMake] Use variables rather than ":" delimiters This is a more idiomatic CMake. Differential Revision: https://reviews.llvm.org/D37644 llvm-svn: 335703
2018-06-27 05:14:41 +02:00
if(DEFINED ${target})
set(external_target "${${target}}")
[CMake] Support multi-target runtimes build This changes adds support for building runtimes for multiple different targets using LLVM runtimes directory. The implementation follow the model used already by the builtins build which already supports this option. To specify the runtimes targets to be built, use the LLVM_RUNTIME_TARGETS variable, where the valuae is the list of targets to build runtimes for. To pass a per target variable to the runtimes build, you can set RUNTIMES_<target>_<variable> where <variable> will be passed to the runtimes build for <target>. Each runtime target (except for the default one) will be installed into lib/<target> subdirectory. Build targets will be suffixed with the target name. Differential Revision: https://reviews.llvm.org/D32816 llvm-svn: 307731
2017-07-12 01:41:15 +02:00
else()
[CMake] Use variables rather than ":" delimiters This is a more idiomatic CMake. Differential Revision: https://reviews.llvm.org/D37644 llvm-svn: 335703
2018-06-27 05:14:41 +02:00
set(external_target "${target}")
[CMake] Support multi-target runtimes build This changes adds support for building runtimes for multiple different targets using LLVM runtimes directory. The implementation follow the model used already by the builtins build which already supports this option. To specify the runtimes targets to be built, use the LLVM_RUNTIME_TARGETS variable, where the valuae is the list of targets to build runtimes for. To pass a per target variable to the runtimes build, you can set RUNTIMES_<target>_<variable> where <variable> will be passed to the runtimes build for <target>. Each runtime target (except for the default one) will be installed into lib/<target> subdirectory. Build targets will be suffixed with the target name. Differential Revision: https://reviews.llvm.org/D32816 llvm-svn: 307731
2017-07-12 01:41:15 +02:00
endif()
[CMake] Use variables rather than ":" delimiters This is a more idiomatic CMake. Differential Revision: https://reviews.llvm.org/D37644 llvm-svn: 335703
2018-06-27 05:14:41 +02:00
llvm_ExternalProject_BuildCmd(build_runtime_cmd ${external_target} ${BINARY_DIR})
add_custom_target(${target}
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
COMMAND ${build_runtime_cmd}
DEPENDS ${name}-configure
WORKING_DIRECTORY ${BINARY_DIR}
VERBATIM
[CMake] Cleanup uses of USES_TERMINAL Now that we are on CMake 3.4.3 we no longer need a version check around this. llvm-svn: 272211
2016-06-09 00:19:25 +02:00
USES_TERMINAL)
[CMake] Add support for building the llvm test-suite as part of an LLVM build using clang and lld Summary: This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out. The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt. This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx. Reviewers: samsonov, jroelofs, rengolin, jmolloy Subscribers: jmolloy, llvm-commits Differential Revision: http://reviews.llvm.org/D14513 llvm-svn: 252747
2015-11-11 17:14:03 +01:00
endforeach()
endfunction()
Reference in New Issue Copy Permalink