maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/cmake/modules/AddClang.cmake

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

188 lines
5.7 KiB
CMake
Raw Normal View History

[cmake] Add support for multiple distributions LLVM's build system contains support for configuring a distribution, but it can often be useful to be able to configure multiple distributions (e.g. if you want separate distributions for the tools and the libraries). Add this support to the build system, along with documentation and usage examples. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D89177
2020-10-02 05:35:28 +08:00
include(LLVMDistributionSupport)
Move add_clang_* entry points from the main clang CMakeLists.txt to cmake/modules/AddClang.cmake. This matches how LLVM has its cmake files organized and is cleaner than just shoving this business logic into the main CMakeLists.txt. llvm-svn: 274992
2016-07-10 05:58:40 +08:00
function(clang_tablegen)
# Syntax:
# clang_tablegen output-file [tablegen-arg ...] SOURCE source-file
# [[TARGET cmake-target-name] [DEPENDS extra-dependency ...]]
#
# Generates a custom command for invoking tblgen as
#
# tblgen source-file -o=output-file tablegen-arg ...
#
# and, if cmake-target-name is provided, creates a custom target for
# executing the custom command depending on output-file. It is
# possible to list more files to depend after DEPENDS.
cmake_parse_arguments(CTG "" "SOURCE;TARGET" "" ${ARGN})
if( NOT CTG_SOURCE )
message(FATAL_ERROR "SOURCE source-file required by clang_tablegen")
endif()
[CMAKE] Plumb include_directories() into tablegen() Previously, the tablegen() cmake command, which defines custom commands for running tablegen, included several hardcoded paths. This becomes unwieldy as there are more users for which these paths are insufficient. For most targets, cmake uses include_directories() and the INCLUDE_DIRECTORIES directory property to specify include paths. This change picks up the INCLUDE_DIRECTORIES property and adds it to the include path used when running tablegen. As a side effect, this allows us to remove several hard coded paths to tablegen that are redundant with specified include_directories(). I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which seems generically useful. There are several users in clang which apparently don't have the current directory as an include_directories(). This could be considered separately. The new version of this path uses list APPEND rather than list TRANSFORM, in order to be compatible with cmake 3.4.3. If we update to cmake 3.12 then we can use list TRANSFORM instead. Differential Revision: https://reviews.llvm.org/D77156
2020-04-01 02:45:59 +08:00
set( CLANG_TABLEGEN_ARGUMENTS "" )
Move add_clang_* entry points from the main clang CMakeLists.txt to cmake/modules/AddClang.cmake. This matches how LLVM has its cmake files organized and is cleaner than just shoving this business logic into the main CMakeLists.txt. llvm-svn: 274992
2016-07-10 05:58:40 +08:00
set( LLVM_TARGET_DEFINITIONS ${CTG_SOURCE} )
Always -I clang/include when tblgen'ing in Clang.
2019-12-15 15:27:27 +08:00
tablegen(CLANG ${CTG_UNPARSED_ARGUMENTS} ${CLANG_TABLEGEN_ARGUMENTS})
Move add_clang_* entry points from the main clang CMakeLists.txt to cmake/modules/AddClang.cmake. This matches how LLVM has its cmake files organized and is cleaner than just shoving this business logic into the main CMakeLists.txt. llvm-svn: 274992
2016-07-10 05:58:40 +08:00
if(CTG_TARGET)
add_public_tablegen_target(${CTG_TARGET})
set_target_properties( ${CTG_TARGET} PROPERTIES FOLDER "Clang tablegenning")
set_property(GLOBAL APPEND PROPERTY CLANG_TABLEGEN_TARGETS ${CTG_TARGET})
endif()
endfunction(clang_tablegen)
macro(set_clang_windows_version_resource_properties name)
if(DEFINED windows_resource_file)
set_windows_version_resource_properties(${name} ${windows_resource_file}
VERSION_MAJOR ${CLANG_VERSION_MAJOR}
VERSION_MINOR ${CLANG_VERSION_MINOR}
VERSION_PATCHLEVEL ${CLANG_VERSION_PATCHLEVEL}
VERSION_STRING "${CLANG_VERSION} (${BACKEND_PACKAGE_STRING})"
PRODUCT_NAME "clang")
endif()
endmacro()
macro(add_clang_subdirectory name)
add_llvm_subdirectory(CLANG TOOL ${name})
endmacro()
macro(add_clang_library name)
cmake_parse_arguments(ARG
Reland [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON f8990feb125a enabled installing PIC version of both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC build when LLVM_ENABLE_PIC=OFF with the following error: ``` CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123 (target_compile_definitions): target_compile_definitions called with non-compilable target type ``` This is because as the code loops through ${name} and ${name}_static, it introduced a side effect, which is adding an empty libclang_static to targets. Later target_compile_definitions is called on libclang_static. That function requires that target must have been created by a command such as add_executable() or add_library(), so it crashed. The solution is to not naively loop through both libclang and libclang_static, but only the ones that are actually added by llvm_add_library(). Here's the library build type to library target name mapping: | SHARED only | libclang | | STATIC only | libclang | | SHARED and STATIC | libclang and libclang_static | So only when SHARED and STATIC are both set should we loop through two targets. Explicitly parse the STATIC argument and set the list accordingly. Reviewed By: smeenai Differential Revision: https://reviews.llvm.org/D79059
2020-05-07 10:31:46 +08:00
"SHARED;STATIC;INSTALL_WITH_TOOLCHAIN"
Move add_clang_* entry points from the main clang CMakeLists.txt to cmake/modules/AddClang.cmake. This matches how LLVM has its cmake files organized and is cleaner than just shoving this business logic into the main CMakeLists.txt. llvm-svn: 274992
2016-07-10 05:58:40 +08:00
""
"ADDITIONAL_HEADERS"
${ARGN})
set(srcs)
if(MSVC_IDE OR XCODE)
# Add public headers
file(RELATIVE_PATH lib_path
${CLANG_SOURCE_DIR}/lib/
${CMAKE_CURRENT_SOURCE_DIR}
)
if(NOT lib_path MATCHES "^[.][.]")
file( GLOB_RECURSE headers
${CLANG_SOURCE_DIR}/include/clang/${lib_path}/*.h
${CLANG_SOURCE_DIR}/include/clang/${lib_path}/*.def
)
set_source_files_properties(${headers} PROPERTIES HEADER_FILE_ONLY ON)
file( GLOB_RECURSE tds
${CLANG_SOURCE_DIR}/include/clang/${lib_path}/*.td
)
source_group("TableGen descriptions" FILES ${tds})
set_source_files_properties(${tds}} PROPERTIES HEADER_FILE_ONLY ON)
if(headers OR tds)
set(srcs ${headers} ${tds})
endif()
endif()
endif(MSVC_IDE OR XCODE)
if(srcs OR ARG_ADDITIONAL_HEADERS)
set(srcs
ADDITIONAL_HEADERS
${srcs}
${ARG_ADDITIONAL_HEADERS} # It may contain unparsed unknown args.
)
endif()
Reland [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON f8990feb125a enabled installing PIC version of both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC build when LLVM_ENABLE_PIC=OFF with the following error: ``` CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123 (target_compile_definitions): target_compile_definitions called with non-compilable target type ``` This is because as the code loops through ${name} and ${name}_static, it introduced a side effect, which is adding an empty libclang_static to targets. Later target_compile_definitions is called on libclang_static. That function requires that target must have been created by a command such as add_executable() or add_library(), so it crashed. The solution is to not naively loop through both libclang and libclang_static, but only the ones that are actually added by llvm_add_library(). Here's the library build type to library target name mapping: | SHARED only | libclang | | STATIC only | libclang | | SHARED and STATIC | libclang and libclang_static | So only when SHARED and STATIC are both set should we loop through two targets. Explicitly parse the STATIC argument and set the list accordingly. Reviewed By: smeenai Differential Revision: https://reviews.llvm.org/D79059
2020-05-07 10:31:46 +08:00
if(ARG_SHARED AND ARG_STATIC)
set(LIBTYPE SHARED STATIC)
elseif(ARG_SHARED)
Re-land: Add Clang shared library with C++ exports Summary: This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two. This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries. llvm-svn: 360985
2019-05-17 12:20:01 +08:00
set(LIBTYPE SHARED)
else()
Fix BUILD_SHARED_LIBS for clang which broke in D61909 llvm_add_library ignores `BUILD_SHARED_LIBS` `STATIC` is explicitly specified. This restores the `BUILD_SHARED_LIBS` behavior to the clang build. llvm-svn: 361271
2019-05-21 23:56:17 +08:00
# llvm_add_library ignores BUILD_SHARED_LIBS if STATIC is explicitly set,
# so we need to handle it here.
if(BUILD_SHARED_LIBS)
[CMake] Clang: Don't use object libraries with Xcode Undoes some of the effects of r360946 when using the Xcode CMake generator---it doesn't handle object libraries correctly at all. Attempts to still honor BUILD_SHARED_LIBS for Xcode, but I didn't actually test it. Should have no effect on non-Xcode generators. https://reviews.llvm.org/D68430 llvm-svn: 373769
2019-10-05 02:17:58 +08:00
set(LIBTYPE SHARED)
Fix BUILD_SHARED_LIBS for clang which broke in D61909 llvm_add_library ignores `BUILD_SHARED_LIBS` `STATIC` is explicitly specified. This restores the `BUILD_SHARED_LIBS` behavior to the clang build. llvm-svn: 361271
2019-05-21 23:56:17 +08:00
else()
[CMake] Clang: Don't use object libraries with Xcode Undoes some of the effects of r360946 when using the Xcode CMake generator---it doesn't handle object libraries correctly at all. Attempts to still honor BUILD_SHARED_LIBS for Xcode, but I didn't actually test it. Should have no effect on non-Xcode generators. https://reviews.llvm.org/D68430 llvm-svn: 373769
2019-10-05 02:17:58 +08:00
set(LIBTYPE STATIC)
endif()
if(NOT XCODE)
# The Xcode generator doesn't handle object libraries correctly.
list(APPEND LIBTYPE OBJECT)
Fix BUILD_SHARED_LIBS for clang which broke in D61909 llvm_add_library ignores `BUILD_SHARED_LIBS` `STATIC` is explicitly specified. This restores the `BUILD_SHARED_LIBS` behavior to the clang build. llvm-svn: 361271
2019-05-21 23:56:17 +08:00
endif()
Re-land: Add Clang shared library with C++ exports Summary: This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two. This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries. llvm-svn: 360985
2019-05-17 12:20:01 +08:00
set_property(GLOBAL APPEND PROPERTY CLANG_STATIC_LIBS ${name})
Move add_clang_* entry points from the main clang CMakeLists.txt to cmake/modules/AddClang.cmake. This matches how LLVM has its cmake files organized and is cleaner than just shoving this business logic into the main CMakeLists.txt. llvm-svn: 274992
2016-07-10 05:58:40 +08:00
endif()
Re-land: Add Clang shared library with C++ exports Summary: This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two. This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries. llvm-svn: 360985
2019-05-17 12:20:01 +08:00
llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
Move add_clang_* entry points from the main clang CMakeLists.txt to cmake/modules/AddClang.cmake. This matches how LLVM has its cmake files organized and is cleaner than just shoving this business logic into the main CMakeLists.txt. llvm-svn: 274992
2016-07-10 05:58:40 +08:00
Reland [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON f8990feb125a enabled installing PIC version of both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC build when LLVM_ENABLE_PIC=OFF with the following error: ``` CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123 (target_compile_definitions): target_compile_definitions called with non-compilable target type ``` This is because as the code loops through ${name} and ${name}_static, it introduced a side effect, which is adding an empty libclang_static to targets. Later target_compile_definitions is called on libclang_static. That function requires that target must have been created by a command such as add_executable() or add_library(), so it crashed. The solution is to not naively loop through both libclang and libclang_static, but only the ones that are actually added by llvm_add_library(). Here's the library build type to library target name mapping: | SHARED only | libclang | | STATIC only | libclang | | SHARED and STATIC | libclang and libclang_static | So only when SHARED and STATIC are both set should we loop through two targets. Explicitly parse the STATIC argument and set the list accordingly. Reviewed By: smeenai Differential Revision: https://reviews.llvm.org/D79059
2020-05-07 10:31:46 +08:00
set(libs ${name})
if(ARG_SHARED AND ARG_STATIC)
list(APPEND libs ${name}_static)
endif()
Revert f8990feb125a "[libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON" This broke builds configured with $ cmake -GNinja -DCMAKE_BUILD_TYPE=Release '-DLLVM_ENABLE_PROJECTS=clang' '-DLLVM_TARGETS_TO_BUILD=X86' -DLLVM_ENABLE_PIC=OFF ../llvm CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123 (target_compile_definitions): target_compile_definitions called with non-compilable target type This reverts commit f8990feb125a0f8d3f2892a589bc6fad3c430858.
2020-04-28 16:10:33 +08:00
Reland [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON f8990feb125a enabled installing PIC version of both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC build when LLVM_ENABLE_PIC=OFF with the following error: ``` CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123 (target_compile_definitions): target_compile_definitions called with non-compilable target type ``` This is because as the code loops through ${name} and ${name}_static, it introduced a side effect, which is adding an empty libclang_static to targets. Later target_compile_definitions is called on libclang_static. That function requires that target must have been created by a command such as add_executable() or add_library(), so it crashed. The solution is to not naively loop through both libclang and libclang_static, but only the ones that are actually added by llvm_add_library(). Here's the library build type to library target name mapping: | SHARED only | libclang | | STATIC only | libclang | | SHARED and STATIC | libclang and libclang_static | So only when SHARED and STATIC are both set should we loop through two targets. Explicitly parse the STATIC argument and set the list accordingly. Reviewed By: smeenai Differential Revision: https://reviews.llvm.org/D79059
2020-05-07 10:31:46 +08:00
foreach(lib ${libs})
if(TARGET ${lib})
target_link_libraries(${lib} INTERFACE ${LLVM_COMMON_LIBS})
if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
[cmake] Add support for multiple distributions LLVM's build system contains support for configuring a distribution, but it can often be useful to be able to configure multiple distributions (e.g. if you want separate distributions for the tools and the libraries). Add this support to the build system, along with documentation and usage examples. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D89177
2020-10-02 05:35:28 +08:00
get_target_export_arg(${name} Clang export_to_clangtargets UMBRELLA clang-libraries)
Reland [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON f8990feb125a enabled installing PIC version of both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC build when LLVM_ENABLE_PIC=OFF with the following error: ``` CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123 (target_compile_definitions): target_compile_definitions called with non-compilable target type ``` This is because as the code loops through ${name} and ${name}_static, it introduced a side effect, which is adding an empty libclang_static to targets. Later target_compile_definitions is called on libclang_static. That function requires that target must have been created by a command such as add_executable() or add_library(), so it crashed. The solution is to not naively loop through both libclang and libclang_static, but only the ones that are actually added by llvm_add_library(). Here's the library build type to library target name mapping: | SHARED only | libclang | | STATIC only | libclang | | SHARED and STATIC | libclang and libclang_static | So only when SHARED and STATIC are both set should we loop through two targets. Explicitly parse the STATIC argument and set the list accordingly. Reviewed By: smeenai Differential Revision: https://reviews.llvm.org/D79059
2020-05-07 10:31:46 +08:00
install(TARGETS ${lib}
COMPONENT ${lib}
${export_to_clangtargets}
LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX}
ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX}
RUNTIME DESTINATION bin)
if (NOT LLVM_ENABLE_IDE)
add_llvm_install_targets(install-${lib}
DEPENDS ${lib}
COMPONENT ${lib})
endif()
set_property(GLOBAL APPEND PROPERTY CLANG_LIBS ${lib})
Revert f8990feb125a "[libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON" This broke builds configured with $ cmake -GNinja -DCMAKE_BUILD_TYPE=Release '-DLLVM_ENABLE_PROJECTS=clang' '-DLLVM_TARGETS_TO_BUILD=X86' -DLLVM_ENABLE_PIC=OFF ../llvm CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123 (target_compile_definitions): target_compile_definitions called with non-compilable target type This reverts commit f8990feb125a0f8d3f2892a589bc6fad3c430858.
2020-04-28 16:10:33 +08:00
endif()
Reland [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON f8990feb125a enabled installing PIC version of both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC build when LLVM_ENABLE_PIC=OFF with the following error: ``` CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123 (target_compile_definitions): target_compile_definitions called with non-compilable target type ``` This is because as the code loops through ${name} and ${name}_static, it introduced a side effect, which is adding an empty libclang_static to targets. Later target_compile_definitions is called on libclang_static. That function requires that target must have been created by a command such as add_executable() or add_library(), so it crashed. The solution is to not naively loop through both libclang and libclang_static, but only the ones that are actually added by llvm_add_library(). Here's the library build type to library target name mapping: | SHARED only | libclang | | STATIC only | libclang | | SHARED and STATIC | libclang and libclang_static | So only when SHARED and STATIC are both set should we loop through two targets. Explicitly parse the STATIC argument and set the list accordingly. Reviewed By: smeenai Differential Revision: https://reviews.llvm.org/D79059
2020-05-07 10:31:46 +08:00
set_property(GLOBAL APPEND PROPERTY CLANG_EXPORTS ${lib})
else()
# Add empty "phony" target
add_custom_target(${lib})
Move add_clang_* entry points from the main clang CMakeLists.txt to cmake/modules/AddClang.cmake. This matches how LLVM has its cmake files organized and is cleaner than just shoving this business logic into the main CMakeLists.txt. llvm-svn: 274992
2016-07-10 05:58:40 +08:00
endif()
Reland [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON f8990feb125a enabled installing PIC version of both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC is ON. But it broke the no-PIC build when LLVM_ENABLE_PIC=OFF with the following error: ``` CMake Error at /b/s/w/ir/cache/builder/src/third_party/llvm/clang/tools/libclang/CMakeLists.txt:123 (target_compile_definitions): target_compile_definitions called with non-compilable target type ``` This is because as the code loops through ${name} and ${name}_static, it introduced a side effect, which is adding an empty libclang_static to targets. Later target_compile_definitions is called on libclang_static. That function requires that target must have been created by a command such as add_executable() or add_library(), so it crashed. The solution is to not naively loop through both libclang and libclang_static, but only the ones that are actually added by llvm_add_library(). Here's the library build type to library target name mapping: | SHARED only | libclang | | STATIC only | libclang | | SHARED and STATIC | libclang and libclang_static | So only when SHARED and STATIC are both set should we loop through two targets. Explicitly parse the STATIC argument and set the list accordingly. Reviewed By: smeenai Differential Revision: https://reviews.llvm.org/D79059
2020-05-07 10:31:46 +08:00
endforeach()
Move add_clang_* entry points from the main clang CMakeLists.txt to cmake/modules/AddClang.cmake. This matches how LLVM has its cmake files organized and is cleaner than just shoving this business logic into the main CMakeLists.txt. llvm-svn: 274992
2016-07-10 05:58:40 +08:00
set_target_properties(${name} PROPERTIES FOLDER "Clang libraries")
set_clang_windows_version_resource_properties(${name})
endmacro(add_clang_library)
macro(add_clang_executable name)
add_llvm_executable( ${name} ${ARGN} )
set_target_properties(${name} PROPERTIES FOLDER "Clang executables")
set_clang_windows_version_resource_properties(${name})
endmacro(add_clang_executable)
macro(add_clang_tool name)
Add CLANG_BUILD_TOOLS as a clang counterpart for LLVM_BUILD_TOOLS LLVM_BUILD_TOOLS is a boolean variable that controls whether or not generated targets for llvm tools are built by the "all" target. CLANG_BUILD_TOOLS is an analogous variable for clang targets. This is useful functionality for selectively disabling the building of clang targets by default to speed up builds. In terms of implementation, I just followed the model of LLVM's implementation of this functionality. llvm-svn: 275006
2016-07-10 09:44:00 +08:00
if (NOT CLANG_BUILD_TOOLS)
set(EXCLUDE_FROM_ALL ON)
endif()
Move add_clang_* entry points from the main clang CMakeLists.txt to cmake/modules/AddClang.cmake. This matches how LLVM has its cmake files organized and is cleaner than just shoving this business logic into the main CMakeLists.txt. llvm-svn: 274992
2016-07-10 05:58:40 +08:00
add_clang_executable(${name} ${ARGN})
[build] Rename clang-headers to clang-resource-headers Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 llvm-svn: 355340
2019-03-05 05:19:53 +08:00
add_dependencies(${name} clang-resource-headers)
Add CLANG_BUILD_TOOLS as a clang counterpart for LLVM_BUILD_TOOLS LLVM_BUILD_TOOLS is a boolean variable that controls whether or not generated targets for llvm tools are built by the "all" target. CLANG_BUILD_TOOLS is an analogous variable for clang targets. This is useful functionality for selectively disabling the building of clang targets by default to speed up builds. In terms of implementation, I just followed the model of LLVM's implementation of this functionality. llvm-svn: 275006
2016-07-10 09:44:00 +08:00
if (CLANG_BUILD_TOOLS)
[cmake] Add support for multiple distributions LLVM's build system contains support for configuring a distribution, but it can often be useful to be able to configure multiple distributions (e.g. if you want separate distributions for the tools and the libraries). Add this support to the build system, along with documentation and usage examples. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D89177
2020-10-02 05:35:28 +08:00
get_target_export_arg(${name} Clang export_to_clangtargets)
Add CLANG_BUILD_TOOLS as a clang counterpart for LLVM_BUILD_TOOLS LLVM_BUILD_TOOLS is a boolean variable that controls whether or not generated targets for llvm tools are built by the "all" target. CLANG_BUILD_TOOLS is an analogous variable for clang targets. This is useful functionality for selectively disabling the building of clang targets by default to speed up builds. In terms of implementation, I just followed the model of LLVM's implementation of this functionality. llvm-svn: 275006
2016-07-10 09:44:00 +08:00
install(TARGETS ${name}
cmake: Support exports correctly with LLVM_DISTRIBUTION_COMPONENTS We need to apply the same export logic in clang as in llvm for LLVM_DISTRIBUTION_COMPONENTS, or the clang exports will be invalid when we use this config. This makes using distribution components without setting LLVM_TOOLCHAIN_ONLY=On work correctly. llvm-svn: 286181
2016-11-08 07:46:05 +08:00
${export_to_clangtargets}
Add CLANG_BUILD_TOOLS as a clang counterpart for LLVM_BUILD_TOOLS LLVM_BUILD_TOOLS is a boolean variable that controls whether or not generated targets for llvm tools are built by the "all" target. CLANG_BUILD_TOOLS is an analogous variable for clang targets. This is useful functionality for selectively disabling the building of clang targets by default to speed up builds. In terms of implementation, I just followed the model of LLVM's implementation of this functionality. llvm-svn: 275006
2016-07-10 09:44:00 +08:00
RUNTIME DESTINATION bin
COMPONENT ${name})
[clang] Switch to LLVM_ENABLE_IDE r344555 switched LLVM to guarding install targets with LLVM_ENABLE_IDE instead of CMAKE_CONFIGURATION_TYPES, which expresses the intent more directly and can be overridden by a user. Make the corresponding change in clang. LLVM_ENABLE_IDE is computed by HandleLLVMOptions, so it should be available for both standalone and integrated builds. Differential Revision: https://reviews.llvm.org/D58284 llvm-svn: 354525
2019-02-21 07:08:43 +08:00
if(NOT LLVM_ENABLE_IDE)
[clang] Use add_llvm_install_targets Use this function to create the install targets rather than doing so manually, which gains us the `-stripped` install targets to perform stripped installations. Differential Revision: https://reviews.llvm.org/D40675 llvm-svn: 319489
2017-12-01 06:35:02 +08:00
add_llvm_install_targets(install-${name}
DEPENDS ${name}
COMPONENT ${name})
Add CLANG_BUILD_TOOLS as a clang counterpart for LLVM_BUILD_TOOLS LLVM_BUILD_TOOLS is a boolean variable that controls whether or not generated targets for llvm tools are built by the "all" target. CLANG_BUILD_TOOLS is an analogous variable for clang targets. This is useful functionality for selectively disabling the building of clang targets by default to speed up builds. In terms of implementation, I just followed the model of LLVM's implementation of this functionality. llvm-svn: 275006
2016-07-10 09:44:00 +08:00
endif()
[cmake] Follow LLVM's lead in creating exported tool targets for clang tools. This is needed by downstream projects such as swift to get proper cmake dependency information for LLVM/Clang targets. A few months ago I added support for exporting this information for Clang libraries. In order to be incremental, I did not add support for exporting clang tools as well at that time. Now such support is needed, so I am committing this incremental code. llvm-svn: 284658
2016-10-20 06:46:06 +08:00
set_property(GLOBAL APPEND PROPERTY CLANG_EXPORTS ${name})
Move add_clang_* entry points from the main clang CMakeLists.txt to cmake/modules/AddClang.cmake. This matches how LLVM has its cmake files organized and is cleaner than just shoving this business logic into the main CMakeLists.txt. llvm-svn: 274992
2016-07-10 05:58:40 +08:00
endif()
endmacro()
macro(add_clang_symlink name dest)
add_llvm_tool_symlink(${name} ${dest} ALWAYS_GENERATE)
# Always generate install targets
llvm_install_symlink(${name} ${dest} ALWAYS_GENERATE)
endmacro()
cmake: Add CLANG_LINK_CLANG_DYLIB option Summary: Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against libclang_shared.so instead of the individual component libraries. Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru Subscribers: arphaman, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63503 llvm-svn: 365092
2019-07-04 06:45:55 +08:00
function(clang_target_link_libraries target type)
if (CLANG_LINK_CLANG_DYLIB)
Rename libclang_shared to libclang-cpp Summary: Fix bug 42475 Reviewers: beanz, tstellar Reviewed By: beanz Subscribers: kimgr, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64278 llvm-svn: 365831
2019-07-12 05:42:55 +08:00
target_link_libraries(${target} ${type} clang-cpp)
cmake: Add CLANG_LINK_CLANG_DYLIB option Summary: Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against libclang_shared.so instead of the individual component libraries. Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru Subscribers: arphaman, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63503 llvm-svn: 365092
2019-07-04 06:45:55 +08:00
else()
target_link_libraries(${target} ${type} ${ARGN})
endif()
endfunction()