qiurui
/
qtbase
mirror of https://github.com/qt/qtbase.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
qtbase/cmake/QtPublicWalkLibsHelpers.cmake

361 lines
16 KiB
CMake
Raw Normal View History

Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 11:26:52 +00:00
# Copyright (C) 2022 The Qt Company Ltd.
Change the license of all CMakeLists.txt and *.cmake files to BSD Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-19 13:21:34 +00:00
# SPDX-License-Identifier: BSD-3-Clause
Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 11:26:52 +00:00
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
# Add libraries to variable ${out_libs_var} in a way that duplicates
# are added at the end. This ensures the library order needed for the
# linker.
function(__qt_internal_merge_libs out_libs_var)
foreach(dep ${ARGN})
list(REMOVE_ITEM ${out_libs_var} ${dep})
list(APPEND ${out_libs_var} ${dep})
endforeach()
set(${out_libs_var} ${${out_libs_var}} PARENT_SCOPE)
endfunction()
# Extracts value from per-target dict key and assigns it to out_var.
# Assumes dict_name to be an existing INTERFACE target.
function(__qt_internal_get_dict_key_values out_var target_infix dict_name dict_key)
get_target_property(values "${dict_name}" "INTERFACE_${target_infix}_${dict_key}")
set(${out_var} "${values}" PARENT_SCOPE)
endfunction()
# Assigns 'values' to per-target dict key, including for aliases of the target.
# Assumes dict_name to be an existing INTERFACE target.
function(__qt_internal_memoize_values_in_dict target dict_name dict_key values)
# Memoize the computed values for the target as well as its aliases.
#
# Aka assigns the contents of ${values} to INTERFACE_Core, INTERFACE_Qt::Core,
# INTERFACE_Qt6::Core.
#
# Yes, i know it's crazy that target names are legal property names.
#
# Assigning for library aliases is needed to avoid multiple recomputation of values.
# Scenario in the context of __qt_internal_walk_libs:
# 'values' are computed for Core target and memoized to INTERFACE_Core.
# When processing Gui, it depends on Qt::Core, but there are no values for INTERFACE_Qt::Core.
set_target_properties(${dict_name} PROPERTIES INTERFACE_${target}_${dict_key} "${values}")
get_target_property(versionless_alias "${target}" "_qt_versionless_alias")
if(versionless_alias)
__qt_internal_get_dict_key_values(
versionless_values "${versionless_alias}" "${dict_name}" "${dict_key}")
if(versionless_values MATCHES "-NOTFOUND$")
set_target_properties(${dict_name}
PROPERTIES INTERFACE_${versionless_alias}_${dict_key} "${values}")
endif()
endif()
get_target_property(versionfull_alias "${target}" "_qt_versionfull_alias")
if(versionfull_alias)
__qt_internal_get_dict_key_values(
versionfull_values "${versionfull_alias}" "${dict_name}" "${dict_key}")
if(versionfull_values MATCHES "-NOTFOUND$")
set_target_properties(${dict_name}
PROPERTIES INTERFACE_${versionfull_alias}_${dict_key} "${values}")
endif()
endif()
endfunction()
CMake: Add 'collect_targets' mode to __qt_internal_walk_libs Allow collecting all public dependency CMake targets starting from a given initial target. The new mode walks INTERFACE_LINK_LIBRARIES of a shared library or executable target, as well as the INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES of a static library target. Each encountered target (checked with if(TARGET)) is added the output list. Note that the private dependencies of a non-static target (like a shared library or executable) are not walked by the new mode. Introduce a new function called __qt_internal_collect_all_target_dependencies which uses the new mode to collect the full private dependency list of a target. The final list only contains targets, so no linker flags or file paths. This list is useful to do further processing on the targets like extracting properties from them and running finalizers. Task-number: QTBUG-92933 Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
# Walks a target's public link libraries recursively, and performs some actions (poor man's
# polypmorphism)
#
# Walks INTERFACE_LINK_LIBRARIES for all target types, as well as LINK_LIBRARIES for static
# library targets.
#
# out_var: the name of the variable where the result will be assigned. The result is a list of
# libraries, mostly in generator expression form.
# rcc_objects_out_var: the name of the variable where the collected rcc object files will be
# assigned (for the initial target and its dependencies)
# dict_name: used for caching the results, and preventing the same target from being processed
# twice
# operation: a string to tell the function what additional behaviors to execute.
# 'collect_libs' (default) operation is to collect linker file paths and flags.
# Used for prl file generation.
CMake: Prevent most global promotion errors when building Qt Backstory. The main reason why we keep getting "unable to promote 3rd party 'X' target to global scope" errors when building Qt repositories, is because we try to promote 3rd party imported targets in a different scope than where the imported targets were created. What were the main motivations for promoting 3rd party targets to global? 1) imported targets are by default local to the directory scope they were created in 2) we want 3rd party targets to be accessible across subdirectory scopes, but looked up once, e.g. qt_find_package(JPEG) looked up in src/gui/CMakeLists.txt, but the target should also be usable in the sibling scope src/plugins/imageformats/CMakeLists.txt Having the package lookup close to the consuming qt module is easier to maintain, because all the other 3rd party dependency lookups are in the same file. This goes against the conventional CMake advice where each subdirectory should look for its own dependencies, or the dependency should be available directly in the root project scope. 3) to make the 3rd party targets available in the root project scope as part of the following flow: QtPostProcess.cmake -> qt_internal_create_module_depends_file() -> qt_collect_third_party_deps() -> get_property(INTERFACE_QT_PACKAGE_NAME) -> write 3rd party Dependencies.cmake file for each qt module. Properties can only be queried from an imported target if it's in the same scope or was promoted to global, otherwise you get 'non-existent target' errors. 4) for prl and pri file generation, where we need the targets to be available during generator expression evaluation within the relevant qt module directory scope Here is a list of approaches I came up with on how to improve the situation. 1) Make all imported targets global during the Qt build, by iterating over the directory property IMPORTED_TARGETS and making each one global. Requires CMake 3.21. Status: Already implemented for a long time, but is opt-in. Pros: Relatively robust Cons: Minimum CMake version for building Qt is 3.16. 2) Make all imported targets global during the Qt build using the CMAKE_FIND_PACKAGE_TARGETS_GLOBAL variable. Requires CMake 3.24. Status: Not implemented, but can be set by Qt builders directly on the command line. Pros: Should be robust Cons: Minimum CMake version for building Qt is 3.16. 3) Abandon the desire to have a single qt_find_package in a single directory scope, and embrace the CMake-way of repeating the dependency in each subdirectory that requires it. Status: Not implemented. Pros: Should be robust Cons: A lot of qt_find_package duplication, will require rewriting various code paths, QtPostProcess would have to be done at directory scope, unclear if dependency tracking will still work work reliably when there might be multiple same-named directory-scoped targets, other unknown unknowns 4) Move all qt_find_package calls into a $repo_name/dependencies.cmake file which would be read at project root scope. This would potentially avoid all scoping issues, because all dependencies will have to be specified at root scope. Status: Not implemented. Pros: No duplication Cons: Dependencies are not scoped anymore to module directories, won't be able to conditionally look for dependencies based on module feature evaluation, not clear yet how this will tie into standalone tests which are in tests/ subdir, other unknown unknowns 5) Try to promote as many 3rd party libraries at project root scope as possible. Currently we have 2 general locations where we look up dependencies. One is each qt_find_package call. The other is Qt6FooDependencies.cmake -> _qt_internal_find_third_party_dependencies(). Many 3rd party targets are created by _qt_internal_find_third_party_dependencies() in the root scope, but not promoted, and then we try to promote them in child scopes using qt_find_package, which causes the promotion errors. Starting with 58eefbd0b6169d0749b312268c1ae1e594e04362 and 37a5e001277db9e1392a242171ab2b88cb6c3049 we now record the provided targets of previous qt_find_package calls. So instead of waiting to try and promote targets later during the configuration process, we can make sure we promote the targets at _qt_internal_find_third_party_dependencies() call time, right when we lookup the Qt dependencies of the qt repo, in the root scope. Status: Implemented in this change Notably, we only promote 3rd party targets to global for qt builds, and not user projects, to not accidentally break user project behaviors. Also, we only promote 3rd party targets, and not Qt internal targets like Qt6::Core, Qt6::Platform, Qt6::PlatformCommonInternal, Qt6::GlobalConfig, etc, for a few reasons: - the code that requires targets to be global only cares about 3rd party targets - promoting the internal targets is more prone to breaking, because there is more than one place where find_package(Qt6Foo) might be called, and if that ends up being in a different directory scope, we encounter the same global promotion errors. Some notable cases where this happens: - tests/CMakeLists.txt brings in extra Qt packages via StandaloneTestsConfig.cmake files - qtbase standalone tests qt_internal_qtbase_pre_project_setup() calls find_package(Qt6 COMPONENTS BuildInternals) which ends up creating the Platform target in the root scope instead of the tests/ scope - Qt6::BundledLibpng links against Core, which ends up trying to promote Core's internal dependencies Platform and GlobalConfig To only promote 3rd party targets, we walk the dependencies of an initial target recursively, and skip promoting targets that have the _qt_is_internal_target or _qt_should_skip_global_promotion_always properties set. Pros: Improves the situation compared to the status quo Cons: Still not ideal due to the various filtering of internal targets and having to mark them as such. 6) Avoid promoting targets to global if we can detect that the target was created in a different scope than where we are trying to promote it. We can do that by comparing the target's BINARY_DIR to the CMAKE_CURRENT_BINARY_DIR and skip promotion if they are not equal. Status: Not implemented, but we can consider it because it's quick to do. Pros: More robust than newly implemented approach (5) Cons: Requires CMake 3.18, because trying to read the BINARY_DIR property on an INTERFACE_LIBRARY would error out. Also, if we implement it and make it the default when using 3.18+, we might 'collect' a lot more hidden promotion errors that will only be revealed later once someone uses CMake 3.16 or 3.17, because most will probably use newer CMake versions. Perhaps the trade-off is worth it? Pick-to: 6.8 Fixes: QTBUG-89204 Fixes: QTBUG-94356 Fixes: QTBUG-95052 Fixes: QTBUG-98807 Fixes: QTBUG-125371 Change-Id: I088a17a98ef35aa69537a3ad208c61de40def581 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 17:10:26 +00:00
# 'promote_3rd_party_global' promotes walked 3rd party imported targets to global scope.
CMake: Add 'collect_targets' mode to __qt_internal_walk_libs Allow collecting all public dependency CMake targets starting from a given initial target. The new mode walks INTERFACE_LINK_LIBRARIES of a shared library or executable target, as well as the INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES of a static library target. Each encountered target (checked with if(TARGET)) is added the output list. Note that the private dependencies of a non-static target (like a shared library or executable) are not walked by the new mode. Introduce a new function called __qt_internal_collect_all_target_dependencies which uses the new mode to collect the full private dependency list of a target. The final list only contains targets, so no linker flags or file paths. This list is useful to do further processing on the targets like extracting properties from them and running finalizers. Task-number: QTBUG-92933 Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
# 'collect_targets' collects all target names (discards framework or link flags)
CMake build: generate pkgconfig for public modules After the update to the CMake based build system the ability to generate pkgconfig files, like it was with QMake, was lost. This patch adds pkgconfig generation again via a new internal command named qt_internal_export_pkg_config_file. The functionality of this command consists in checking if the target is internal. Then gets the compile definitions. It performs a search for dependencies that is somewhat similar to qt_get_direct_module_dependencies, although it won't recurse down for more deps. Each dependency is then again, checked if it's internal or has a public interface. Later these deps get deduplicated and lastly a pkgconfig file is filled. The resulting pkgconfig files of many of the Qt6 packages were validated via invocations of `pkg-config --validate` and `pkg-config --simulate` commands and later used to build local projects plus tests that use the pkg-config provided details at compilation time. Although it has some limitations, with qt_internal_add_qml_module if it specifies non-public deps these won't be listed and with non-Qt requirements, notably in static builds, not being appended to the PkgConfig file. Task-number: QTBUG-86080 Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-11 17:39:53 +00:00
# 'direct_targets' collects only the direct target names (discards framework or link
# flags)
CMake: Add 'collect_targets' mode to __qt_internal_walk_libs Allow collecting all public dependency CMake targets starting from a given initial target. The new mode walks INTERFACE_LINK_LIBRARIES of a shared library or executable target, as well as the INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES of a static library target. Each encountered target (checked with if(TARGET)) is added the output list. Note that the private dependencies of a non-static target (like a shared library or executable) are not walked by the new mode. Introduce a new function called __qt_internal_collect_all_target_dependencies which uses the new mode to collect the full private dependency list of a target. The final list only contains targets, so no linker flags or file paths. This list is useful to do further processing on the targets like extracting properties from them and running finalizers. Task-number: QTBUG-92933 Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
#
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
#
function(__qt_internal_walk_libs
target out_var rcc_objects_out_var dict_name operation)
set(collected ${ARGN})
if(target IN_LIST collected)
return()
endif()
list(APPEND collected ${target})
CMake build: generate pkgconfig for public modules After the update to the CMake based build system the ability to generate pkgconfig files, like it was with QMake, was lost. This patch adds pkgconfig generation again via a new internal command named qt_internal_export_pkg_config_file. The functionality of this command consists in checking if the target is internal. Then gets the compile definitions. It performs a search for dependencies that is somewhat similar to qt_get_direct_module_dependencies, although it won't recurse down for more deps. Each dependency is then again, checked if it's internal or has a public interface. Later these deps get deduplicated and lastly a pkgconfig file is filled. The resulting pkgconfig files of many of the Qt6 packages were validated via invocations of `pkg-config --validate` and `pkg-config --simulate` commands and later used to build local projects plus tests that use the pkg-config provided details at compilation time. Although it has some limitations, with qt_internal_add_qml_module if it specifies non-public deps these won't be listed and with non-Qt requirements, notably in static builds, not being appended to the PkgConfig file. Task-number: QTBUG-86080 Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-11 17:39:53 +00:00
if(operation MATCHES "^direct")
set(direct TRUE)
else()
set(direct FALSE)
endif()
Adjust the EntryPoint target name according to the internal module naming policy Pick-to: 6.2 Task-number: QTBUG-87775 Change-Id: I1d6097c950f97e102c44e2952edc98caa4deb6c6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-11 11:36:10 +00:00
if(target STREQUAL "${QT_CMAKE_EXPORT_NAMESPACE}::EntryPointPrivate")
# We can't (and don't need to) process EntryPointPrivate because it brings in
# $<TARGET_PROPERTY:prop> genexes which get replaced with
# $<TARGET_PROPERTY:EntryPointPrivate,prop> genexes in the code below and that causes
# 'INTERFACE_LIBRARY targets may only have whitelisted properties.' errors with CMake
# versions equal to or lower than 3.18. These errors are super unintuitive to debug
# because there's no mention that it's happening during a file(GENERATE) call.
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
return()
endif()
if(NOT TARGET ${dict_name})
add_library(${dict_name} INTERFACE IMPORTED GLOBAL)
endif()
__qt_internal_get_dict_key_values(libs "${target}" "${dict_name}" "libs")
__qt_internal_get_dict_key_values(rcc_objects "${target}" "${dict_name}" "rcc_objects")
if(libs MATCHES "-NOTFOUND$")
unset(libs)
unset(rcc_objects)
get_target_property(target_libs ${target} INTERFACE_LINK_LIBRARIES)
if(NOT target_libs)
unset(target_libs)
endif()
get_target_property(target_type ${target} TYPE)
if(target_type STREQUAL "STATIC_LIBRARY")
get_target_property(link_libs ${target} LINK_LIBRARIES)
if(link_libs)
list(APPEND target_libs ${link_libs})
endif()
endif()
# Need to record the rcc object file info not only for dependencies, but also for
# the current target too. Otherwise the saved information is incomplete for prl static
# build purposes.
get_target_property(main_target_rcc_objects ${target} _qt_rcc_objects)
if(main_target_rcc_objects)
__qt_internal_merge_libs(rcc_objects ${main_target_rcc_objects})
endif()
foreach(lib ${target_libs})
# Cannot use $<TARGET_POLICY:...> in add_custom_command.
# Check the policy now, and replace the generator expression with the value.
while(lib MATCHES "\\$<TARGET_POLICY:([^>]+)>")
cmake_policy(GET ${CMAKE_MATCH_1} value)
if(value STREQUAL "NEW")
set(value "TRUE")
else()
set(value "FALSE")
endif()
string(REPLACE "${CMAKE_MATCH_0}" "${value}" lib "${lib}")
endwhile()
# Fix up $<TARGET_PROPERTY:FOO> expressions that refer to the "current" target.
# Those cannot be used with add_custom_command.
while(lib MATCHES "\\$<TARGET_PROPERTY:([^,>]+)>")
string(REPLACE "${CMAKE_MATCH_0}" "$<TARGET_PROPERTY:${target},${CMAKE_MATCH_1}>"
lib "${lib}")
endwhile()
CMake: Add a special skip genex marker when walking libs Useful to annotate certain linking expressions that need to be skipped for inclusion in prl file generation. E.g. $<TARGET_OBJECTS> expressions that represent propagated object libraries, which are handled by the rcc_objects walk lib code path, and thus need to end up in prl RCC_OBJECTS section, instead of the QMAKE_PRL_LIBS_FOR_CMAKE one. Pick-to: 6.8 6.9 Change-Id: Ib08b00200b6b06d32eab15ecb15c0820eec2a908 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-03-06 13:38:40 +00:00
# Skip processing static plugins.
# There are some abuses of this genex marker, because the more generic one below did
# not exist yet.
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
set(_is_plugin_marker_genex "\\$<BOOL:QT_IS_PLUGIN_GENEX>")
CMake: Add a special skip genex marker when walking libs Useful to annotate certain linking expressions that need to be skipped for inclusion in prl file generation. E.g. $<TARGET_OBJECTS> expressions that represent propagated object libraries, which are handled by the rcc_objects walk lib code path, and thus need to end up in prl RCC_OBJECTS section, instead of the QMAKE_PRL_LIBS_FOR_CMAKE one. Pick-to: 6.8 6.9 Change-Id: Ib08b00200b6b06d32eab15ecb15c0820eec2a908 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-03-06 13:38:40 +00:00
# Skip any genex expressions that contain the marker. Useful in cases like processing
# link expressions for prl file generation, where some link expressions should be
# skipped either because they don't make sense or they are handled differently.
set(_is_skip_marker_genex "\\$<BOOL:QT_SKIP_WALK_LIBS_PROCESSING>")
if(lib MATCHES "${_is_plugin_marker_genex}" OR lib MATCHES "${_is_skip_marker_genex}")
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
continue()
endif()
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
# Skip optional dependencies for now. They are likely to be handled manually for prl
# file purposes (like nolink handling). And for one of the other operations, we don't
# have a use case yet. This might be revisited.
if(lib MATCHES "^\\$<TARGET_NAME_IF_EXISTS:")
continue()
endif()
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
# Strip any directory scope tokens.
__qt_internal_strip_target_directory_scope_token("${lib}" lib)
if(lib MATCHES "^\\$<TARGET_OBJECTS:")
# Skip object files.
continue()
endif()
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 16:19:22 +00:00
set(lib_target "${lib}")
# Unwrap targets like $<LINK_ONLY:$<BUILD_INTERFACE:Qt6::CorePrivate>>
while(lib_target
MATCHES "^\\$<(LINK_ONLY|BUILD_INTERFACE|BUILD_LOCAL_INTERFACE):(.*)>$")
CMake: Skip walking empty targets in __qt_internal_walk_libs() If one of the interface link libraries of a target is "$<LINK_ONLY:$<BUILD_LOCAL_INTERFACE:Foo>>" this will be exported by cmake as "$<LINK_ONLY:>" in the exported INTERFACE_LINK_LIBRARIES property. When walking the dependent libraries of a target using __qt_internal_walk_libs(), this value will become empty after unwrapping the LINK_ONLY genex. In such a case, we should skip further processing of the library. Otherwise in some weird unknown conditions, CMake might consider the empty name to be a valid target, and cause errors when trying to read properties from it. Amends ad7b94e163ac5c3959a7e38d7f48536be288a187 Pick-to: 6.9 Fixes: QTBUG-136039 Change-Id: I143dec697e10530379486462697cd299940ee463 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-04-24 16:14:25 +00:00
set(lib_target "${CMAKE_MATCH_2}")
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 16:19:22 +00:00
endwhile()
CMake: Skip walking empty targets in __qt_internal_walk_libs() If one of the interface link libraries of a target is "$<LINK_ONLY:$<BUILD_LOCAL_INTERFACE:Foo>>" this will be exported by cmake as "$<LINK_ONLY:>" in the exported INTERFACE_LINK_LIBRARIES property. When walking the dependent libraries of a target using __qt_internal_walk_libs(), this value will become empty after unwrapping the LINK_ONLY genex. In such a case, we should skip further processing of the library. Otherwise in some weird unknown conditions, CMake might consider the empty name to be a valid target, and cause errors when trying to read properties from it. Amends ad7b94e163ac5c3959a7e38d7f48536be288a187 Pick-to: 6.9 Fixes: QTBUG-136039 Change-Id: I143dec697e10530379486462697cd299940ee463 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-04-24 16:14:25 +00:00
# If one of the values is "$<LINK_ONLY:$<BUILD_LOCAL_INTERFACE:Foo>>", this will be
# exported by cmake as "$<LINK_ONLY:>", which will become an empty value after the
# unwrapping above.
# In that case, skip the processing. Otherwise in some weird unknown conditions,
# CMake might consider the empty name to be a valid target, and cause errors further
# down.
if("${lib_target}" STREQUAL "")
continue()
endif()
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
# Skip CMAKE_DIRECTORY_ID_SEP. If a target_link_libraries is applied to a target
# that was defined in a different scope, CMake appends and prepends a special directory
# id separator. Filter those out.
if(lib_target MATCHES "^::@")
continue()
elseif(TARGET ${lib_target})
Prefer the versioned targets over the namespaceless one when collecting deps Change the way we collect dependencies in __qt_internal_walk_libs. Prefer the versioned Qt targets over the namespaceless. This fixes the generating of the pkg-config configs. Pick-to: 6.5 6.6 6.7 Task-number: QTBUG-124135 Change-Id: I660376e122a99b5bc0874f2bc6ccd4d80c9ad453 Reviewed-by: Ionen Wolkens <ionen@gentoo.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2024-04-05 12:50:37 +00:00
if(NOT "${lib_target}" MATCHES "^(Qt|${QT_CMAKE_EXPORT_NAMESPACE})::.+")
# If both, Qt::Foo and Foo targets exist, prefer the target name with versioned
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
# namespace. Which one is preferred doesn't really matter. This code exists to
# avoid ending up with both, Qt::Foo and Foo in our dependencies.
Prefer the versioned targets over the namespaceless one when collecting deps Change the way we collect dependencies in __qt_internal_walk_libs. Prefer the versioned Qt targets over the namespaceless. This fixes the generating of the pkg-config configs. Pick-to: 6.5 6.6 6.7 Task-number: QTBUG-124135 Change-Id: I660376e122a99b5bc0874f2bc6ccd4d80c9ad453 Reviewed-by: Ionen Wolkens <ionen@gentoo.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2024-04-05 12:50:37 +00:00
set(versioned_qt_target "${QT_CMAKE_EXPORT_NAMESPACE}::${lib_target}")
if(TARGET "${versioned_qt_target}")
set(lib_target ${versioned_qt_target})
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
endif()
endif()
get_target_property(lib_target_type ${lib_target} TYPE)
if(lib_target_type STREQUAL "INTERFACE_LIBRARY")
CMake build: generate pkgconfig for public modules After the update to the CMake based build system the ability to generate pkgconfig files, like it was with QMake, was lost. This patch adds pkgconfig generation again via a new internal command named qt_internal_export_pkg_config_file. The functionality of this command consists in checking if the target is internal. Then gets the compile definitions. It performs a search for dependencies that is somewhat similar to qt_get_direct_module_dependencies, although it won't recurse down for more deps. Each dependency is then again, checked if it's internal or has a public interface. Later these deps get deduplicated and lastly a pkgconfig file is filled. The resulting pkgconfig files of many of the Qt6 packages were validated via invocations of `pkg-config --validate` and `pkg-config --simulate` commands and later used to build local projects plus tests that use the pkg-config provided details at compilation time. Although it has some limitations, with qt_internal_add_qml_module if it specifies non-public deps these won't be listed and with non-Qt requirements, notably in static builds, not being appended to the PkgConfig file. Task-number: QTBUG-86080 Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-11 17:39:53 +00:00
if(NOT ${direct})
__qt_internal_walk_libs(
${lib_target}
lib_libs_${target}
lib_rcc_objects_${target}
"${dict_name}" "${operation}" ${collected})
if(lib_libs_${target})
__qt_internal_merge_libs(libs ${lib_libs_${target}})
set(is_module 0)
endif()
if(lib_rcc_objects_${target})
__qt_internal_merge_libs(rcc_objects ${lib_rcc_objects_${target}})
endif()
else()
__qt_internal_merge_libs(libs ${lib})
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
endif()
elseif(NOT lib_target_type STREQUAL "OBJECT_LIBRARY")
CMake: Add 'collect_targets' mode to __qt_internal_walk_libs Allow collecting all public dependency CMake targets starting from a given initial target. The new mode walks INTERFACE_LINK_LIBRARIES of a shared library or executable target, as well as the INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES of a static library target. Each encountered target (checked with if(TARGET)) is added the output list. Note that the private dependencies of a non-static target (like a shared library or executable) are not walked by the new mode. Introduce a new function called __qt_internal_collect_all_target_dependencies which uses the new mode to collect the full private dependency list of a target. The final list only contains targets, so no linker flags or file paths. This list is useful to do further processing on the targets like extracting properties from them and running finalizers. Task-number: QTBUG-92933 Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
CMake build: generate pkgconfig for public modules After the update to the CMake based build system the ability to generate pkgconfig files, like it was with QMake, was lost. This patch adds pkgconfig generation again via a new internal command named qt_internal_export_pkg_config_file. The functionality of this command consists in checking if the target is internal. Then gets the compile definitions. It performs a search for dependencies that is somewhat similar to qt_get_direct_module_dependencies, although it won't recurse down for more deps. Each dependency is then again, checked if it's internal or has a public interface. Later these deps get deduplicated and lastly a pkgconfig file is filled. The resulting pkgconfig files of many of the Qt6 packages were validated via invocations of `pkg-config --validate` and `pkg-config --simulate` commands and later used to build local projects plus tests that use the pkg-config provided details at compilation time. Although it has some limitations, with qt_internal_add_qml_module if it specifies non-public deps these won't be listed and with non-Qt requirements, notably in static builds, not being appended to the PkgConfig file. Task-number: QTBUG-86080 Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-11 17:39:53 +00:00
if(operation MATCHES "^(collect|direct)_targets$")
CMake: Add 'collect_targets' mode to __qt_internal_walk_libs Allow collecting all public dependency CMake targets starting from a given initial target. The new mode walks INTERFACE_LINK_LIBRARIES of a shared library or executable target, as well as the INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES of a static library target. Each encountered target (checked with if(TARGET)) is added the output list. Note that the private dependencies of a non-static target (like a shared library or executable) are not walked by the new mode. Introduce a new function called __qt_internal_collect_all_target_dependencies which uses the new mode to collect the full private dependency list of a target. The final list only contains targets, so no linker flags or file paths. This list is useful to do further processing on the targets like extracting properties from them and running finalizers. Task-number: QTBUG-92933 Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
__qt_internal_merge_libs(libs ${lib_target})
else()
__qt_internal_merge_libs(libs "$<TARGET_LINKER_FILE:${lib_target}>")
endif()
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
get_target_property(target_rcc_objects "${lib_target}" _qt_rcc_objects)
if(target_rcc_objects)
__qt_internal_merge_libs(rcc_objects ${target_rcc_objects})
endif()
CMake build: generate pkgconfig for public modules After the update to the CMake based build system the ability to generate pkgconfig files, like it was with QMake, was lost. This patch adds pkgconfig generation again via a new internal command named qt_internal_export_pkg_config_file. The functionality of this command consists in checking if the target is internal. Then gets the compile definitions. It performs a search for dependencies that is somewhat similar to qt_get_direct_module_dependencies, although it won't recurse down for more deps. Each dependency is then again, checked if it's internal or has a public interface. Later these deps get deduplicated and lastly a pkgconfig file is filled. The resulting pkgconfig files of many of the Qt6 packages were validated via invocations of `pkg-config --validate` and `pkg-config --simulate` commands and later used to build local projects plus tests that use the pkg-config provided details at compilation time. Although it has some limitations, with qt_internal_add_qml_module if it specifies non-public deps these won't be listed and with non-Qt requirements, notably in static builds, not being appended to the PkgConfig file. Task-number: QTBUG-86080 Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-11 17:39:53 +00:00
if(NOT ${direct})
__qt_internal_walk_libs(
${lib_target}
lib_libs_${target}
lib_rcc_objects_${target}
"${dict_name}" "${operation}" ${collected})
endif()
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
if(lib_libs_${target})
__qt_internal_merge_libs(libs ${lib_libs_${target}})
endif()
if(lib_rcc_objects_${target})
__qt_internal_merge_libs(rcc_objects ${lib_rcc_objects_${target}})
endif()
endif()
CMake: Prevent most global promotion errors when building Qt Backstory. The main reason why we keep getting "unable to promote 3rd party 'X' target to global scope" errors when building Qt repositories, is because we try to promote 3rd party imported targets in a different scope than where the imported targets were created. What were the main motivations for promoting 3rd party targets to global? 1) imported targets are by default local to the directory scope they were created in 2) we want 3rd party targets to be accessible across subdirectory scopes, but looked up once, e.g. qt_find_package(JPEG) looked up in src/gui/CMakeLists.txt, but the target should also be usable in the sibling scope src/plugins/imageformats/CMakeLists.txt Having the package lookup close to the consuming qt module is easier to maintain, because all the other 3rd party dependency lookups are in the same file. This goes against the conventional CMake advice where each subdirectory should look for its own dependencies, or the dependency should be available directly in the root project scope. 3) to make the 3rd party targets available in the root project scope as part of the following flow: QtPostProcess.cmake -> qt_internal_create_module_depends_file() -> qt_collect_third_party_deps() -> get_property(INTERFACE_QT_PACKAGE_NAME) -> write 3rd party Dependencies.cmake file for each qt module. Properties can only be queried from an imported target if it's in the same scope or was promoted to global, otherwise you get 'non-existent target' errors. 4) for prl and pri file generation, where we need the targets to be available during generator expression evaluation within the relevant qt module directory scope Here is a list of approaches I came up with on how to improve the situation. 1) Make all imported targets global during the Qt build, by iterating over the directory property IMPORTED_TARGETS and making each one global. Requires CMake 3.21. Status: Already implemented for a long time, but is opt-in. Pros: Relatively robust Cons: Minimum CMake version for building Qt is 3.16. 2) Make all imported targets global during the Qt build using the CMAKE_FIND_PACKAGE_TARGETS_GLOBAL variable. Requires CMake 3.24. Status: Not implemented, but can be set by Qt builders directly on the command line. Pros: Should be robust Cons: Minimum CMake version for building Qt is 3.16. 3) Abandon the desire to have a single qt_find_package in a single directory scope, and embrace the CMake-way of repeating the dependency in each subdirectory that requires it. Status: Not implemented. Pros: Should be robust Cons: A lot of qt_find_package duplication, will require rewriting various code paths, QtPostProcess would have to be done at directory scope, unclear if dependency tracking will still work work reliably when there might be multiple same-named directory-scoped targets, other unknown unknowns 4) Move all qt_find_package calls into a $repo_name/dependencies.cmake file which would be read at project root scope. This would potentially avoid all scoping issues, because all dependencies will have to be specified at root scope. Status: Not implemented. Pros: No duplication Cons: Dependencies are not scoped anymore to module directories, won't be able to conditionally look for dependencies based on module feature evaluation, not clear yet how this will tie into standalone tests which are in tests/ subdir, other unknown unknowns 5) Try to promote as many 3rd party libraries at project root scope as possible. Currently we have 2 general locations where we look up dependencies. One is each qt_find_package call. The other is Qt6FooDependencies.cmake -> _qt_internal_find_third_party_dependencies(). Many 3rd party targets are created by _qt_internal_find_third_party_dependencies() in the root scope, but not promoted, and then we try to promote them in child scopes using qt_find_package, which causes the promotion errors. Starting with 58eefbd0b6169d0749b312268c1ae1e594e04362 and 37a5e001277db9e1392a242171ab2b88cb6c3049 we now record the provided targets of previous qt_find_package calls. So instead of waiting to try and promote targets later during the configuration process, we can make sure we promote the targets at _qt_internal_find_third_party_dependencies() call time, right when we lookup the Qt dependencies of the qt repo, in the root scope. Status: Implemented in this change Notably, we only promote 3rd party targets to global for qt builds, and not user projects, to not accidentally break user project behaviors. Also, we only promote 3rd party targets, and not Qt internal targets like Qt6::Core, Qt6::Platform, Qt6::PlatformCommonInternal, Qt6::GlobalConfig, etc, for a few reasons: - the code that requires targets to be global only cares about 3rd party targets - promoting the internal targets is more prone to breaking, because there is more than one place where find_package(Qt6Foo) might be called, and if that ends up being in a different directory scope, we encounter the same global promotion errors. Some notable cases where this happens: - tests/CMakeLists.txt brings in extra Qt packages via StandaloneTestsConfig.cmake files - qtbase standalone tests qt_internal_qtbase_pre_project_setup() calls find_package(Qt6 COMPONENTS BuildInternals) which ends up creating the Platform target in the root scope instead of the tests/ scope - Qt6::BundledLibpng links against Core, which ends up trying to promote Core's internal dependencies Platform and GlobalConfig To only promote 3rd party targets, we walk the dependencies of an initial target recursively, and skip promoting targets that have the _qt_is_internal_target or _qt_should_skip_global_promotion_always properties set. Pros: Improves the situation compared to the status quo Cons: Still not ideal due to the various filtering of internal targets and having to mark them as such. 6) Avoid promoting targets to global if we can detect that the target was created in a different scope than where we are trying to promote it. We can do that by comparing the target's BINARY_DIR to the CMAKE_CURRENT_BINARY_DIR and skip promotion if they are not equal. Status: Not implemented, but we can consider it because it's quick to do. Pros: More robust than newly implemented approach (5) Cons: Requires CMake 3.18, because trying to read the BINARY_DIR property on an INTERFACE_LIBRARY would error out. Also, if we implement it and make it the default when using 3.18+, we might 'collect' a lot more hidden promotion errors that will only be revealed later once someone uses CMake 3.16 or 3.17, because most will probably use newer CMake versions. Perhaps the trade-off is worth it? Pick-to: 6.8 Fixes: QTBUG-89204 Fixes: QTBUG-94356 Fixes: QTBUG-95052 Fixes: QTBUG-98807 Fixes: QTBUG-125371 Change-Id: I088a17a98ef35aa69537a3ad208c61de40def581 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 17:10:26 +00:00
if(operation STREQUAL "promote_3rd_party_global")
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
set(lib_target_unaliased "${lib_target}")
Use `_qt_internal_dealias_target` Pick-to: 6.9 6.8 Change-Id: Iffc1148ed7655c724ea0609be01978ab7d5e7f8f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-05 11:17:44 +00:00
_qt_internal_dealias_target(lib_target_unaliased)
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
get_property(is_imported TARGET ${lib_target_unaliased} PROPERTY IMPORTED)
# Allow opting out of promotion. This is useful in certain corner cases
# like with WrapLibClang and Threads in qttools.
CMake: Move some of the target promotion functions to public files They will used from another Public.cmake file in a follow up commit. Pick-to: 6.8 Change-Id: I71b69ed76ca48c391ba45329eb9c305e4a2a238b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-07-08 15:50:48 +00:00
_qt_internal_should_not_promote_package_target_to_global(
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
"${lib_target_unaliased}" should_not_promote)
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
if(is_imported AND NOT should_not_promote)
CMake: Prevent most global promotion errors when building Qt Backstory. The main reason why we keep getting "unable to promote 3rd party 'X' target to global scope" errors when building Qt repositories, is because we try to promote 3rd party imported targets in a different scope than where the imported targets were created. What were the main motivations for promoting 3rd party targets to global? 1) imported targets are by default local to the directory scope they were created in 2) we want 3rd party targets to be accessible across subdirectory scopes, but looked up once, e.g. qt_find_package(JPEG) looked up in src/gui/CMakeLists.txt, but the target should also be usable in the sibling scope src/plugins/imageformats/CMakeLists.txt Having the package lookup close to the consuming qt module is easier to maintain, because all the other 3rd party dependency lookups are in the same file. This goes against the conventional CMake advice where each subdirectory should look for its own dependencies, or the dependency should be available directly in the root project scope. 3) to make the 3rd party targets available in the root project scope as part of the following flow: QtPostProcess.cmake -> qt_internal_create_module_depends_file() -> qt_collect_third_party_deps() -> get_property(INTERFACE_QT_PACKAGE_NAME) -> write 3rd party Dependencies.cmake file for each qt module. Properties can only be queried from an imported target if it's in the same scope or was promoted to global, otherwise you get 'non-existent target' errors. 4) for prl and pri file generation, where we need the targets to be available during generator expression evaluation within the relevant qt module directory scope Here is a list of approaches I came up with on how to improve the situation. 1) Make all imported targets global during the Qt build, by iterating over the directory property IMPORTED_TARGETS and making each one global. Requires CMake 3.21. Status: Already implemented for a long time, but is opt-in. Pros: Relatively robust Cons: Minimum CMake version for building Qt is 3.16. 2) Make all imported targets global during the Qt build using the CMAKE_FIND_PACKAGE_TARGETS_GLOBAL variable. Requires CMake 3.24. Status: Not implemented, but can be set by Qt builders directly on the command line. Pros: Should be robust Cons: Minimum CMake version for building Qt is 3.16. 3) Abandon the desire to have a single qt_find_package in a single directory scope, and embrace the CMake-way of repeating the dependency in each subdirectory that requires it. Status: Not implemented. Pros: Should be robust Cons: A lot of qt_find_package duplication, will require rewriting various code paths, QtPostProcess would have to be done at directory scope, unclear if dependency tracking will still work work reliably when there might be multiple same-named directory-scoped targets, other unknown unknowns 4) Move all qt_find_package calls into a $repo_name/dependencies.cmake file which would be read at project root scope. This would potentially avoid all scoping issues, because all dependencies will have to be specified at root scope. Status: Not implemented. Pros: No duplication Cons: Dependencies are not scoped anymore to module directories, won't be able to conditionally look for dependencies based on module feature evaluation, not clear yet how this will tie into standalone tests which are in tests/ subdir, other unknown unknowns 5) Try to promote as many 3rd party libraries at project root scope as possible. Currently we have 2 general locations where we look up dependencies. One is each qt_find_package call. The other is Qt6FooDependencies.cmake -> _qt_internal_find_third_party_dependencies(). Many 3rd party targets are created by _qt_internal_find_third_party_dependencies() in the root scope, but not promoted, and then we try to promote them in child scopes using qt_find_package, which causes the promotion errors. Starting with 58eefbd0b6169d0749b312268c1ae1e594e04362 and 37a5e001277db9e1392a242171ab2b88cb6c3049 we now record the provided targets of previous qt_find_package calls. So instead of waiting to try and promote targets later during the configuration process, we can make sure we promote the targets at _qt_internal_find_third_party_dependencies() call time, right when we lookup the Qt dependencies of the qt repo, in the root scope. Status: Implemented in this change Notably, we only promote 3rd party targets to global for qt builds, and not user projects, to not accidentally break user project behaviors. Also, we only promote 3rd party targets, and not Qt internal targets like Qt6::Core, Qt6::Platform, Qt6::PlatformCommonInternal, Qt6::GlobalConfig, etc, for a few reasons: - the code that requires targets to be global only cares about 3rd party targets - promoting the internal targets is more prone to breaking, because there is more than one place where find_package(Qt6Foo) might be called, and if that ends up being in a different directory scope, we encounter the same global promotion errors. Some notable cases where this happens: - tests/CMakeLists.txt brings in extra Qt packages via StandaloneTestsConfig.cmake files - qtbase standalone tests qt_internal_qtbase_pre_project_setup() calls find_package(Qt6 COMPONENTS BuildInternals) which ends up creating the Platform target in the root scope instead of the tests/ scope - Qt6::BundledLibpng links against Core, which ends up trying to promote Core's internal dependencies Platform and GlobalConfig To only promote 3rd party targets, we walk the dependencies of an initial target recursively, and skip promoting targets that have the _qt_is_internal_target or _qt_should_skip_global_promotion_always properties set. Pros: Improves the situation compared to the status quo Cons: Still not ideal due to the various filtering of internal targets and having to mark them as such. 6) Avoid promoting targets to global if we can detect that the target was created in a different scope than where we are trying to promote it. We can do that by comparing the target's BINARY_DIR to the CMAKE_CURRENT_BINARY_DIR and skip promotion if they are not equal. Status: Not implemented, but we can consider it because it's quick to do. Pros: More robust than newly implemented approach (5) Cons: Requires CMake 3.18, because trying to read the BINARY_DIR property on an INTERFACE_LIBRARY would error out. Also, if we implement it and make it the default when using 3.18+, we might 'collect' a lot more hidden promotion errors that will only be revealed later once someone uses CMake 3.16 or 3.17, because most will probably use newer CMake versions. Perhaps the trade-off is worth it? Pick-to: 6.8 Fixes: QTBUG-89204 Fixes: QTBUG-94356 Fixes: QTBUG-95052 Fixes: QTBUG-98807 Fixes: QTBUG-125371 Change-Id: I088a17a98ef35aa69537a3ad208c61de40def581 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 17:10:26 +00:00
_qt_internal_promote_3rd_party_target_to_global(
${lib_target_unaliased})
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
endif()
endif()
Consider versioned targets when checking the existens in __qt_internal_walk_libs Since Qt targets now are linked as versioned targets by default, we should adjust the respective check in __qt_internal_walk_libs. Pick-to: 6.7 Change-Id: Idb896c1d9eda944a06d57b0491686cd78e010df0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-04-05 12:17:58 +00:00
elseif("${lib_target}" MATCHES "^(Qt|${QT_CMAKE_EXPORT_NAMESPACE})::(.*)")
Avoid requiring all Qt targets defined for user projects When building user projects replace the FATAL_ERROR about the missing Qt targets with the WARNING and mention that the linking might be incomplete. The updated check affected some user projects that used the linking to the versioned targets and our deferred finalizers. If Qt targets are not propagated to the global scope or not found in the top-level directories, finalizers might fail to resolve these targets. Now users will see the warning. The side effect of the missing targets - missing plugin linking, or incomplete deployment, both use walk libs results. Pick-to: 6.5 6.7 6.8 Change-Id: I5c68b548122775424909c62f904f887417816fbc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-07-02 16:50:46 +00:00
if(QT_BUILDING_QT OR QT_BUILD_STANDALONE_TESTS)
set(message_type FATAL_ERROR)
set(message_addition "")
else()
set(message_type WARNING)
set(message_addition " The linking might be incomplete.")
endif()
message(${message_type} "The ${CMAKE_MATCH_2} target is mentioned as a dependency"
" for ${target}, but not declared.${message_addition}")
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
else()
CMake build: generate pkgconfig for public modules After the update to the CMake based build system the ability to generate pkgconfig files, like it was with QMake, was lost. This patch adds pkgconfig generation again via a new internal command named qt_internal_export_pkg_config_file. The functionality of this command consists in checking if the target is internal. Then gets the compile definitions. It performs a search for dependencies that is somewhat similar to qt_get_direct_module_dependencies, although it won't recurse down for more deps. Each dependency is then again, checked if it's internal or has a public interface. Later these deps get deduplicated and lastly a pkgconfig file is filled. The resulting pkgconfig files of many of the Qt6 packages were validated via invocations of `pkg-config --validate` and `pkg-config --simulate` commands and later used to build local projects plus tests that use the pkg-config provided details at compilation time. Although it has some limitations, with qt_internal_add_qml_module if it specifies non-public deps these won't be listed and with non-Qt requirements, notably in static builds, not being appended to the PkgConfig file. Task-number: QTBUG-86080 Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-11 17:39:53 +00:00
if(NOT operation MATCHES "^(collect|direct)_targets$")
CMake: Add 'collect_targets' mode to __qt_internal_walk_libs Allow collecting all public dependency CMake targets starting from a given initial target. The new mode walks INTERFACE_LINK_LIBRARIES of a shared library or executable target, as well as the INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES of a static library target. Each encountered target (checked with if(TARGET)) is added the output list. Note that the private dependencies of a non-static target (like a shared library or executable) are not walked by the new mode. Introduce a new function called __qt_internal_collect_all_target_dependencies which uses the new mode to collect the full private dependency list of a target. The final list only contains targets, so no linker flags or file paths. This list is useful to do further processing on the targets like extracting properties from them and running finalizers. Task-number: QTBUG-92933 Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
set(final_lib_name_to_merge "${lib_target}")
if(lib_target MATCHES "/([^/]+).framework$")
set(final_lib_name_to_merge "-framework ${CMAKE_MATCH_1}")
endif()
__qt_internal_merge_libs(libs "${final_lib_name_to_merge}")
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
endif()
endif()
endforeach()
__qt_internal_memoize_values_in_dict("${target}" "${dict_name}" "libs" "${libs}")
__qt_internal_memoize_values_in_dict("${target}" "${dict_name}"
"rcc_objects" "${rcc_objects}")
endif()
set(${out_var} ${libs} PARENT_SCOPE)
set(${rcc_objects_out_var} ${rcc_objects} PARENT_SCOPE)
endfunction()
CMake: Add 'collect_targets' mode to __qt_internal_walk_libs Allow collecting all public dependency CMake targets starting from a given initial target. The new mode walks INTERFACE_LINK_LIBRARIES of a shared library or executable target, as well as the INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES of a static library target. Each encountered target (checked with if(TARGET)) is added the output list. Note that the private dependencies of a non-static target (like a shared library or executable) are not walked by the new mode. Introduce a new function called __qt_internal_collect_all_target_dependencies which uses the new mode to collect the full private dependency list of a target. The final list only contains targets, so no linker flags or file paths. This list is useful to do further processing on the targets like extracting properties from them and running finalizers. Task-number: QTBUG-92933 Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
CMake: Handle non-existent targets when collecting dependencies When collecting the dependencies of a target, it can happen that we encounter a target that is not visible in the current directory scope. This can usually be fixed by moving the corresponding find_package call to a higher directory. Detect this situation and print a warning with instruction how to silence this warning: either by fixing the situation or by setting QT_SILENCE_MISSING_DEPENDENCY_TARGET_WARNING. Fixes: QTBUG-108286 Change-Id: I9033fedbd81ef0710b7cc11fab0e94e67c74ff86 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-12-12 11:40:02 +00:00
function(__qt_internal_print_missing_dependency_target_warning target dep)
if(QT_SILENCE_MISSING_DEPENDENCY_TARGET_WARNING)
return()
endif()
message(WARNING
"When trying to collect dependencies of target '${target}', "
"the non-existent target '${dep}' was encountered. "
"This can likely be fixed by moving the find_package call that pulls in "
"'${dep}' to the scope of directory '${CMAKE_CURRENT_LIST_DIR}' or higher. "
"This warning can be silenced by setting QT_SILENCE_MISSING_DEPENDENCY_TARGET_WARNING to "
"ON.")
endfunction()
CMake: Add 'collect_targets' mode to __qt_internal_walk_libs Allow collecting all public dependency CMake targets starting from a given initial target. The new mode walks INTERFACE_LINK_LIBRARIES of a shared library or executable target, as well as the INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES of a static library target. Each encountered target (checked with if(TARGET)) is added the output list. Note that the private dependencies of a non-static target (like a shared library or executable) are not walked by the new mode. Introduce a new function called __qt_internal_collect_all_target_dependencies which uses the new mode to collect the full private dependency list of a target. The final list only contains targets, so no linker flags or file paths. This list is useful to do further processing on the targets like extracting properties from them and running finalizers. Task-number: QTBUG-92933 Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
# Given ${target}, collect all its private dependencies that are CMake targets.
#
# Discards non-CMake-target dependencies like linker flags or file paths.
# Does nothing when given an interface library.
#
# To be used to extract the full list of target dependencies of a library or executable.
function(__qt_internal_collect_all_target_dependencies target out_var)
set(dep_targets "")
get_target_property(target_type ${target} TYPE)
if(NOT target_type STREQUAL "INTERFACE_LIBRARY")
get_target_property(link_libs ${target} LINK_LIBRARIES)
if(link_libs)
foreach(lib ${link_libs})
if(TARGET "${lib}")
list(APPEND dep_targets "${lib}")
__qt_internal_walk_libs(
"${lib}"
lib_walked_targets
_discarded_out_var
"qt_private_link_library_targets"
"collect_targets")
CMake: Handle non-existent targets when collecting dependencies When collecting the dependencies of a target, it can happen that we encounter a target that is not visible in the current directory scope. This can usually be fixed by moving the corresponding find_package call to a higher directory. Detect this situation and print a warning with instruction how to silence this warning: either by fixing the situation or by setting QT_SILENCE_MISSING_DEPENDENCY_TARGET_WARNING. Fixes: QTBUG-108286 Change-Id: I9033fedbd81ef0710b7cc11fab0e94e67c74ff86 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-12-12 11:40:02 +00:00
foreach(lib_target IN LISTS lib_walked_targets)
if(NOT TARGET "${lib_target}")
__qt_internal_print_missing_dependency_target_warning(${target}
${lib_target})
continue()
endif()
list(APPEND dep_targets ${lib_target})
endforeach()
CMake: Add 'collect_targets' mode to __qt_internal_walk_libs Allow collecting all public dependency CMake targets starting from a given initial target. The new mode walks INTERFACE_LINK_LIBRARIES of a shared library or executable target, as well as the INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES of a static library target. Each encountered target (checked with if(TARGET)) is added the output list. Note that the private dependencies of a non-static target (like a shared library or executable) are not walked by the new mode. Introduce a new function called __qt_internal_collect_all_target_dependencies which uses the new mode to collect the full private dependency list of a target. The final list only contains targets, so no linker flags or file paths. This list is useful to do further processing on the targets like extracting properties from them and running finalizers. Task-number: QTBUG-92933 Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
endif()
endforeach()
endif()
endif()
list(REMOVE_DUPLICATES dep_targets)
set(${out_var} "${dep_targets}" PARENT_SCOPE)
endfunction()