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

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

341 lines
13 KiB
CMake
Raw Normal View History

Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
function(get_system_libs return_var)
Simplify linking to system libraries The LLVMSupport library implementation consolidates all dependencies on system libraries. Move the logic gathering system libraries out of 'cmake/modules/LLVM-Config.cmake' and into 'lib/Support/CMakeLists.txt'. Use the target_link_libraries() command there to tell CMake about the link dependencies of the LLVMSupport implementation. CMake will automatically propagate this to all targets that link LLVMSupport directly or indirectly. We still need to build knowledge of system library dependencies into 'llvm-config'. Store the list of libraries needed in a property on LLVMSupport and teach 'tools/llvm-config/CMakeLists.txt' to retrieve it from there. Drop all calls to 'link_system_libs' and 'get_system_libs' from our CMake code. Replace their implementations with a warning that explains the calls are no longer necessary. Also drop from 'LLVMConfig.cmake' the HAVE_* and related variables that were published there only to allow 'get_system_libs' to run outside our build process. Contributed by Brad King. llvm-svn: 201969
2014-02-23 14:27:04 +08:00
message(AUTHOR_WARNING "get_system_libs no longer needed")
set(${return_var} "" PARENT_SCOPE)
endfunction()
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
Fixed the build of Clang's unit tests on MinGW. Also removed some unnecesary conditionals and introduced a new convenience function. The problem was that the list of libraries for Clang's unit tests was <clang libraries> <system libraries> <llvm libraries>. As the llvm libraries references symbols defined on the system libraries, those were reported as undefined. llvm-svn: 128484
2011-03-30 04:51:08 +08:00
function(link_system_libs target)
Simplify linking to system libraries The LLVMSupport library implementation consolidates all dependencies on system libraries. Move the logic gathering system libraries out of 'cmake/modules/LLVM-Config.cmake' and into 'lib/Support/CMakeLists.txt'. Use the target_link_libraries() command there to tell CMake about the link dependencies of the LLVMSupport implementation. CMake will automatically propagate this to all targets that link LLVMSupport directly or indirectly. We still need to build knowledge of system library dependencies into 'llvm-config'. Store the list of libraries needed in a property on LLVMSupport and teach 'tools/llvm-config/CMakeLists.txt' to retrieve it from there. Drop all calls to 'link_system_libs' and 'get_system_libs' from our CMake code. Replace their implementations with a warning that explains the calls are no longer necessary. Also drop from 'LLVMConfig.cmake' the HAVE_* and related variables that were published there only to allow 'get_system_libs' to run outside our build process. Contributed by Brad King. llvm-svn: 201969
2014-02-23 14:27:04 +08:00
message(AUTHOR_WARNING "link_system_libs no longer needed")
endfunction()
Fixed the build of Clang's unit tests on MinGW. Also removed some unnecesary conditionals and introduced a new convenience function. The problem was that the list of libraries for Clang's unit tests was <clang libraries> <system libraries> <llvm libraries>. As the llvm libraries references symbols defined on the system libraries, those were reported as undefined. llvm-svn: 128484
2011-03-30 04:51:08 +08:00
[CMake] Fix `is_llvm_target_library` and support out-of-order components Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
2017-02-09 04:58:37 +08:00
# is_llvm_target_library(
# library
# Name of the LLVM library to check
# return_var
# Output variable name
# ALL_TARGETS;INCLUDED_TARGETS;OMITTED_TARGETS
# ALL_TARGETS - default looks at the full list of known targets
# INCLUDED_TARGETS - looks only at targets being configured
# OMITTED_TARGETS - looks only at targets that are not being configured
# )
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
function(is_llvm_target_library library return_var)
[CMake] Fix `is_llvm_target_library` and support out-of-order components Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
2017-02-09 04:58:37 +08:00
cmake_parse_arguments(ARG "ALL_TARGETS;INCLUDED_TARGETS;OMITTED_TARGETS" "" "" ${ARGN})
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
# Sets variable `return_var' to ON if `library' corresponds to a
# LLVM supported target. To OFF if it doesn't.
set(${return_var} OFF PARENT_SCOPE)
string(TOUPPER "${library}" capitalized_lib)
[CMake] Fix `is_llvm_target_library` and support out-of-order components Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
2017-02-09 04:58:37 +08:00
if(ARG_INCLUDED_TARGETS)
string(TOUPPER "${LLVM_TARGETS_TO_BUILD}" targets)
elseif(ARG_OMITTED_TARGETS)
set(omitted_targets ${LLVM_ALL_TARGETS})
Fix use of add_llvm_tool in projects that build no targets Projects that set LLVM_TARGETS_TO_BUILD to an empty list can't use add_llvm_tool (and probably other macros). Here's the error that this change fixes: list sub-command REMOVE_ITEM requires two or more arguments. https://reviews.llvm.org/D70167 Signed-off-by: Kevin Petit <kevin.petit@arm.com>
2019-11-13 17:29:10 +08:00
list(REMOVE_ITEM omitted_targets "${LLVM_TARGETS_TO_BUILD}")
[CMake] Fix `is_llvm_target_library` and support out-of-order components Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
2017-02-09 04:58:37 +08:00
string(TOUPPER "${omitted_targets}" targets)
else()
string(TOUPPER "${LLVM_ALL_TARGETS}" targets)
endif()
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
foreach(t ${targets})
is_llvm_target_library: recognize libraries without the LLVM prefix. Without this cmake fails at configuration when some target pass "native" on LLVM_LINK_COMPONENTS and that is expanded to "X86". llvm-svn: 127679
2011-03-15 22:53:53 +08:00
if( capitalized_lib STREQUAL t OR
[CMake] Fix `is_llvm_target_library` and support out-of-order components Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
2017-02-09 04:58:37 +08:00
capitalized_lib STREQUAL "${t}" OR
capitalized_lib STREQUAL "${t}DESC" OR
capitalized_lib STREQUAL "${t}CODEGEN" OR
capitalized_lib STREQUAL "${t}ASMPARSER" OR
capitalized_lib STREQUAL "${t}ASMPRINTER" OR
capitalized_lib STREQUAL "${t}DISASSEMBLER" OR
capitalized_lib STREQUAL "${t}INFO" OR
capitalized_lib STREQUAL "${t}UTILS" )
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
set(${return_var} ON PARENT_SCOPE)
break()
endif()
endforeach()
endfunction(is_llvm_target_library)
[CMake] Fix `is_llvm_target_library` and support out-of-order components Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
2017-02-09 04:58:37 +08:00
function(is_llvm_target_specifier library return_var)
is_llvm_target_library(${library} ${return_var} ${ARGN})
string(TOUPPER "${library}" capitalized_lib)
if(NOT ${return_var})
if( capitalized_lib STREQUAL "ALLTARGETSASMPARSERS" OR
capitalized_lib STREQUAL "ALLTARGETSDESCS" OR
capitalized_lib STREQUAL "ALLTARGETSDISASSEMBLERS" OR
capitalized_lib STREQUAL "ALLTARGETSINFOS" OR
capitalized_lib STREQUAL "NATIVE" OR
capitalized_lib STREQUAL "NATIVECODEGEN" )
set(${return_var} ON PARENT_SCOPE)
endif()
endif()
endfunction()
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
macro(llvm_config executable)
[cmake] rework LLVM_LINK_LLVM_DYLIB option handling Summary: This diff attempts to address the concerns raised in http://reviews.llvm.org/D12488. We introduce a new USE_SHARED option to llvm_config, which, if set, causes the target to be linked against libLLVM. add_llvm_utility now uniformly disables linking against libLLVM. These utilities are not intended for distribution, and this keeps the option handling more centralised. llvm-shlib is now processes before any other "tools" subdirectories, ensuring the libLLVM target is defined before its dependents. One main difference from what was requested: llvm_config does not prune LLVM_DYLIB_COMPONENTS from the components passed into explicit_llvm_config. This is because the "all" component does something special, adding additional libraries (namely libLTO). Adding the component libraries after libLLVM should not be a problem, as symbols will be resolved in libLLVM first. Finally, I'm not really happy with the DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a better way to get the following: - link all tools and shared libraries to libLLVM if LLVM_LINK_LLVM_DYLIB is set - some way of explicitly *not* doing so for utilities and libLLVM itself Suggestions for improvement here are particularly welcome. Reviewers: beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12590 llvm-svn: 246918
2015-09-05 16:27:33 +08:00
cmake_parse_arguments(ARG "USE_SHARED" "" "" ${ARGN})
set(link_components ${ARG_UNPARSED_ARGUMENTS})
[cmake] fix a typo in llvm_config macro Summary: The macro parses out the USE_SHARED option out of the argument list, but then ignores it and accesses the variable with the same name instead. It seems the intention here was to check the argument value. Technically, this is NFC, because the only in-tree usage (add_llvm_executable) of USE_SHARED sets both the variable and the argument when calling llvm_config, but it makes the usage of this macro for out-of-tree users more sensible. Reviewers: mgorny, beanz Reviewed By: mgorny Subscribers: foutrelis, llvm-commits Differential Revision: https://reviews.llvm.org/D44420 llvm-svn: 334082
2018-06-06 18:07:08 +08:00
if(ARG_USE_SHARED)
[cmake] rework LLVM_LINK_LLVM_DYLIB option handling Summary: This diff attempts to address the concerns raised in http://reviews.llvm.org/D12488. We introduce a new USE_SHARED option to llvm_config, which, if set, causes the target to be linked against libLLVM. add_llvm_utility now uniformly disables linking against libLLVM. These utilities are not intended for distribution, and this keeps the option handling more centralised. llvm-shlib is now processes before any other "tools" subdirectories, ensuring the libLLVM target is defined before its dependents. One main difference from what was requested: llvm_config does not prune LLVM_DYLIB_COMPONENTS from the components passed into explicit_llvm_config. This is because the "all" component does something special, adding additional libraries (namely libLTO). Adding the component libraries after libLLVM should not be a problem, as symbols will be resolved in libLLVM first. Finally, I'm not really happy with the DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a better way to get the following: - link all tools and shared libraries to libLLVM if LLVM_LINK_LLVM_DYLIB is set - some way of explicitly *not* doing so for utilities and libLLVM itself Suggestions for improvement here are particularly welcome. Reviewers: beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12590 llvm-svn: 246918
2015-09-05 16:27:33 +08:00
# If USE_SHARED is specified, then we link against libLLVM,
# but also against the component libraries below. This is
# done in case libLLVM does not contain all of the components
# the target requires.
#
Avoid linking LLVM component libraries with libLLVM Patch by Jack Howarth. When linking to libLLVM, don't also link to the component libraries that constitute libLLVM. Differential Revision: http://reviews.llvm.org/D16945 llvm-svn: 260641
2016-02-12 09:42:43 +08:00
# Strip LLVM_DYLIB_COMPONENTS out of link_components.
[cmake] rework LLVM_LINK_LLVM_DYLIB option handling Summary: This diff attempts to address the concerns raised in http://reviews.llvm.org/D12488. We introduce a new USE_SHARED option to llvm_config, which, if set, causes the target to be linked against libLLVM. add_llvm_utility now uniformly disables linking against libLLVM. These utilities are not intended for distribution, and this keeps the option handling more centralised. llvm-shlib is now processes before any other "tools" subdirectories, ensuring the libLLVM target is defined before its dependents. One main difference from what was requested: llvm_config does not prune LLVM_DYLIB_COMPONENTS from the components passed into explicit_llvm_config. This is because the "all" component does something special, adding additional libraries (namely libLTO). Adding the component libraries after libLLVM should not be a problem, as symbols will be resolved in libLLVM first. Finally, I'm not really happy with the DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a better way to get the following: - link all tools and shared libraries to libLLVM if LLVM_LINK_LLVM_DYLIB is set - some way of explicitly *not* doing so for utilities and libLLVM itself Suggestions for improvement here are particularly welcome. Reviewers: beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12590 llvm-svn: 246918
2015-09-05 16:27:33 +08:00
# To do this, we need special handling for "all", since that
# may imply linking to libraries that are not included in
# libLLVM.
Avoid linking LLVM component libraries with libLLVM Patch by Jack Howarth. When linking to libLLVM, don't also link to the component libraries that constitute libLLVM. Differential Revision: http://reviews.llvm.org/D16945 llvm-svn: 260641
2016-02-12 09:42:43 +08:00
if (DEFINED link_components AND DEFINED LLVM_DYLIB_COMPONENTS)
if("${LLVM_DYLIB_COMPONENTS}" STREQUAL "all")
set(link_components "")
else()
list(REMOVE_ITEM link_components ${LLVM_DYLIB_COMPONENTS})
endif()
endif()
[CMake] Use PRIVATE in target_link_libraries for executables We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
2017-12-06 05:49:56 +08:00
target_link_libraries(${executable} PRIVATE LLVM)
[cmake] rework LLVM_LINK_LLVM_DYLIB option handling Summary: This diff attempts to address the concerns raised in http://reviews.llvm.org/D12488. We introduce a new USE_SHARED option to llvm_config, which, if set, causes the target to be linked against libLLVM. add_llvm_utility now uniformly disables linking against libLLVM. These utilities are not intended for distribution, and this keeps the option handling more centralised. llvm-shlib is now processes before any other "tools" subdirectories, ensuring the libLLVM target is defined before its dependents. One main difference from what was requested: llvm_config does not prune LLVM_DYLIB_COMPONENTS from the components passed into explicit_llvm_config. This is because the "all" component does something special, adding additional libraries (namely libLTO). Adding the component libraries after libLLVM should not be a problem, as symbols will be resolved in libLLVM first. Finally, I'm not really happy with the DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a better way to get the following: - link all tools and shared libraries to libLLVM if LLVM_LINK_LLVM_DYLIB is set - some way of explicitly *not* doing so for utilities and libLLVM itself Suggestions for improvement here are particularly welcome. Reviewers: beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12590 llvm-svn: 246918
2015-09-05 16:27:33 +08:00
endif()
explicit_llvm_config(${executable} ${link_components})
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
endmacro(llvm_config)
function(explicit_llvm_config executable)
set( link_components ${ARGN} )
[CMake] Re-apply r200765, "Get rid of llvm_config() to expand dependencies." CMake's target_link_libraries() will manage dependencies with Brad's LLVMConfig improvements. Configuration time may be reduced by a few seconds. llvm-svn: 201062
2014-02-10 11:24:19 +08:00
llvm_map_components_to_libnames(LIBRARIES ${link_components})
[CMake] Use target_link_libraries(INTERFACE|PRIVATE) on CMake-2.8.12 to increase opportunity for parallel build. target_link_libraries(INTERFACE) doesn't bring inter-target dependencies in add_library, although final targets have dependencies to whole dependent libraries. It makes most libraries can be built in parallel. target_link_libraries(PRIVATE) is used to shaared library. Each dependent library is linked to the target.so, and its user will not see its grandchildren. For example, - libclang.so has sufficient libclang*.a(s). - c-index-test requires just only libclang.so. FIXME: lld is tweaked minimally. Adding INTERFACE in each library would be better thing. llvm-svn: 202241
2014-02-26 14:53:16 +08:00
get_target_property(t ${executable} TYPE)
[cmake] Modernize some conditionals. NFC The "x${...}" form was a workaround for CMake versions prior to 3.1, where the if command would interpret arguments as variables even when quoted [1]. We can drop the workaround now that our minimum CMake version is 3.4. [1] https://cmake.org/cmake/help/v3.1/policy/CMP0054.html Differential Revision: https://reviews.llvm.org/D40744 llvm-svn: 319723
2017-12-05 09:19:48 +08:00
if(t STREQUAL "STATIC_LIBRARY")
Raising minimum required CMake version to 2.8.12.2. This commit is in reference to the llvm-dev thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083672.html llvm-svn: 233008
2015-03-24 04:03:57 +08:00
target_link_libraries(${executable} INTERFACE ${LIBRARIES})
[CMake] Use PRIVATE in target_link_libraries for executables We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
2017-12-06 05:49:56 +08:00
elseif(t STREQUAL "EXECUTABLE" OR t STREQUAL "SHARED_LIBRARY" OR t STREQUAL "MODULE_LIBRARY")
Raising minimum required CMake version to 2.8.12.2. This commit is in reference to the llvm-dev thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083672.html llvm-svn: 233008
2015-03-24 04:03:57 +08:00
target_link_libraries(${executable} PRIVATE ${LIBRARIES})
[CMake] Use target_link_libraries(INTERFACE|PRIVATE) on CMake-2.8.12 to increase opportunity for parallel build. target_link_libraries(INTERFACE) doesn't bring inter-target dependencies in add_library, although final targets have dependencies to whole dependent libraries. It makes most libraries can be built in parallel. target_link_libraries(PRIVATE) is used to shaared library. Each dependent library is linked to the target.so, and its user will not see its grandchildren. For example, - libclang.so has sufficient libclang*.a(s). - c-index-test requires just only libclang.so. FIXME: lld is tweaked minimally. Adding INTERFACE in each library would be better thing. llvm-svn: 202241
2014-02-26 14:53:16 +08:00
else()
# Use plain form for legacy user.
target_link_libraries(${executable} ${LIBRARIES})
endif()
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
endfunction(explicit_llvm_config)
Emit a warning if llvm_map_components_to_libraries() is used noting that its use is deprecated in favour of llvm_map_components_to_libnames() Although message(DEPRECATION "msg") would probably be a better fit this does nothing if CMAKE_ERROR_DEPRECATED and CMAKE_WARNING_DEPRECATED are both off, which is the default. llvm-svn: 214078
2014-07-28 21:36:50 +08:00
# This is Deprecated
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
function(llvm_map_components_to_libraries OUT_VAR)
Emit a warning if llvm_map_components_to_libraries() is used noting that its use is deprecated in favour of llvm_map_components_to_libnames() Although message(DEPRECATION "msg") would probably be a better fit this does nothing if CMAKE_ERROR_DEPRECATED and CMAKE_WARNING_DEPRECATED are both off, which is the default. llvm-svn: 214078
2014-07-28 21:36:50 +08:00
message(AUTHOR_WARNING "Using llvm_map_components_to_libraries() is deprecated. Use llvm_map_components_to_libnames() instead")
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
explicit_map_components_to_libraries(result ${ARGN})
set( ${OUT_VAR} ${result} ${sys_result} PARENT_SCOPE )
endfunction(llvm_map_components_to_libraries)
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
# Expand pseudo-components into real components.
# Does not cover 'native', 'backend', or 'engine' as these require special
# handling. Also does not cover 'all' as we only have a list of the libnames
# available and not a list of the components.
function(llvm_expand_pseudo_components out_components)
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
set( link_components ${ARGN} )
foreach(c ${link_components})
# add codegen, asmprinter, asmparser, disassembler
list(FIND LLVM_TARGETS_TO_BUILD ${c} idx)
if( NOT idx LESS 0 )
Teach LLVM-Config to use logical target names (1/2) LLVM library names are now available as logical CMake targets both to our own build and to application CMake code. Replace use of 'list(FIND)' with a simple 'if(TARGET)' to determine whether a library is available. Contributed by Brad King. llvm-svn: 201852
2014-02-21 22:16:52 +08:00
if( TARGET LLVM${c}CodeGen )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${c}CodeGen")
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
else()
Teach LLVM-Config to use logical target names (1/2) LLVM library names are now available as logical CMake targets both to our own build and to application CMake code. Replace use of 'list(FIND)' with a simple 'if(TARGET)' to determine whether a library is available. Contributed by Brad King. llvm-svn: 201852
2014-02-21 22:16:52 +08:00
if( TARGET LLVM${c} )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${c}")
[CMake] Untabify. llvm-svn: 200644
2014-02-03 00:46:35 +08:00
else()
message(FATAL_ERROR "Target ${c} is not in the set of libraries.")
endif()
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
endif()
Revert r366610 and r366612: Expand pseudo-components before embedding in llvm-config Some targets are missing LLVMDemangle, one is adding the LLVM prefix twice, and two are hitting the very error this patch fixes for my target. Reverting while I work through the reports. llvm-svn: 366615
2019-07-20 05:11:05 +08:00
if( TARGET LLVM${c}AsmPrinter )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${c}AsmPrinter")
endif()
if( TARGET LLVM${c}AsmParser )
list(APPEND expanded_components "${c}AsmParser")
[CMake][LLVM] Remove duplicated library mask. Broken clang linking against clangShared Summary: The `LLVM${c}Info` mask is listed twice in LLVM-Config.cmake. This results in the libraries such as LLVMARMInfo, LLVMAArch4Info, etc appearing twice in `extract_symbols.py` command line while building `clangShared`. `Extract_symbols.py` does not work well in such a case and completely ignores the symbols from the duplicated libraries. Thus, the LLVM(...)Info symbols do not get exported from `clangShared` and linking clang against it fails with unresolved dependencies. Seems to be a mere copy-paste mistake. Reviewers: beanz, chapuni Reviewed By: chapuni Subscribers: chapuni, aemerson, mgorny, kristof.beyls, llvm-commits, asl Differential Revision: https://reviews.llvm.org/D36119 llvm-svn: 310590
2017-08-10 21:37:58 +08:00
endif()
[CMake] LINK_COMPONENTS: Add also corresponding MCTargetDesc and TargetInfo as well, when target names or "nativecodegen" are specified. llvm-svn: 212921
2014-07-14 13:07:07 +08:00
if( TARGET LLVM${c}Desc )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${c}Desc")
[CMake] LINK_COMPONENTS: Add also corresponding MCTargetDesc and TargetInfo as well, when target names or "nativecodegen" are specified. llvm-svn: 212921
2014-07-14 13:07:07 +08:00
endif()
Teach LLVM-Config to use logical target names (1/2) LLVM library names are now available as logical CMake targets both to our own build and to application CMake code. Replace use of 'list(FIND)' with a simple 'if(TARGET)' to determine whether a library is available. Contributed by Brad King. llvm-svn: 201852
2014-02-21 22:16:52 +08:00
if( TARGET LLVM${c}Disassembler )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${c}Disassembler")
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
endif()
[CMake] Fix `is_llvm_target_library` and support out-of-order components Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
2017-02-09 04:58:37 +08:00
if( TARGET LLVM${c}Info )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${c}Info")
[CMake] Fix `is_llvm_target_library` and support out-of-order components Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
2017-02-09 04:58:37 +08:00
endif()
if( TARGET LLVM${c}Utils )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${c}Utils")
[CMake] Fix `is_llvm_target_library` and support out-of-order components Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
2017-02-09 04:58:37 +08:00
endif()
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
elseif( c STREQUAL "nativecodegen" )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
if( TARGET LLVM${LLVM_NATIVE_ARCH}CodeGen )
list(APPEND expanded_components "${LLVM_NATIVE_ARCH}CodeGen")
endif()
[CMake] LINK_COMPONENTS: Add also corresponding MCTargetDesc and TargetInfo as well, when target names or "nativecodegen" are specified. llvm-svn: 212921
2014-07-14 13:07:07 +08:00
if( TARGET LLVM${LLVM_NATIVE_ARCH}Desc )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${LLVM_NATIVE_ARCH}Desc")
[CMake] LINK_COMPONENTS: Add also corresponding MCTargetDesc and TargetInfo as well, when target names or "nativecodegen" are specified. llvm-svn: 212921
2014-07-14 13:07:07 +08:00
endif()
if( TARGET LLVM${LLVM_NATIVE_ARCH}Info )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${LLVM_NATIVE_ARCH}Info")
[CMake] LINK_COMPONENTS: Add also corresponding MCTargetDesc and TargetInfo as well, when target names or "nativecodegen" are specified. llvm-svn: 212921
2014-07-14 13:07:07 +08:00
endif()
Break false dependencies on target libraries Summary: For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with some combination of AllTargets* so that they depend on specific components of a target backend rather than all of it. The overall effect of this is that, for example, tools like opt no longer falsely depend on the disassembler, while tools like llvm-ar no longer depend on the code generator. There's a couple quirks to point out here: * AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil seem to need it which I was surprised by. * llvm-xray linked to all the backends but doesn't seem to need any of them. It builds and passes the tests so that seems to be correct. * I left gold out as it's not built when binutils is not available so I'm unable to test it Reviewers: bogner, JDevlieghere Reviewed By: bogner Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62331 llvm-svn: 361567
2019-05-24 07:02:56 +08:00
elseif( c STREQUAL "AllTargetsCodeGens" )
Fix BUILD_SHARED_LIBS builds after r361567 Also fixed a comment I noticed while debugging this build llvm-svn: 361591
2019-05-24 10:15:27 +08:00
# Link all the codegens from all the targets
Break false dependencies on target libraries Summary: For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with some combination of AllTargets* so that they depend on specific components of a target backend rather than all of it. The overall effect of this is that, for example, tools like opt no longer falsely depend on the disassembler, while tools like llvm-ar no longer depend on the code generator. There's a couple quirks to point out here: * AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil seem to need it which I was surprised by. * llvm-xray linked to all the backends but doesn't seem to need any of them. It builds and passes the tests so that seems to be correct. * I left gold out as it's not built when binutils is not available so I'm unable to test it Reviewers: bogner, JDevlieghere Reviewed By: bogner Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62331 llvm-svn: 361567
2019-05-24 07:02:56 +08:00
foreach(t ${LLVM_TARGETS_TO_BUILD})
if( TARGET LLVM${t}CodeGen)
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${t}CodeGen")
Break false dependencies on target libraries Summary: For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with some combination of AllTargets* so that they depend on specific components of a target backend rather than all of it. The overall effect of this is that, for example, tools like opt no longer falsely depend on the disassembler, while tools like llvm-ar no longer depend on the code generator. There's a couple quirks to point out here: * AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil seem to need it which I was surprised by. * llvm-xray linked to all the backends but doesn't seem to need any of them. It builds and passes the tests so that seems to be correct. * I left gold out as it's not built when binutils is not available so I'm unable to test it Reviewers: bogner, JDevlieghere Reviewed By: bogner Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62331 llvm-svn: 361567
2019-05-24 07:02:56 +08:00
endif()
endforeach(t)
Add targets to cmake for specific target components. This adds the following targets to cmake. These can be used to build and link only specific parts of a backend, instead of having to link the whole backend. - AllTargetsAsmPrinters, AllTargetsAsmParsers, AllTargetsDescs, AllTargetsDisassemblers, AllTargetsInfos A typical use for these is instead of linking ${LLVM_TARGETS_TO_BUILD}. This commit changes llvm-mc to show how to use the new targets. Reviewed by Chris Bieneman. llvm-svn: 235324
2015-04-21 02:22:05 +08:00
elseif( c STREQUAL "AllTargetsAsmParsers" )
# Link all the asm parsers from all the targets
foreach(t ${LLVM_TARGETS_TO_BUILD})
if( TARGET LLVM${t}AsmParser )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${t}AsmParser")
Add targets to cmake for specific target components. This adds the following targets to cmake. These can be used to build and link only specific parts of a backend, instead of having to link the whole backend. - AllTargetsAsmPrinters, AllTargetsAsmParsers, AllTargetsDescs, AllTargetsDisassemblers, AllTargetsInfos A typical use for these is instead of linking ${LLVM_TARGETS_TO_BUILD}. This commit changes llvm-mc to show how to use the new targets. Reviewed by Chris Bieneman. llvm-svn: 235324
2015-04-21 02:22:05 +08:00
endif()
endforeach(t)
elseif( c STREQUAL "AllTargetsDescs" )
# Link all the descs from all the targets
foreach(t ${LLVM_TARGETS_TO_BUILD})
if( TARGET LLVM${t}Desc )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${t}Desc")
Add targets to cmake for specific target components. This adds the following targets to cmake. These can be used to build and link only specific parts of a backend, instead of having to link the whole backend. - AllTargetsAsmPrinters, AllTargetsAsmParsers, AllTargetsDescs, AllTargetsDisassemblers, AllTargetsInfos A typical use for these is instead of linking ${LLVM_TARGETS_TO_BUILD}. This commit changes llvm-mc to show how to use the new targets. Reviewed by Chris Bieneman. llvm-svn: 235324
2015-04-21 02:22:05 +08:00
endif()
endforeach(t)
elseif( c STREQUAL "AllTargetsDisassemblers" )
# Link all the disassemblers from all the targets
foreach(t ${LLVM_TARGETS_TO_BUILD})
if( TARGET LLVM${t}Disassembler )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${t}Disassembler")
Add targets to cmake for specific target components. This adds the following targets to cmake. These can be used to build and link only specific parts of a backend, instead of having to link the whole backend. - AllTargetsAsmPrinters, AllTargetsAsmParsers, AllTargetsDescs, AllTargetsDisassemblers, AllTargetsInfos A typical use for these is instead of linking ${LLVM_TARGETS_TO_BUILD}. This commit changes llvm-mc to show how to use the new targets. Reviewed by Chris Bieneman. llvm-svn: 235324
2015-04-21 02:22:05 +08:00
endif()
endforeach(t)
elseif( c STREQUAL "AllTargetsInfos" )
# Link all the infos from all the targets
foreach(t ${LLVM_TARGETS_TO_BUILD})
if( TARGET LLVM${t}Info )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
list(APPEND expanded_components "${t}Info")
Add targets to cmake for specific target components. This adds the following targets to cmake. These can be used to build and link only specific parts of a backend, instead of having to link the whole backend. - AllTargetsAsmPrinters, AllTargetsAsmParsers, AllTargetsDescs, AllTargetsDisassemblers, AllTargetsInfos A typical use for these is instead of linking ${LLVM_TARGETS_TO_BUILD}. This commit changes llvm-mc to show how to use the new targets. Reviewed by Chris Bieneman. llvm-svn: 235324
2015-04-21 02:22:05 +08:00
endif()
endforeach(t)
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
else()
list(APPEND expanded_components "${c}")
endif()
endforeach()
set(${out_components} ${expanded_components} PARENT_SCOPE)
endfunction(llvm_expand_pseudo_components out_components)
# This is a variant intended for the final user:
# Map LINK_COMPONENTS to actual libnames.
function(llvm_map_components_to_libnames out_libs)
set( link_components ${ARGN} )
if(NOT LLVM_AVAILABLE_LIBS)
# Inside LLVM itself available libs are in a global property.
get_property(LLVM_AVAILABLE_LIBS GLOBAL PROPERTY LLVM_LIBS)
endif()
string(TOUPPER "${LLVM_AVAILABLE_LIBS}" capitalized_libs)
get_property(LLVM_TARGETS_CONFIGURED GLOBAL PROPERTY LLVM_TARGETS_CONFIGURED)
# Generally in our build system we avoid order-dependence. Unfortunately since
# not all targets create the same set of libraries we actually need to ensure
# that all build targets associated with a target are added before we can
# process target dependencies.
if(NOT LLVM_TARGETS_CONFIGURED)
foreach(c ${link_components})
is_llvm_target_specifier(${c} iltl_result ALL_TARGETS)
if(iltl_result)
message(FATAL_ERROR "Specified target library before target registration is complete.")
endif()
endforeach()
endif()
# Expand some keywords:
list(FIND LLVM_TARGETS_TO_BUILD "${LLVM_NATIVE_ARCH}" have_native_backend)
list(FIND link_components "engine" engine_required)
if( NOT engine_required EQUAL -1 )
list(FIND LLVM_TARGETS_WITH_JIT "${LLVM_NATIVE_ARCH}" have_jit)
if( NOT have_native_backend EQUAL -1 AND NOT have_jit EQUAL -1 )
list(APPEND link_components "jit")
list(APPEND link_components "native")
else()
list(APPEND link_components "interpreter")
endif()
endif()
list(FIND link_components "native" native_required)
if( NOT native_required EQUAL -1 )
if( NOT have_native_backend EQUAL -1 )
list(APPEND link_components ${LLVM_NATIVE_ARCH})
endif()
endif()
# Translate symbolic component names to real libraries:
llvm_expand_pseudo_components(link_components ${link_components})
foreach(c ${link_components})
if( c STREQUAL "native" )
# already processed
elseif( c STREQUAL "backend" )
# same case as in `native'.
elseif( c STREQUAL "engine" )
# already processed
elseif( c STREQUAL "all" )
[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries" Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
2019-11-14 13:39:58 +08:00
get_property(all_components GLOBAL PROPERTY LLVM_COMPONENT_LIBS)
list(APPEND expanded_components ${all_components})
[cmake] Remove confusing condition argument from else() NFC Summary: This makes it look like an elseif and also the variable referenced in the condition was removed from this function in r366622. Reviewers: dsanders, beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70159
2019-11-14 08:01:33 +08:00
else()
Simplified LLVMConfig. llvm-svn: 114998
2010-09-29 06:38:39 +08:00
# Canonize the component name:
string(TOUPPER "${c}" capitalized)
list(FIND capitalized_libs LLVM${capitalized} lib_idx)
if( lib_idx LESS 0 )
Make my attempt to build up global deps variables actually utilize globally scoped constructs. Also, round-trip these dependencies through the LLVMConfig.cmake.in file thata is used by CMake-based clients of "installed" (or built) LLVM trees. llvm-svn: 136543
2011-07-30 07:52:01 +08:00
# The component is unknown. Maybe is an omitted target?
[CMake] Fix `is_llvm_target_library` and support out-of-order components Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
2017-02-09 04:58:37 +08:00
is_llvm_target_library(${c} iltl_result OMITTED_TARGETS)
if(iltl_result)
# A missing library to a directly referenced omitted target would be bad.
message(FATAL_ERROR "Library '${c}' is a direct reference to a target library for an omitted target.")
else()
# If it is not an omitted target we should assume it is a component
# that hasn't yet been processed by CMake. Missing components will
# cause errors later in the configuration, so we can safely assume
# that this is valid here.
list(APPEND expanded_components LLVM${c})
Make my attempt to build up global deps variables actually utilize globally scoped constructs. Also, round-trip these dependencies through the LLVMConfig.cmake.in file thata is used by CMake-based clients of "installed" (or built) LLVM trees. llvm-svn: 136543
2011-07-30 07:52:01 +08:00
endif()
Simplified LLVMConfig. llvm-svn: 114998
2010-09-29 06:38:39 +08:00
else( lib_idx LESS 0 )
Teach LLVM-Config to use logical target names (2/2) The module still needs to collect the list of all available libraries in order to satisfy the 'all' component. Provide this in the package configuration file, 'LLVMConfig.cmake', as a LLVM_AVAILABLE_LIBS variable. (A variable is scoped better than a global property.) Since this won't be set for our own build, fall back to looking up the LLVM_LIBS property to get the value when it is not set. Contributed by Brad King. llvm-svn: 201853
2014-02-21 22:17:07 +08:00
list(GET LLVM_AVAILABLE_LIBS ${lib_idx} canonical_lib)
Make my attempt to build up global deps variables actually utilize globally scoped constructs. Also, round-trip these dependencies through the LLVMConfig.cmake.in file thata is used by CMake-based clients of "installed" (or built) LLVM trees. llvm-svn: 136543
2011-07-30 07:52:01 +08:00
list(APPEND expanded_components ${canonical_lib})
Simplified LLVMConfig. llvm-svn: 114998
2010-09-29 06:38:39 +08:00
endif( lib_idx LESS 0 )
Re-commit: r366610 and r366612: Expand pseudo-components before embedding in llvm-config There were two main problems: * The 'nativecodegen' pseudo-component was unconditionally adding ${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and ${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen conditional too * The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as the expansion was to a library name and not a component. There doesn't seem to be a list of available components anywhere so this has been fixed by moving the expansion of 'all' back where it was before. This manifested in different ways on different builders but it was the same root cause llvm-svn: 366622
2019-07-20 06:46:47 +08:00
endif( c STREQUAL "native" )
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
endforeach(c)
[CMake] LLVM-Config.cmake: Split explicit_map_components_to_libraries and introduce llvm_map_components_to_libnames and llvm_expand_dependencies. llvm-svn: 200764
2014-02-04 22:42:04 +08:00
set(${out_libs} ${expanded_components} PARENT_SCOPE)
endfunction()
[cmake] Unbreak LLVM-Config.cmake / llvm_expand_dependencies. The algorithm for sorting libraries in topological order, as previously implemented, had a few issues: * It didn't make any sense. * It didn't actually sort libraries in topological order. * It hung on some inputs, e.g. "LLVMipo". This commit replaces the old algorithm with a straightforward port from llvm-config.cpp. llvm-svn: 224554
2014-12-19 07:56:52 +08:00
# Perform a post-order traversal of the dependency graph.
# This duplicates the algorithm used by llvm-config, originally
# in tools/llvm-config/llvm-config.cpp, function ComputeLibsForComponents.
function(expand_topologically name required_libs visited_libs)
list(FIND visited_libs ${name} found)
if( found LESS 0 )
list(APPEND visited_libs ${name})
set(visited_libs ${visited_libs} PARENT_SCOPE)
get_property(lib_deps GLOBAL PROPERTY LLVMBUILD_LIB_DEPS_${name})
foreach( lib_dep ${lib_deps} )
expand_topologically(${lib_dep} "${required_libs}" "${visited_libs}")
set(required_libs ${required_libs} PARENT_SCOPE)
set(visited_libs ${visited_libs} PARENT_SCOPE)
endforeach()
list(APPEND required_libs ${name})
set(required_libs ${required_libs} PARENT_SCOPE)
endif()
endfunction()
[CMake] LLVM-Config.cmake: Split explicit_map_components_to_libraries and introduce llvm_map_components_to_libnames and llvm_expand_dependencies. llvm-svn: 200764
2014-02-04 22:42:04 +08:00
# Expand dependencies while topologically sorting the list of libraries:
function(llvm_expand_dependencies out_libs)
set(expanded_components ${ARGN})
[cmake] Unbreak LLVM-Config.cmake / llvm_expand_dependencies. The algorithm for sorting libraries in topological order, as previously implemented, had a few issues: * It didn't make any sense. * It didn't actually sort libraries in topological order. * It hung on some inputs, e.g. "LLVMipo". This commit replaces the old algorithm with a straightforward port from llvm-config.cpp. llvm-svn: 224554
2014-12-19 07:56:52 +08:00
set(required_libs)
set(visited_libs)
foreach( lib ${expanded_components} )
expand_topologically(${lib} "${required_libs}" "${visited_libs}")
endforeach()
[CMake] Avoid REVERSE on unset variable If required_libs happens to remain unset, CMake would fail with: list sub-command REVERSE requires list to be present. Fix by ensuring we do not attempt to reverse an unset variable. Reported by Tu Vuong. Differential Revision: https://reviews.llvm.org/D51799 llvm-svn: 343088
2018-09-26 18:14:10 +08:00
if(required_libs)
list(REVERSE required_libs)
endif()
[cmake] Unbreak LLVM-Config.cmake / llvm_expand_dependencies. The algorithm for sorting libraries in topological order, as previously implemented, had a few issues: * It didn't make any sense. * It didn't actually sort libraries in topological order. * It hung on some inputs, e.g. "LLVMipo". This commit replaces the old algorithm with a straightforward port from llvm-config.cpp. llvm-svn: 224554
2014-12-19 07:56:52 +08:00
set(${out_libs} ${required_libs} PARENT_SCOPE)
[CMake] LLVM-Config.cmake: Split explicit_map_components_to_libraries and introduce llvm_map_components_to_libnames and llvm_expand_dependencies. llvm-svn: 200764
2014-02-04 22:42:04 +08:00
endfunction()
function(explicit_map_components_to_libraries out_libs)
llvm_map_components_to_libnames(link_libs ${ARGN})
llvm_expand_dependencies(expanded_components ${link_libs})
Simplified LLVMConfig. llvm-svn: 114998
2010-09-29 06:38:39 +08:00
# Return just the libraries included in this build:
set(result)
foreach(c ${expanded_components})
Teach LLVM-Config to use logical target names (1/2) LLVM library names are now available as logical CMake targets both to our own build and to application CMake code. Replace use of 'list(FIND)' with a simple 'if(TARGET)' to determine whether a library is available. Contributed by Brad King. llvm-svn: 201852
2014-02-21 22:16:52 +08:00
if( TARGET ${c} )
Simplified LLVMConfig. llvm-svn: 114998
2010-09-29 06:38:39 +08:00
set(result ${result} ${c})
endif()
endforeach(c)
Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally." This reverts commit r113632 Conflicts: cmake/modules/AddLLVM.cmake llvm-svn: 113819
2010-09-14 07:59:48 +08:00
set(${out_libs} ${result} PARENT_SCOPE)
endfunction(explicit_map_components_to_libraries)