1berry/qtbase
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
qtbase/cmake/QtPublicTargetHelpers.cmake

524 lines
19 KiB
CMake
Raw Permalink 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 13:26:52 +02: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 15:21:34 +02: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 13:26:52 +02: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 12:47:52 +02:00
function(__qt_internal_strip_target_directory_scope_token target out_var)
# In CMake versions earlier than CMake 3.18, a subdirectory scope id is appended to the
# target name if the target is referenced in a target_link_libraries command from a
# different directory scope than where the target was created.
# Strip it.
#
# For informational purposes, in CMake 3.18, the target name looks as follows:
# ::@(0x5604cb3f6b50);Threads::Threads;::@
# This case doesn't have to be stripped (at least for now), because when we iterate over
# link libraries, the tokens appear as separate target names.
#
# Example: Threads::Threads::@<0x5604cb3f6b50>
# Output: Threads::Threads
string(REGEX REPLACE "::@<.+>$" "" target "${target}")
set("${out_var}" "${target}" PARENT_SCOPE)
endfunction()
Implement propagation of object files to the end-point executable This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-19 19:46:24 +02:00
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
# Tests if linker could resolve circular dependencies between object files and static libraries.
Remove target specific flags from the linker capabilities check Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-16 19:24:59 +02:00
function(__qt_internal_static_link_order_public_test result)
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
# We could trust iOS linker
if(IOS)
Make QT_HAVE_LINK_ORDER_MATTERS INTERNAL to hide from GUI Hide QT_HAVE_LINK_ORDER_MATTERS from GUI like QtCreator's CMake configurator. Pick-to: 6.1 6.2 Change-Id: I9591092f0902ad17ff260a1ca4494239a7acf6fa Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 18:54:53 +02:00
set(QT_HAVE_LINK_ORDER_MATTERS "FALSE" CACHE INTERNAL "Link order matters")
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
endif()
Remove target specific flags from the linker capabilities check Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-16 19:24:59 +02:00
if(DEFINED QT_HAVE_LINK_ORDER_MATTERS)
set(${result} "${QT_HAVE_LINK_ORDER_MATTERS}" PARENT_SCOPE)
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
return()
endif()
if(EXISTS "${QT_CMAKE_DIR}")
Remove target specific flags from the linker capabilities check Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-16 19:24:59 +02:00
set(test_source_basedir "${QT_CMAKE_DIR}/..")
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
else()
set(test_source_basedir "${_qt_cmake_dir}/${QT_CMAKE_EXPORT_NAMESPACE}")
endif()
try_compile(${result}
Remove target specific flags from the linker capabilities check Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-16 19:24:59 +02:00
"${CMAKE_CURRENT_BINARY_DIR}/config.tests/static_link_order"
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
"${test_source_basedir}/config.tests/static_link_order"
static_link_order_test
static_link_order_test
)
Remove target specific flags from the linker capabilities check Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-16 19:24:59 +02:00
message(STATUS "Check if linker can resolve circular dependencies - ${${result}}")
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
# Invert the result
if(${result})
set(${result} FALSE)
else()
set(${result} TRUE)
endif()
Make QT_HAVE_LINK_ORDER_MATTERS INTERNAL to hide from GUI Hide QT_HAVE_LINK_ORDER_MATTERS from GUI like QtCreator's CMake configurator. Pick-to: 6.1 6.2 Change-Id: I9591092f0902ad17ff260a1ca4494239a7acf6fa Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 18:54:53 +02:00
set(QT_HAVE_LINK_ORDER_MATTERS "${${result}}" CACHE INTERNAL "Link order matters")
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
set(${result} "${${result}}" PARENT_SCOPE)
endfunction()
# Sets _qt_link_order_matters flag for the target.
function(__qt_internal_set_link_order_matters target link_order_matters)
if(NOT TARGET ${target})
message(FATAL_ERROR "Unable to set _qt_link_order_matters flag. ${target} is not a target.")
endif()
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 12:17:44 +01:00
_qt_internal_dealias_target(target)
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
if(link_order_matters)
set(link_order_matters TRUE)
else()
set(link_order_matters FALSE)
endif()
set_target_properties(${target} PROPERTIES _qt_link_order_matters "${link_order_matters}")
endfunction()
# Function combines __qt_internal_static_link_order_public_test and
Remove target specific flags from the linker capabilities check Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-16 19:24:59 +02:00
# __qt_internal_set_link_order_matters calls on Qt::Platform target.
function(__qt_internal_check_link_order_matters)
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
__qt_internal_static_link_order_public_test(
Remove target specific flags from the linker capabilities check Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-16 19:24:59 +02:00
link_order_matters
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
)
__qt_internal_set_link_order_matters(
Remove target specific flags from the linker capabilities check Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-16 19:24:59 +02:00
${QT_CMAKE_EXPORT_NAMESPACE}::Platform "${link_order_matters}"
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
)
Remove target specific flags from the linker capabilities check Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-16 19:24:59 +02:00
if("${ARGC}" GREATER "0" AND NOT ARGV0 STREQUAL "")
set(${ARGV0} ${link_order_matters} PARENT_SCOPE)
endif()
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
endfunction()
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 18:00:39 +02:00
# Constructs a TARGET_POLICY genex expression if the policy is available.
function(__qt_internal_get_cmp0099_genex_check result)
if(POLICY CMP0099)
set(${result} "$<BOOL:$<TARGET_POLICY:CMP0099>>" PARENT_SCOPE)
else()
set(${result} "$<BOOL:FALSE>" PARENT_SCOPE)
endif()
endfunction()
function(__qt_internal_check_cmp0099_available)
set(platform_target ${QT_CMAKE_EXPORT_NAMESPACE}::Platform)
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 12:17:44 +01:00
_qt_internal_dealias_target(platform_target)
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 18:00:39 +02:00
__qt_internal_get_cmp0099_genex_check(cmp0099_check)
set_target_properties(${platform_target} PROPERTIES
_qt_cmp0099_policy_check "${cmp0099_check}"
)
set(result TRUE)
if(NOT POLICY CMP0099)
set(result FALSE)
endif()
if("${ARGC}" GREATER "0" AND NOT ARGV0 STREQUAL "")
set(${ARGV0} ${result} PARENT_SCOPE)
endif()
endfunction()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
function(__qt_internal_process_dependency_object_libraries target)
# The CMake versions greater than 3.21 take care about the order of object files in a
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
# linker line, it's expected that all object files are located at the beginning of the linker
# line.
# So circular dependencies between static libraries and object files are resolved and no need
# to call the finalizer code.
if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.21)
return()
endif()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
get_target_property(processed ${target} _qt_object_libraries_finalizer_processed)
Implement propagation of object files to the end-point executable This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-19 19:46:24 +02:00
if(processed)
return()
endif()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
set_target_properties(${target} PROPERTIES _qt_object_libraries_finalizer_processed TRUE)
Implement propagation of object files to the end-point executable This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-19 19:46:24 +02:00
Disable finalizers by default for the non-ld linkers Check if link order matters before use the object library finalizer. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Change-Id: Ie996bc175ebea36ccda1bb2fe388ae3b7fcde395 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-17 17:55:42 +02:00
get_target_property(qt_link_order_matters
${QT_CMAKE_EXPORT_NAMESPACE}::Platform _qt_link_order_matters
)
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
__qt_internal_check_finalizer_mode(${target}
use_finalizer_mode
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
object_libraries
Disable finalizers by default for the non-ld linkers Check if link order matters before use the object library finalizer. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Change-Id: Ie996bc175ebea36ccda1bb2fe388ae3b7fcde395 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-17 17:55:42 +02:00
DEFAULT_VALUE "${qt_link_order_matters}"
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 19:01:35 +02:00
)
Implement propagation of object files to the end-point executable This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-19 19:46:24 +02:00
if(NOT use_finalizer_mode)
return()
endif()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
__qt_internal_collect_dependency_object_libraries(${target} objects)
target_sources(${target} PRIVATE "${objects}")
Implement propagation of object files to the end-point executable This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-19 19:46:24 +02:00
endfunction()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
function(__qt_internal_collect_dependency_object_libraries target out_var)
set_property(GLOBAL PROPERTY _qt_processed_object_libraries "")
Collect resource objects of plugins and their dependencies in finalizer Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:02:03 +02:00
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
__qt_internal_collect_object_libraries_recursively(object_libraries ${target} ${target})
Collect resource objects of plugins and their dependencies in finalizer Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:02:03 +02:00
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
# Collect object libraries of plugins and plugin dependencies.
Collect resource objects of plugins and their dependencies in finalizer Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:02:03 +02:00
__qt_internal_collect_plugin_targets_from_dependencies(${target} plugin_targets)
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
__qt_internal_collect_dependency_plugin_object_libraries(${target}
Collect resource objects of plugins and their dependencies in finalizer Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:02:03 +02:00
"${plugin_targets}"
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
plugin_objects
Collect resource objects of plugins and their dependencies in finalizer Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:02:03 +02:00
)
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
set_property(GLOBAL PROPERTY _qt_processed_object_libraries "")
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 18:00:39 +02:00
__qt_internal_get_cmp0099_genex_check(cmp0099_check)
Implement propagation of object files to the end-point executable This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-19 19:46:24 +02:00
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
list(REMOVE_DUPLICATES object_libraries)
set(objects "")
foreach(dep IN LISTS object_libraries)
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 18:00:39 +02:00
list(PREPEND objects "$<$<NOT:${cmp0099_check}>:$<TARGET_OBJECTS:${dep}>>")
Implement propagation of object files to the end-point executable This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-19 19:46:24 +02:00
endforeach()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
set(${out_var} "${plugin_objects};${objects}" PARENT_SCOPE)
Collect resource objects of plugins and their dependencies in finalizer Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:02:03 +02:00
endfunction()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
function(__qt_internal_collect_dependency_plugin_object_libraries target plugin_targets out_var)
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 18:00:39 +02:00
__qt_internal_get_cmp0099_genex_check(cmp0099_check)
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
set(plugin_objects "")
Collect resource objects of plugins and their dependencies in finalizer Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:02:03 +02:00
foreach(plugin_target IN LISTS plugin_targets)
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
__qt_internal_collect_object_libraries_recursively(plugin_object_libraries
Collect resource objects of plugins and their dependencies in finalizer Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:02:03 +02:00
"${QT_CMAKE_EXPORT_NAMESPACE}::${plugin_target}"
${target}
)
__qt_internal_get_static_plugin_condition_genex("${plugin_target}" plugin_condition)
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
foreach(plugin_object_library IN LISTS plugin_object_libraries)
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 18:00:39 +02:00
string(JOIN "" plugin_objects_genex
"$<"
"$<AND:"
"$<NOT:${cmp0099_check}>,"
"${plugin_condition}"
">"
":$<TARGET_OBJECTS:${plugin_object_library}>"
">"
Collect resource objects of plugins and their dependencies in finalizer Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:02:03 +02:00
)
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 18:00:39 +02:00
list(APPEND plugin_objects "${plugin_objects_genex}")
Collect resource objects of plugins and their dependencies in finalizer Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:02:03 +02:00
endforeach()
endforeach()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
set(${out_var} "${plugin_objects}" PARENT_SCOPE)
Implement propagation of object files to the end-point executable This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-19 19:46:24 +02:00
endfunction()
Rework resource finalizer approach In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-28 14:02:29 +02:00
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
function(__qt_internal_collect_object_libraries_recursively out_var target initial_target)
get_property(processed_object_libraries GLOBAL PROPERTY _qt_processed_object_libraries)
Do not get LINK_LIBRARY of the interface libraries Avoid getting the LINK_LIBRARY property of the interface libraries when calling a resource object finalizer. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: I19d625a927c66994902f5c89e6c82183c94af91e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-01 12:41:55 +02:00
set(interface_libs "")
set(libs "")
Rework resource finalizer approach In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-28 14:02:29 +02:00
if(NOT "${target}" STREQUAL "${initial_target}")
get_target_property(interface_libs ${target} INTERFACE_LINK_LIBRARIES)
endif()
Do not get LINK_LIBRARY of the interface libraries Avoid getting the LINK_LIBRARY property of the interface libraries when calling a resource object finalizer. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: I19d625a927c66994902f5c89e6c82183c94af91e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-01 12:41:55 +02:00
get_target_property(type ${target} TYPE)
if(NOT type STREQUAL "INTERFACE_LIBRARY")
get_target_property(libs ${target} LINK_LIBRARIES)
endif()
Rework resource finalizer approach In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-28 14:02:29 +02:00
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
set(object_libraries "")
Rework resource finalizer approach In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-28 14:02:29 +02:00
foreach(lib IN LISTS libs interface_libs)
CMake: Pierce through LINK_ONLY deps in finalizer dep traversal Ensure that the finalizer approach of __qt_internal_propagate_object_library considers $<LINK_ONLY:> libraries when traversing the dependencies of a target. The issue was discovered when using the Quick.Shapes QML module in a static build. The module has both a backing library and a plugin. The backing library has some resource objects associated with it. When the targets are exported, the plugin INTERFACE_LINK_LIBRARIES has a $<LINK_ONLY:QuickShapes> dependency. This ensures that the library will be linked, but depending on which linking approach in __qt_internal_propagate_object_library is used, the resources might not be linked to the final executable. The resources are linked correctly when using the target_link_libraries approach, but not when using the finalizer or target_sources approach. This change fixes the finalizer approach, but the target_sources approach is still broken. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Pick-to: 6.2 Change-Id: Ifbb91a17d388c3dc4263e17ec0d3bd5627b57cb4 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-25 15:16:19 +02:00
# Extract possible target from exported LINK_ONLY dependencies.
# This is super important for traversing backing library dependencies of qml plugins.
if(lib MATCHES "^\\$<LINK_ONLY:(.*)>$")
set(lib "${CMAKE_MATCH_1}")
endif()
Rework resource finalizer approach In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-28 14:02:29 +02:00
if(TARGET ${lib})
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 12:17:44 +01:00
_qt_internal_dealias_target(lib)
Rework resource finalizer approach In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-28 14:02:29 +02:00
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
if(${lib} IN_LIST processed_object_libraries)
Rework resource finalizer approach In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-28 14:02:29 +02:00
continue()
else()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
list(APPEND processed_object_libraries ${lib})
set_property(GLOBAL APPEND PROPERTY _qt_processed_object_libraries ${lib})
Rework resource finalizer approach In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-28 14:02:29 +02:00
endif()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
get_target_property(is_qt_propagated_object_library ${lib}
_is_qt_propagated_object_library
)
if(is_qt_propagated_object_library)
list(APPEND object_libraries ${lib})
Rework resource finalizer approach In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-28 14:02:29 +02:00
else()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
__qt_internal_collect_object_libraries_recursively(next_level_object_libraries
Collect resource objects of plugins and their dependencies in finalizer Resource objects might be linked to plugins. Since some plugins may be present in LINK_LIBRARIES as the complex genexes, need to collect them explicitly and iterate over plugin targets to find resource object libraries that need to be exposed to end-point target executable. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8 Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:02:03 +02:00
${lib}
${initial_target}
)
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
list(APPEND object_libraries ${next_level_object_libraries})
Rework resource finalizer approach In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-28 14:02:29 +02:00
endif()
endif()
endforeach()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 13:09:57 +02:00
set(${out_var} "${object_libraries}" PARENT_SCOPE)
Rework resource finalizer approach In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-28 14:02:29 +02:00
endfunction()
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 13:38:30 +02:00
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 17:50:48 +02:00
# Sets out_var to to TRUE if the target was marked to not be promoted to global scope.
function(_qt_internal_should_not_promote_package_target_to_global target out_var)
get_property(should_not_promote TARGET "${target}" PROPERTY _qt_no_promote_global)
set("${out_var}" "${should_not_promote}" PARENT_SCOPE)
endfunction()
# This function recursively walks transitive link libraries of the given target
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 19:10:26 +02:00
# and promotes encountered 3rd party targets to be IMPORTED_GLOBAL if they are not.
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 17:50:48 +02:00
#
# This is required for .prl file generation in top-level builds, to make sure that imported 3rd
# party library targets in any repo are made global, so there are no scoping issues.
#
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 19:10:26 +02:00
# The promotion needs to happen in the same directory scope where the imported target is
# first created.
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 17:50:48 +02:00
#
# Uses __qt_internal_walk_libs.
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 19:10:26 +02:00
function(_qt_internal_promote_3rd_party_link_targets_to_global target)
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 17:50:48 +02:00
__qt_internal_walk_libs("${target}" _discarded_out_var _discarded_out_var_2
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 19:10:26 +02:00
"qt_find_package_targets_dict" "promote_3rd_party_global")
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 17:50:48 +02:00
endfunction()
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 19:10:26 +02:00
# Check if a target is an internal target (one added by qt_internal_* API, executables, libraries,
# etc).
function(_qt_internal_is_internal_target target out_var)
get_target_property(is_internal ${target} _qt_is_internal_target)
if(is_internal)
set(value TRUE)
else()
set(value FALSE)
endif()
set(${out_var} "${value}" PARENT_SCOPE)
endfunction()
# Check if a target should never be promoted to global.
# Some targets like the Platform target is public, and can't have _qt_is_internal_target set.
# But we still want to avoid promoting it to global. Setting this property achieves that.
function(_qt_internal_should_skip_3rd_party_global_promotion target out_var)
get_target_property(should_skip ${target} _qt_should_skip_3rd_party_global_promotion)
if(should_skip)
set(value TRUE)
else()
set(value FALSE)
endif()
set(${out_var} "${value}" PARENT_SCOPE)
endfunction()
# Tries to promote any non-global imported target to global scope.
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 13:38:30 +02:00
function(__qt_internal_promote_target_to_global target)
get_property(is_global TARGET ${target} PROPERTY IMPORTED_GLOBAL)
if(NOT is_global)
message(DEBUG "Promoting target to global: '${target}'")
set_property(TARGET ${target} PROPERTY IMPORTED_GLOBAL TRUE)
endif()
endfunction()
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 19:10:26 +02:00
# Promotes a 3rd party provided target to global, which was found by qt_find_package or
# _qt_internal_find_third_party_dependencies.
# Only does it when building Qt, but not when building user projects.
function(_qt_internal_promote_3rd_party_provided_target_and_3rd_party_deps_to_global target)
# Return early if building a user project, and not Qt.
# QT_BUILDING_QT is set when building a qt repo, but we also check for QT_REPO_MODULE_VERSION,
# which is set in .cmake.conf, because _qt_internal_find_third_party_dependencies is called
# before QT_BUILDING_QT is set.
if(NOT (QT_BUILDING_QT OR QT_REPO_MODULE_VERSION))
return()
endif()
# Return early if the provided target does not exist, which can happen in the case of zstd,
# where we list multiple possible target names, but only some will be available.
if(NOT TARGET "${target}")
return()
endif()
get_property(is_global TARGET "${target}" PROPERTY IMPORTED_GLOBAL)
_qt_internal_should_not_promote_package_target_to_global("${target}" should_not_promote)
if(NOT is_global AND NOT should_not_promote)
_qt_internal_promote_3rd_party_target_to_global(${target})
_qt_internal_promote_3rd_party_link_targets_to_global("${target}")
endif()
endfunction()
# Tries to promote a non-global imported 3rd party target to global scope.
# 3rd party targets are usually system library targets.
# - targets that were not created by qt_internal_add_foo commands
# - targets that don't have the should_skip_global_promotion property
function(_qt_internal_promote_3rd_party_target_to_global target)
get_property(is_global TARGET ${target} PROPERTY IMPORTED_GLOBAL)
if(NOT is_global)
_qt_internal_is_internal_target("${target}" is_internal)
_qt_internal_should_skip_3rd_party_global_promotion("${target}" should_skip)
if(NOT is_internal AND NOT should_skip)
__qt_internal_promote_target_to_global("${target}")
endif()
endif()
endfunction()
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 13:38:30 +02:00
function(__qt_internal_promote_target_to_global_checked target)
CMake: Promote all targets to global within a scope when possible CMake 3.21 introduced a new IMPORTED_TARGETS directory property which we can use to promote all imported targets within a scope to be global. This would cover transitive non-Qt imported targets which the Qt build system does not know about and is thus a more complete solution compared to promoting only Qt targets. Run a finalizer at the end of the directory scope where find_package(Qt6) is called to promote all imported targets within that scope to global (when requested). The old promotion method is disabled when the CMake version is new enough. Pick-to: 6.2 Task-number: QTBUG-92878 Task-number: QTBUG-94528 Change-Id: I533a3bd4186eba652f878ddd72c76118c2fd8bae Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-11 09:54:47 +02:00
# With CMake version 3.21 we use a different mechanism that allows us to promote all targets
# within a scope.
if(QT_PROMOTE_TO_GLOBAL_TARGETS AND CMAKE_VERSION VERSION_LESS 3.21)
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 13:38:30 +02:00
__qt_internal_promote_target_to_global(${target})
endif()
endfunction()
CMake: Promote all targets to global within a scope when possible CMake 3.21 introduced a new IMPORTED_TARGETS directory property which we can use to promote all imported targets within a scope to be global. This would cover transitive non-Qt imported targets which the Qt build system does not know about and is thus a more complete solution compared to promoting only Qt targets. Run a finalizer at the end of the directory scope where find_package(Qt6) is called to promote all imported targets within that scope to global (when requested). The old promotion method is disabled when the CMake version is new enough. Pick-to: 6.2 Task-number: QTBUG-92878 Task-number: QTBUG-94528 Change-Id: I533a3bd4186eba652f878ddd72c76118c2fd8bae Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-11 09:54:47 +02:00
function(__qt_internal_promote_targets_in_dir_scope_to_global)
# IMPORTED_TARGETS got added in 3.21.
if(CMAKE_VERSION VERSION_LESS 3.21)
return()
endif()
get_directory_property(targets IMPORTED_TARGETS)
foreach(target IN LISTS targets)
__qt_internal_promote_target_to_global(${target})
endforeach()
endfunction()
function(__qt_internal_promote_targets_in_dir_scope_to_global_checked)
if(QT_PROMOTE_TO_GLOBAL_TARGETS)
__qt_internal_promote_targets_in_dir_scope_to_global()
endif()
endfunction()
# This function ends up being called multiple times as part of a find_package(Qt6Foo) call,
# due sub-packages depending on the Qt6 package. Ensure the finalizer is ran only once per
# directory scope.
function(__qt_internal_defer_promote_targets_in_dir_scope_to_global)
get_directory_property(is_deferred _qt_promote_targets_is_deferred)
if(NOT is_deferred)
set_property(DIRECTORY PROPERTY _qt_promote_targets_is_deferred TRUE)
if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.19)
cmake_language(DEFER CALL __qt_internal_promote_targets_in_dir_scope_to_global_checked)
endif()
endif()
endfunction()
CMake: Use correct MSVC runtime library for Qt object libraries If Qt was configured with -static-runtime which implies MultiThreaded -MT flag, the plugin initializer object libraries were still compiled with the default -MD flag. When an application linked to Qt, that caused linking to fail with mismatched symbol errors between the application symbols and the plugin initializer object library symbols. Make sure to set the MSVC_RUNTIME_LIBRARY property on both plugin initializer and resource object libraries, depending on the value of QT_FEATURE_static_runtime. We did set the property for resources added by qt_internal_add_resource, but not for the resource created by the public qt6_add_resources counterpart. Pick-to: 6.2 Fixes: QTBUG-95043 Change-Id: Ia543cd0241db94a12080be2655ad420fe9ad3f24 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-08 14:01:59 +02:00
function(_qt_internal_set_up_static_runtime_library target)
if(QT_FEATURE_static_runtime)
if(MSVC)
set_property(TARGET ${target} PROPERTY
MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")
elseif(MINGW)
CMake: use correct link flag for MinGW(GCC) static-runtime build When using MinGW compiler and Qt is configured with "-static-runtime", we should pass "-static" to g++ while linking, like Qt 5, instead of "-Wl,-Bstatic", to get rid of dependencies on libgcc_s_seh-1.dll, libwinpthread-1.dll and libstdc++-6.dll. Because syncqt doesn't link to any Qt library, "target_link_options(${target} INTERFACE -static)" has no effect on it. So we should use "PRIVATE" instead of "INTERFACE" for executables. Pick-to: 6.6 6.5 Change-Id: Icf551783f92ef3615b3840c9af16d163eee09fdb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-19 16:27:58 +08:00
get_target_property(target_type ${target} TYPE)
if(target_type STREQUAL "EXECUTABLE")
set(link_option PRIVATE)
else()
set(link_option INTERFACE)
endif()
if(CLANG)
target_link_options(${target} ${link_option} "LINKER:-Bstatic")
else()
target_link_options(${target} ${link_option} "-static")
endif()
CMake: Use correct MSVC runtime library for Qt object libraries If Qt was configured with -static-runtime which implies MultiThreaded -MT flag, the plugin initializer object libraries were still compiled with the default -MD flag. When an application linked to Qt, that caused linking to fail with mismatched symbol errors between the application symbols and the plugin initializer object library symbols. Make sure to set the MSVC_RUNTIME_LIBRARY property on both plugin initializer and resource object libraries, depending on the value of QT_FEATURE_static_runtime. We did set the property for resources added by qt_internal_add_resource, but not for the resource created by the public qt6_add_resources counterpart. Pick-to: 6.2 Fixes: QTBUG-95043 Change-Id: Ia543cd0241db94a12080be2655ad420fe9ad3f24 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-08 14:01:59 +02:00
endif()
endif()
endfunction()
CMake: Warn when examples are not added via qt_internal_add_example To ensure examples can be built as ExternalProjects, the example subdirectories need to be added via qt_internal_add_example rather than just add_subdirectory. qt_internal_add_example is also needed for correct installation of example sources. To catch examples that are still not added via qt_internal_add_example, set a QT_WARN_ABOUT_EXAMPLE_ADD_SUBDIRECTORY variable at the top of the examples/CMakeLists.txt directory scope and show a warning in qt_add_executable whenever that variable is TRUE. Calls of qt_internal_add_example will set the variable to FALSE, making sure the warning is not shown for properly added examples. This is limited to developer builds and can be opted out of via the QT_NO_WARN_ABOUT_EXAMPLE_ADD_SUBDIRECTORY_WARNING variable. qt_add_executable is used as the 'hook' for showing the error, because that is the most likely function to be used in examples. We don't use qt_standard_project_setup in all projects yet, so we don't want to use that one. Task-number: QTBUG-90820 Task-number: QTBUG-123096 Change-Id: I7a0b0b2cc60c70903db03b56c06494c127a62420 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-03-07 15:32:17 +01:00
function(_qt_internal_warn_about_example_add_subdirectory)
# This is set by qt_build_repo_impl_examples() in QtBuildRepoHelpers.cmake, only for developer
# builds, to catch examples that are added via add_subdirectory instead of via
# qt_internal_add_example.
if(QT_WARN_ABOUT_EXAMPLE_ADD_SUBDIRECTORY)
get_filename_component(dir_name "${PROJECT_SOURCE_DIR}" NAME)
message(AUTHOR_WARNING
"It looks like this example project was added via add_subdirectory instead of via "
"qt_internal_add_example. This causes issues in certain build configurations. Please "
"change the code to use\n qt_internal_add_example(${dir_name})\ninstead."
)
endif()
endfunction()
Add `_qt_internal_set_source_file_generated` function Create a function `_qt_internal_set_source_file_generated` that sets the source file property `GENERATED` along with Qt relevant properties: - `SKIP_LINTING` if CMake>=3.27 and `QT_FEATURE_lint_generated_code` Task-number: QTBUG-125077 Pick-to: 6.9 Change-Id: I0ef5f7901f502366aaf2d020554c72e4845101b6 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-06 17:14:40 +01:00
# Mark source files as generated.
#
# This sets `GENERATED` property to TRUE, along with other Qt relevant properties,
# e.g. `SKIP_LINTING`.
#
# Synopsis
#
# _qt_internal_set_source_file_generated(SOURCE <src1> ...
# [CONFIGURE_GENERATED]
# [SKIP_AUTOGEN]
# [DIRECTORY <dirs> ...]
# [TARGET_DIRECTORY <targets> ...]
# )
#
# Arguments
#
# `SOURCES`
# Source files that are generated.
#
# Equivalent to `set_source_files_properties(<files>)`.
#
# `DIRECTORY`
# Equivalent to `set_source_files_properties(DIRECTORY)`.
#
# `TARGET_DIRECTORY`
# Equivalent to `set_source_files_properties(TARGET_DIRECTORY)`.
#
# `SKIP_AUTOGEN`
# Set SKIP_AUTOGEN property to True as well.
#
# `CONFIGURE_GENERATED`
# Files are generated with `configure_file`.
# Does not set `GENERATED TRUE` property. This is needed to avoid removing the file when
# running the clean target.
function(_qt_internal_set_source_file_generated)
set(option_args
SKIP_AUTOGEN
CONFIGURE_GENERATED
)
set(single_args "")
set(multi_args
SOURCES
DIRECTORY
TARGET_DIRECTORY
)
cmake_parse_arguments(PARSE_ARGV 0 arg
"${option_args}" "${single_args}" "${multi_args}"
)
# Parse required variables
if(NOT arg_SOURCES AND QT_FEATURE_developer_build)
message(WARNING
"Unexpected call _qt_internal_set_source_file_generated with empty `SOURCES`."
)
endif()
# Prepend again the appropriate keywords to pass to `set_source_files_properties`
if(arg_DIRECTORY)
list(PREPEND arg_DIRECTORY DIRECTORY)
endif()
if(arg_TARGET_DIRECTORY)
list(PREPEND arg_TARGET_DIRECTORY TARGET_DIRECTORY)
endif()
# Construct the properties list
set(properties "")
if(NOT arg_CONFIGURE_GENERATED)
list(APPEND properties
GENERATED TRUE
)
endif()
if(arg_SKIP_AUTOGEN)
list(APPEND properties
SKIP_AUTOGEN TRUE
)
endif()
# Add SKIP_LINTING if possible. We do not add it unconditionally here to avoid
# confusion when CMake ignores this variable.
if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.27" AND NOT QT_FEATURE_lint_generated_code)
list(APPEND properties
SKIP_LINTING TRUE
)
endif()
set_source_files_properties(${arg_SOURCES}
${arg_DIRECTORY}
${arg_TARGET_DIRECTORY}
PROPERTIES ${properties}
)
endfunction()
Add helper function `_qt_internal_get_real_target` Also a shortcut `_qt_internal_dealias_target` Pick-to: 6.9 6.8 Change-Id: Ic772896f7bf2f3fb05dd4799b1a8aabbc4379930 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-05 12:04:30 +01:00
# Get the real target checking for ALIASED_TARGET
function(_qt_internal_get_real_target out_var target)
get_target_property(aliased_target "${target}" ALIASED_TARGET)
if(aliased_target)
set(${out_var} "${aliased_target}" PARENT_SCOPE)
else()
set(${out_var} "${target}" PARENT_SCOPE)
endif()
endfunction()
# Helpful shortcut to `_qt_internal_get_real_target` if we just need to dealias
function(_qt_internal_dealias_target target_var)
_qt_internal_get_real_target(${target_var} ${${target_var}})
set(${target_var} "${${target_var}}" PARENT_SCOPE)
endfunction()
Reference in New Issue Copy Permalink