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/CMakeLists.txt

58 lines
2.5 KiB
CMake
Raw Normal View History

[cmake] Move creation of ClangTargets and installation of ClangConfig.cmake from ./CMakeLists.txt -> ./cmake/modules/CMakeLists.txt. This matches LLVM. llvm-svn: 274157
2016-06-30 04:22:44 +08:00
# Generate a list of CMake library targets so that other CMake projects can
# link against them. LLVM calls its version of this file LLVMExports.cmake, but
# the usual CMake convention seems to be ${Project}Targets.cmake.
set(CLANG_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/clang)
set(clang_cmake_builddir "${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}")
[cmake] Instead of just copying ClangConfig.cmake, configure it using ClangConfig.cmake.in. This will allow for cmake to expand variables in ClangConfig.cmake for downstream users. llvm-svn: 274176
2016-06-30 05:59:14 +08:00
[cmake] Hint find_package() to prefer LLVM installed alongside clang Include a path hint for find_package() in ClangConfig.cmake to ensure that CMake prefers LLVM installed alongside clang over the default search path. If two versions of LLVM are installed in the system, and one of them is in PATH, CMake's find_package() magic prefers the CMake directory alongside that install by default. Adding a relative hint makes it possible to prioritize to the install from which find_package() is called. If you want to build e.g. LLDB against another install of LLVM, you can pass LLVM_CONFIG override. In this case, LLDB queries the prefix from llvm-config and uses the CMake files located there. However, when including ClangConfig, the implicit find_package() nevertheless prefers PATH-found LLVM over the one used previously by LLDB, and two versions of LLVMConfig end up being loaded. This could be fixed on LLDB end up by explicitly forcing custom package search location. However, it seems simpler and safer to add a hint to ClangConfig than to track every usage of ClangConfig. Differential Revision: https://reviews.llvm.org/D29304 llvm-svn: 293632
2017-01-31 22:15:40 +08:00
# Keep this in sync with llvm/cmake/CMakeLists.txt!
set(LLVM_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm)
set(llvm_cmake_builddir "${LLVM_BINARY_DIR}/${LLVM_INSTALL_PACKAGE_DIR}")
[cmake] Move creation of ClangTargets and installation of ClangConfig.cmake from ./CMakeLists.txt -> ./cmake/modules/CMakeLists.txt. This matches LLVM. llvm-svn: 274157
2016-06-30 04:22:44 +08:00
get_property(CLANG_EXPORTS GLOBAL PROPERTY CLANG_EXPORTS)
export(TARGETS ${CLANG_EXPORTS} FILE ${clang_cmake_builddir}/ClangTargets.cmake)
[cmake] Instead of just copying ClangConfig.cmake, configure it using ClangConfig.cmake.in. This will allow for cmake to expand variables in ClangConfig.cmake for downstream users. llvm-svn: 274176
2016-06-30 05:59:14 +08:00
# Generate ClangConfig.cmake for the build tree.
[ClangConfig] Instead of hard coding the ClangTargets location to /ClangTargets.cmake, follow LLVM's example and use a pre-computed cmake variable @CLANG_CONFIG_EXPORTS_FILE@. This just makes ClangConfig more consistent with LLVMConfig. llvm-svn: 274178
2016-06-30 05:59:19 +08:00
set(CLANG_CONFIG_CMAKE_DIR "${clang_cmake_builddir}")
[cmake] Hint find_package() to prefer LLVM installed alongside clang Include a path hint for find_package() in ClangConfig.cmake to ensure that CMake prefers LLVM installed alongside clang over the default search path. If two versions of LLVM are installed in the system, and one of them is in PATH, CMake's find_package() magic prefers the CMake directory alongside that install by default. Adding a relative hint makes it possible to prioritize to the install from which find_package() is called. If you want to build e.g. LLDB against another install of LLVM, you can pass LLVM_CONFIG override. In this case, LLDB queries the prefix from llvm-config and uses the CMake files located there. However, when including ClangConfig, the implicit find_package() nevertheless prefers PATH-found LLVM over the one used previously by LLDB, and two versions of LLVMConfig end up being loaded. This could be fixed on LLDB end up by explicitly forcing custom package search location. However, it seems simpler and safer to add a hint to ClangConfig than to track every usage of ClangConfig. Differential Revision: https://reviews.llvm.org/D29304 llvm-svn: 293632
2017-01-31 22:15:40 +08:00
set(CLANG_CONFIG_LLVM_CMAKE_DIR "${llvm_cmake_builddir}")
[ClangConfig] Instead of hard coding the ClangTargets location to /ClangTargets.cmake, follow LLVM's example and use a pre-computed cmake variable @CLANG_CONFIG_EXPORTS_FILE@. This just makes ClangConfig more consistent with LLVMConfig. llvm-svn: 274178
2016-06-30 05:59:19 +08:00
set(CLANG_CONFIG_EXPORTS_FILE "${clang_cmake_builddir}/ClangTargets.cmake")
[cmake] Instead of just copying ClangConfig.cmake, configure it using ClangConfig.cmake.in. This will allow for cmake to expand variables in ClangConfig.cmake for downstream users. llvm-svn: 274176
2016-06-30 05:59:14 +08:00
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
${clang_cmake_builddir}/ClangConfig.cmake
@ONLY)
[ClangConfig] Unset some variables after we are done using them to configure ClangConfig.cmake.in files. This ensures that the values do not bleed over in between computations. It may make sense in the future to just refactor this code into functions to provide "true scoping". llvm-svn: 274179
2016-06-30 05:59:20 +08:00
set(CLANG_CONFIG_CMAKE_DIR)
[cmake] Hint find_package() to prefer LLVM installed alongside clang Include a path hint for find_package() in ClangConfig.cmake to ensure that CMake prefers LLVM installed alongside clang over the default search path. If two versions of LLVM are installed in the system, and one of them is in PATH, CMake's find_package() magic prefers the CMake directory alongside that install by default. Adding a relative hint makes it possible to prioritize to the install from which find_package() is called. If you want to build e.g. LLDB against another install of LLVM, you can pass LLVM_CONFIG override. In this case, LLDB queries the prefix from llvm-config and uses the CMake files located there. However, when including ClangConfig, the implicit find_package() nevertheless prefers PATH-found LLVM over the one used previously by LLDB, and two versions of LLVMConfig end up being loaded. This could be fixed on LLDB end up by explicitly forcing custom package search location. However, it seems simpler and safer to add a hint to ClangConfig than to track every usage of ClangConfig. Differential Revision: https://reviews.llvm.org/D29304 llvm-svn: 293632
2017-01-31 22:15:40 +08:00
set(CLANG_CONFIG_LLVM_CMAKE_DIR)
[ClangConfig] Unset some variables after we are done using them to configure ClangConfig.cmake.in files. This ensures that the values do not bleed over in between computations. It may make sense in the future to just refactor this code into functions to provide "true scoping". llvm-svn: 274179
2016-06-30 05:59:20 +08:00
set(CLANG_CONFIG_EXPORTS_FILE)
[cmake] Instead of just copying ClangConfig.cmake, configure it using ClangConfig.cmake.in. This will allow for cmake to expand variables in ClangConfig.cmake for downstream users. llvm-svn: 274176
2016-06-30 05:59:14 +08:00
# Generate ClangConfig.cmake for the install tree.
[ClangConfig] Instead of hard coding the ClangTargets location to /ClangTargets.cmake, follow LLVM's example and use a pre-computed cmake variable @CLANG_CONFIG_EXPORTS_FILE@. This just makes ClangConfig more consistent with LLVMConfig. llvm-svn: 274178
2016-06-30 05:59:19 +08:00
set(CLANG_CONFIG_CODE "
# Compute the installation prefix from this LLVMConfig.cmake file location.
get_filename_component(CLANG_INSTALL_PREFIX \"\${CMAKE_CURRENT_LIST_FILE}\" PATH)")
# Construct the proper number of get_filename_component(... PATH)
# calls to compute the installation prefix.
string(REGEX REPLACE "/" ";" _count "${CLANG_INSTALL_PACKAGE_DIR}")
foreach(p ${_count})
set(CLANG_CONFIG_CODE "${CLANG_CONFIG_CODE}
get_filename_component(CLANG_INSTALL_PREFIX \"\${CLANG_INSTALL_PREFIX}\" PATH)")
endforeach(p)
[ClangConfig] Store all of the targets exported in the variable CLANG_EXPORTED_TARGETS. llvm-svn: 274180
2016-06-30 05:59:23 +08:00
set(CLANG_CONFIG_CMAKE_DIR "\${CLANG_INSTALL_PREFIX}/${CLANG_INSTALL_PACKAGE_DIR}")
[cmake] Hint find_package() to prefer LLVM installed alongside clang Include a path hint for find_package() in ClangConfig.cmake to ensure that CMake prefers LLVM installed alongside clang over the default search path. If two versions of LLVM are installed in the system, and one of them is in PATH, CMake's find_package() magic prefers the CMake directory alongside that install by default. Adding a relative hint makes it possible to prioritize to the install from which find_package() is called. If you want to build e.g. LLDB against another install of LLVM, you can pass LLVM_CONFIG override. In this case, LLDB queries the prefix from llvm-config and uses the CMake files located there. However, when including ClangConfig, the implicit find_package() nevertheless prefers PATH-found LLVM over the one used previously by LLDB, and two versions of LLVMConfig end up being loaded. This could be fixed on LLDB end up by explicitly forcing custom package search location. However, it seems simpler and safer to add a hint to ClangConfig than to track every usage of ClangConfig. Differential Revision: https://reviews.llvm.org/D29304 llvm-svn: 293632
2017-01-31 22:15:40 +08:00
set(CLANG_CONFIG_LLVM_CMAKE_DIR "\${CLANG_INSTALL_PREFIX}/${LLVM_INSTALL_PACKAGE_DIR}")
[ClangConfig] Instead of hard coding the ClangTargets location to /ClangTargets.cmake, follow LLVM's example and use a pre-computed cmake variable @CLANG_CONFIG_EXPORTS_FILE@. This just makes ClangConfig more consistent with LLVMConfig. llvm-svn: 274178
2016-06-30 05:59:19 +08:00
set(CLANG_CONFIG_EXPORTS_FILE "\${CLANG_CMAKE_DIR}/ClangTargets.cmake")
[cmake] Instead of just copying ClangConfig.cmake, configure it using ClangConfig.cmake.in. This will allow for cmake to expand variables in ClangConfig.cmake for downstream users. llvm-svn: 274176
2016-06-30 05:59:14 +08:00
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
@ONLY)
[ClangConfig] Unset some variables after we are done using them to configure ClangConfig.cmake.in files. This ensures that the values do not bleed over in between computations. It may make sense in the future to just refactor this code into functions to provide "true scoping". llvm-svn: 274179
2016-06-30 05:59:20 +08:00
set(CLANG_CONFIG_CODE)
set(CLANG_CONFIG_CMAKE_DIR)
set(CLANG_CONFIG_EXPORTS_FILE)
[cmake] Instead of just copying ClangConfig.cmake, configure it using ClangConfig.cmake.in. This will allow for cmake to expand variables in ClangConfig.cmake for downstream users. llvm-svn: 274176
2016-06-30 05:59:14 +08:00
[ClangConfig] Follow LLVM's example and only install Clang{Config,Target}.cmake when LLVM_INSTALL_TOOLCHAIN_ONLY is disabled. llvm-svn: 274177
2016-06-30 05:59:15 +08:00
if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
cmake: Don't try to install exports if there aren't any When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for clang's export list to be empty. If this happens the install(EXPORTS) command will fail, but since there isn't anything to install anyway we really just want to skip it. llvm-svn: 286210
2016-11-08 13:02:33 +08:00
get_property(clang_has_exports GLOBAL PROPERTY CLANG_HAS_EXPORTS)
if(clang_has_exports)
install(EXPORT ClangTargets DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
endif()
[cmake] Move creation of ClangTargets and installation of ClangConfig.cmake from ./CMakeLists.txt -> ./cmake/modules/CMakeLists.txt. This matches LLVM. llvm-svn: 274157
2016-06-30 04:22:44 +08:00
[ClangConfig] Follow LLVM's example and only install Clang{Config,Target}.cmake when LLVM_INSTALL_TOOLCHAIN_ONLY is disabled. llvm-svn: 274177
2016-06-30 05:59:15 +08:00
install(FILES
${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake
DESTINATION ${CLANG_INSTALL_PACKAGE_DIR})
endif()