AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8761078629
qt5base-lts/cmake/QtPublicTargetHelpers.cmake

311 lines
11 KiB
CMake
Raw Normal View History

CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
function(__qt_internal_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 17:46:24 +00: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 17:01:35 +00: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 17:24:59 +00: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 17:01:35 +00: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 16:54:53 +00: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 17:01:35 +00: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 17:24:59 +00: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 17:01:35 +00: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 17:24:59 +00: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 17:01:35 +00: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 17:24:59 +00: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 17:01:35 +00: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 17:24:59 +00: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 17:01:35 +00: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 16:54:53 +00: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 17:01:35 +00: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()
get_target_property(aliased_target ${target} ALIASED_TARGET)
if(aliased_target)
set(target "${aliased_target}")
endif()
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 17:24:59 +00: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 17:01:35 +00: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 17:24:59 +00: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 17:01:35 +00: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 17:24:59 +00: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 17:01:35 +00: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 17:24:59 +00: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 17:01:35 +00: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 16:00:39 +00: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)
get_target_property(aliased_target ${platform_target} ALIASED_TARGET)
if(aliased_target)
set(platform_target "${aliased_target}")
endif()
__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 11:09:57 +00: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 17:01:35 +00: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 11:09:57 +00: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 17:46:24 +00: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 11:09:57 +00: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 17:46:24 +00: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 15:55:42 +00: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 17:01:35 +00: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 11:09:57 +00: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 15:55:42 +00: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 17:01:35 +00: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 17:46:24 +00: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 11:09:57 +00: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 17:46:24 +00: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 11:09:57 +00: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 13:02:03 +00: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 11:09:57 +00: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 13:02:03 +00: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 11:09:57 +00: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 13:02:03 +00: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 11:09:57 +00: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 13:02:03 +00: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 11:09:57 +00: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 13:02:03 +00: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 11:09:57 +00: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 16:00:39 +00: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 17:46:24 +00: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 11:09:57 +00: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 16:00:39 +00: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 17:46:24 +00: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 11:09:57 +00: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 13:02:03 +00: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 11:09:57 +00: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 16:00:39 +00: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 11:09:57 +00: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 13:02:03 +00: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 11:09:57 +00: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 13:02:03 +00: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 11:09:57 +00: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 16:00:39 +00: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 13:02:03 +00: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 16:00:39 +00: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 13:02:03 +00: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 11:09:57 +00: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 17:46:24 +00: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 12:02:29 +00: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 11:09:57 +00: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 10:41:55 +00: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 12:02:29 +00: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 10:41:55 +00: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 12:02:29 +00: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 11:09:57 +00: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 12:02:29 +00: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 13:16:19 +00: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 12:02:29 +00:00
if(TARGET ${lib})
get_target_property(aliased_target ${lib} ALIASED_TARGET)
if(aliased_target)
set(lib ${aliased_target})
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 11:09:57 +00: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 12:02:29 +00: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 11:09:57 +00: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 12:02:29 +00: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 11:09:57 +00: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 12:02:29 +00: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 11:09:57 +00: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 13:02:03 +00: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 11:09:57 +00: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 12:02:29 +00: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 11:09:57 +00: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 12:02:29 +00: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 11:38:30 +00: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()
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 07:54:47 +00: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 11:38:30 +00: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 07:54:47 +00: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 12:01:59 +00: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)
Call MinGW's ld with -Bstatic when requesting static runtime linkage The -static argument we used before is supported by ld, but not lld. The latter requires --static or -Bstatic. Use -Bstatic, which is supported by both. Pick-to: 6.2 Fixes: QTBUG-89549 Change-Id: I3c3069661bf4cd20e3298aff4714163b7419d3ef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-27 09:13:56 +00:00
target_link_options(${target} INTERFACE "LINKER:-Bstatic")
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 12:01:59 +00:00
endif()
endif()
endfunction()
Reference in New Issue Copy Permalink