qt5base-lts/cmake/QtFindPackageHelpers.cmake

536 lines
25 KiB
CMake
Raw Normal View History

# Copyright (C) 2022 The Qt Company Ltd.
# SPDX-License-Identifier: BSD-3-Clause
# This function recursively walks transitive link libraries of the given target
# and promotes those targets to be IMPORTED_GLOBAL if they are not.
#
# This is required for .prl file generation in top-level builds, to make sure that imported 3rd
# party library targets in any repo are made global, so there are no scoping issues.
#
# Only works if called from qt_find_package(), because the promotion needs to happen in the same
# directory scope where the imported target is first created.
#
# Uses __qt_internal_walk_libs.
function(qt_find_package_promote_targets_to_global_scope target)
__qt_internal_walk_libs("${target}" _discarded_out_var _discarded_out_var_2
"qt_find_package_targets_dict" "promote_global")
endfunction()
macro(qt_find_package)
# Get the target names we expect to be provided by the package.
set(find_package_options CONFIG NO_MODULE MODULE REQUIRED)
set(options ${find_package_options} MARK_OPTIONAL)
set(oneValueArgs MODULE_NAME QMAKE_LIB)
set(multiValueArgs PROVIDED_TARGETS COMPONENTS OPTIONAL_COMPONENTS)
cmake_parse_arguments(arg "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
# If some Qt internal project calls qt_find_package(WrapFreeType), but WrapFreeType was already
# found as part of a find_dependency() call from a ModuleDependencies.cmake file (or similar),
# and the provided target is also found, that means this might have been an unnecessary
# qt_find_package() call, because the dependency was already found via some other transitive
# dependency. Return early, so that CMake doesn't fail with an error with trying to promote the
# targets to be global. This behavior is not enabled by default, because there are cases
# when a regular find_package() (non qt_) can find a package (Freetype -> PNG), and a subsequent
# qt_find_package(PNG PROVIDED_TARGET PNG::PNG) still needs to succeed and register the provided
# targets. To enable the debugging behavior, set QT_DEBUG_QT_FIND_PACKAGE to 1.
set(_qt_find_package_skip_find_package FALSE)
CMake: Reconfigure faster by not looking for missing packages Instead of constantly trying to find packages by calling qt_find_package on each reconfiguration, record which packages were found during initial configuration. Then on a second reconfiguration, skip looking for packages that were not found on the initial configuration. This speeds up reconfiguration on certain platforms and repos. Here are some stats for my macOS qtbase build. not skip 3.69s user 4.96s system 98% cpu 8.750 total skip 2.69s user 1.00s system 97% cpu 3.792 total Top-level build with -submodules=qtquick3d not skip 15.03s user 10.58s system 97% cpu 26.334 total skip 13.87s user 5.16s system 96% cpu 19.724 total Note this is a behavior change from how find_package is used in most CMake projects, where if a package was previously missing, the developer can just install the package and reconfigure to pick it up. With this change, they will first have to remove their CMakeCache.txt file and configure from scratch, or remove the QT_INTERNAL_PREVIOUSLY_FOUND_PACKAGES cache variable and reconfigure. For this reason, we enable this behavior by default only in -developer-builds. Builders can also opt in or out by setting the QT_INTERNAL_SAVE_PREVIOUSLY_FOUND_PACKAGES variable to either ON or OFF. Note this behavior does not apply to user projects, or direct find_package calls (as opposed to qt_find_package). Fixes: QTBUG-107251 Change-Id: Iee9c5d120eb09e2a94eebb059a2174ef6b241e03 Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-09-27 16:20:49 +00:00
# Skip looking for packages that were not found on initial configuration, because they likely
# won't be found again, and only waste configuration time.
# Speeds up reconfiguration configuration for certain platforms and repos.
# Due to this behavior being different from what general CMake projects expect, it is only
# done for -developer-builds.
if(QT_INTERNAL_PREVIOUSLY_FOUND_PACKAGES AND
NOT "${ARGV0}" IN_LIST QT_INTERNAL_PREVIOUSLY_FOUND_PACKAGES)
set(_qt_find_package_skip_find_package TRUE)
endif()
if(QT_DEBUG_QT_FIND_PACKAGE AND ${ARGV0}_FOUND AND arg_PROVIDED_TARGETS)
set(_qt_find_package_skip_find_package TRUE)
foreach(qt_find_package_target_name ${arg_PROVIDED_TARGETS})
if(NOT TARGET ${qt_find_package_target_name})
set(_qt_find_package_skip_find_package FALSE)
endif()
endforeach()
if(_qt_find_package_skip_find_package)
message(AUTHOR_WARNING "qt_find_package(${ARGV0}) called even though the package "
"was already found. Consider removing the call.")
endif()
endif()
# When configure.cmake is included only to record summary entries, there's no point in looking
# for the packages.
if(__QtFeature_only_record_summary_entries)
set(_qt_find_package_skip_find_package TRUE)
endif()
# Get the version if specified.
set(package_version "")
if(${ARGC} GREATER_EQUAL 2)
if(${ARGV1} MATCHES "^[0-9\.]+$")
set(package_version "${ARGV1}")
endif()
endif()
if(arg_COMPONENTS)
# Re-append components to forward them.
list(APPEND arg_UNPARSED_ARGUMENTS "COMPONENTS;${arg_COMPONENTS}")
endif()
if(arg_OPTIONAL_COMPONENTS)
# Re-append optional components to forward them.
list(APPEND arg_UNPARSED_ARGUMENTS "OPTIONAL_COMPONENTS;${arg_OPTIONAL_COMPONENTS}")
endif()
# Don't look for packages in PATH if requested to.
if(QT_NO_USE_FIND_PACKAGE_SYSTEM_ENVIRONMENT_PATH)
set(_qt_find_package_use_system_env_backup "${CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH}")
set(CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH "OFF")
endif()
if(NOT (arg_CONFIG OR arg_NO_MODULE OR arg_MODULE) AND NOT _qt_find_package_skip_find_package)
# Try to find a config package first in quiet mode
set(config_package_arg ${arg_UNPARSED_ARGUMENTS})
list(APPEND config_package_arg "CONFIG;QUIET")
find_package(${config_package_arg})
# Double check that in config mode the targets become visible. Sometimes
# only the module mode creates the targets. For example with vcpkg, the sqlite
# package provides sqlite3-config.cmake, which offers multi-config targets but
# in their own way. CMake has FindSQLite3.cmake and with the original
# qt_find_package(SQLite3) call it is our intention to use the cmake package
# in module mode.
unset(_qt_any_target_found)
unset(_qt_should_unset_found_var)
if(${ARGV0}_FOUND AND arg_PROVIDED_TARGETS)
foreach(expected_target ${arg_PROVIDED_TARGETS})
if (TARGET ${expected_target})
set(_qt_any_target_found TRUE)
break()
endif()
endforeach()
if(NOT _qt_any_target_found)
set(_qt_should_unset_found_var TRUE)
endif()
endif()
# If we consider the package not to be found, make sure to unset both regular
# and CACHE vars, otherwise CMP0126 set to NEW might cause issues with
# packages not being found correctly.
if(NOT ${ARGV0}_FOUND OR _qt_should_unset_found_var)
unset(${ARGV0}_FOUND)
unset(${ARGV0}_FOUND CACHE)
# Unset the NOTFOUND ${package}_DIR var that might have been set by the previous
# find_package call, to get rid of "not found" messages in the feature summary
# if the package is found by the next find_package call.
if(DEFINED CACHE{${ARGV0}_DIR} AND NOT ${ARGV0}_DIR)
unset(${ARGV0}_DIR CACHE)
endif()
endif()
endif()
# Ensure the options are back in the original unparsed arguments
foreach(opt IN LISTS find_package_options)
if(arg_${opt})
list(APPEND arg_UNPARSED_ARGUMENTS ${opt})
endif()
endforeach()
# TODO: Handle packages with components where a previous component is already found.
# E.g. find_package(Qt6 COMPONENTS BuildInternals) followed by
# qt_find_package(Qt6 COMPONENTS Core) doesn't end up calling find_package(Qt6Core).
if (NOT ${ARGV0}_FOUND AND NOT _qt_find_package_skip_find_package)
# Call original function without our custom arguments.
find_package(${arg_UNPARSED_ARGUMENTS})
endif()
if(QT_NO_USE_FIND_PACKAGE_SYSTEM_ENVIRONMENT_PATH)
if("${_qt_find_package_use_system_env_backup}" STREQUAL "")
unset(CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH)
else()
set(CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH "${_qt_find_package_use_system_env_backup}")
endif()
endif()
CMake: Reconfigure faster by not looking for missing packages Instead of constantly trying to find packages by calling qt_find_package on each reconfiguration, record which packages were found during initial configuration. Then on a second reconfiguration, skip looking for packages that were not found on the initial configuration. This speeds up reconfiguration on certain platforms and repos. Here are some stats for my macOS qtbase build. not skip 3.69s user 4.96s system 98% cpu 8.750 total skip 2.69s user 1.00s system 97% cpu 3.792 total Top-level build with -submodules=qtquick3d not skip 15.03s user 10.58s system 97% cpu 26.334 total skip 13.87s user 5.16s system 96% cpu 19.724 total Note this is a behavior change from how find_package is used in most CMake projects, where if a package was previously missing, the developer can just install the package and reconfigure to pick it up. With this change, they will first have to remove their CMakeCache.txt file and configure from scratch, or remove the QT_INTERNAL_PREVIOUSLY_FOUND_PACKAGES cache variable and reconfigure. For this reason, we enable this behavior by default only in -developer-builds. Builders can also opt in or out by setting the QT_INTERNAL_SAVE_PREVIOUSLY_FOUND_PACKAGES variable to either ON or OFF. Note this behavior does not apply to user projects, or direct find_package calls (as opposed to qt_find_package). Fixes: QTBUG-107251 Change-Id: Iee9c5d120eb09e2a94eebb059a2174ef6b241e03 Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-09-27 16:20:49 +00:00
if(${ARGV0}_FOUND)
# Record that the package was found, so that future reconfigurations can be sped up.
set_property(GLOBAL APPEND PROPERTY _qt_previously_found_packages "${ARGV0}")
endif()
if(${ARGV0}_FOUND AND arg_PROVIDED_TARGETS AND NOT _qt_find_package_skip_find_package)
# If package was found, associate each target with its package name. This will be used
# later when creating Config files for Qt libraries, to generate correct find_dependency()
# calls. Also make the provided targets global, so that the properties can be read in
# all scopes.
foreach(qt_find_package_target_name ${arg_PROVIDED_TARGETS})
if(TARGET ${qt_find_package_target_name})
# Allow usage of aliased targets by setting properties on the actual target
get_target_property(aliased_target ${qt_find_package_target_name} ALIASED_TARGET)
if(aliased_target)
set(qt_find_package_target_name ${aliased_target})
endif()
set_target_properties(${qt_find_package_target_name} PROPERTIES
INTERFACE_QT_PACKAGE_NAME ${ARGV0}
INTERFACE_QT_PACKAGE_IS_OPTIONAL ${arg_MARK_OPTIONAL})
if(package_version)
set_target_properties(${qt_find_package_target_name}
PROPERTIES INTERFACE_QT_PACKAGE_VERSION ${ARGV1})
endif()
if(arg_COMPONENTS)
string(REPLACE ";" " " components_as_string "${arg_COMPONENTS}")
set_property(TARGET ${qt_find_package_target_name}
PROPERTY INTERFACE_QT_PACKAGE_COMPONENTS ${components_as_string})
endif()
if(arg_OPTIONAL_COMPONENTS)
string(REPLACE ";" " " components_as_string "${arg_OPTIONAL_COMPONENTS}")
set_property(TARGET ${qt_find_package_target_name}
PROPERTY INTERFACE_QT_PACKAGE_OPTIONAL_COMPONENTS
${components_as_string})
endif()
get_property(is_global TARGET ${qt_find_package_target_name} PROPERTY
IMPORTED_GLOBAL)
qt_internal_should_not_promote_package_target_to_global(
"${qt_find_package_target_name}" should_not_promote)
if(NOT is_global AND NOT should_not_promote)
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
__qt_internal_promote_target_to_global(${qt_find_package_target_name})
qt_find_package_promote_targets_to_global_scope(
"${qt_find_package_target_name}")
endif()
endif()
endforeach()
if(arg_MODULE_NAME AND arg_QMAKE_LIB
AND (NOT arg_QMAKE_LIB IN_LIST QT_QMAKE_LIBS_FOR_${arg_MODULE_NAME}))
set(QT_QMAKE_LIBS_FOR_${arg_MODULE_NAME}
${QT_QMAKE_LIBS_FOR_${arg_MODULE_NAME}};${arg_QMAKE_LIB} CACHE INTERNAL "")
set(QT_TARGETS_OF_QMAKE_LIB_${arg_QMAKE_LIB} ${arg_PROVIDED_TARGETS} CACHE INTERNAL "")
foreach(provided_target ${arg_PROVIDED_TARGETS})
set(QT_QMAKE_LIB_OF_TARGET_${provided_target} ${arg_QMAKE_LIB} CACHE INTERNAL "")
endforeach()
endif()
endif()
endmacro()
CMake: Reconfigure faster by not looking for missing packages Instead of constantly trying to find packages by calling qt_find_package on each reconfiguration, record which packages were found during initial configuration. Then on a second reconfiguration, skip looking for packages that were not found on the initial configuration. This speeds up reconfiguration on certain platforms and repos. Here are some stats for my macOS qtbase build. not skip 3.69s user 4.96s system 98% cpu 8.750 total skip 2.69s user 1.00s system 97% cpu 3.792 total Top-level build with -submodules=qtquick3d not skip 15.03s user 10.58s system 97% cpu 26.334 total skip 13.87s user 5.16s system 96% cpu 19.724 total Note this is a behavior change from how find_package is used in most CMake projects, where if a package was previously missing, the developer can just install the package and reconfigure to pick it up. With this change, they will first have to remove their CMakeCache.txt file and configure from scratch, or remove the QT_INTERNAL_PREVIOUSLY_FOUND_PACKAGES cache variable and reconfigure. For this reason, we enable this behavior by default only in -developer-builds. Builders can also opt in or out by setting the QT_INTERNAL_SAVE_PREVIOUSLY_FOUND_PACKAGES variable to either ON or OFF. Note this behavior does not apply to user projects, or direct find_package calls (as opposed to qt_find_package). Fixes: QTBUG-107251 Change-Id: Iee9c5d120eb09e2a94eebb059a2174ef6b241e03 Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-09-27 16:20:49 +00:00
# Save found packages in the cache. They will be read on next reconfiguration to skip looking
# for packages that were not previously found.
# Only applies to -developer-builds by default.
# Can also be opted in or opted out via QT_INTERNAL_SAVE_PREVIOUSLY_FOUND_PACKAGES.
# Opting out will need two reconfigurations to take effect.
function(qt_internal_save_previously_found_packages)
if(DEFINED QT_INTERNAL_SAVE_PREVIOUSLY_FOUND_PACKAGES)
set(should_save "${QT_INTERNAL_SAVE_PREVIOUSLY_FOUND_PACKAGES}")
else()
if(FEATURE_developer_build OR QT_FEATURE_developer_build)
set(should_save ON)
else()
set(should_save OFF)
endif()
endif()
if(NOT should_save)
# When the value is flipped to OFF, remove any previously saved packages.
unset(QT_INTERNAL_PREVIOUSLY_FOUND_PACKAGES CACHE)
return()
endif()
get_property(_qt_previously_found_packages GLOBAL PROPERTY _qt_previously_found_packages)
if(_qt_previously_found_packages)
list(REMOVE_DUPLICATES _qt_previously_found_packages)
set(QT_INTERNAL_PREVIOUSLY_FOUND_PACKAGES "${_qt_previously_found_packages}" CACHE INTERNAL
"List of CMake packages found during configuration using qt_find_package.")
endif()
endfunction()
# Return qmake library name for the given target, e.g. return "vulkan" for "Vulkan::Vulkan".
function(qt_internal_map_target_to_qmake_lib target out_var)
set(${out_var} "${QT_QMAKE_LIB_OF_TARGET_${target}}" PARENT_SCOPE)
endfunction()
# This function records a dependency between ${main_target_name} and ${dep_package_name}.
# at the CMake package level.
# E.g. The Tools package that provides the qtwaylandscanner target
# needs to call find_package(WaylandScanner) (non-qt-package).
# main_target_name = qtwaylandscanner
# dep_package_name = WaylandScanner
function(qt_record_extra_package_dependency main_target_name dep_package_name dep_package_version)
if(NOT TARGET "${main_target_name}")
qt_get_tool_target_name(main_target_name "${main_target_name}")
endif()
if (TARGET "${main_target_name}")
get_target_property(extra_packages "${main_target_name}" QT_EXTRA_PACKAGE_DEPENDENCIES)
if(NOT extra_packages)
set(extra_packages "")
endif()
list(APPEND extra_packages "${dep_package_name}\;${dep_package_version}")
set_target_properties("${main_target_name}" PROPERTIES QT_EXTRA_PACKAGE_DEPENDENCIES
"${extra_packages}")
endif()
endfunction()
# This function records a dependency between ${main_target_name} and ${dep_target_name}
# at the CMake package level.
# E.g. Qt6CoreConfig.cmake needs to find_package(Qt6EntryPointPrivate).
# main_target_name = Core
# dep_target_name = EntryPointPrivate
# This is just a convenience function that deals with Qt targets and their associated packages
# instead of raw package names.
function(qt_record_extra_qt_package_dependency main_target_name dep_target_name
dep_package_version)
# EntryPointPrivate -> Qt6EntryPointPrivate.
qt_internal_qtfy_target(qtfied_target_name "${dep_target_name}")
qt_record_extra_package_dependency("${main_target_name}"
"${qtfied_target_name_versioned}" "${dep_package_version}")
endfunction()
# This function records a 'QtFooTools' package dependency for the ${main_target_name} target
# onto the ${dep_package_name} tools package.
# E.g. The QtWaylandCompositor package needs to call find_package(QtWaylandScannerTools).
# main_target_name = WaylandCompositor
# dep_package_name = Qt6WaylandScannerTools
function(qt_record_extra_main_tools_package_dependency
main_target_name dep_package_name dep_package_version)
if(NOT TARGET "${main_target_name}")
qt_get_tool_target_name(main_target_name "${main_target_name}")
endif()
if (TARGET "${main_target_name}")
get_target_property(extra_packages "${main_target_name}"
QT_EXTRA_TOOLS_PACKAGE_DEPENDENCIES)
if(NOT extra_packages)
set(extra_packages "")
endif()
list(APPEND extra_packages "${dep_package_name}\;${dep_package_version}")
set_target_properties("${main_target_name}" PROPERTIES QT_EXTRA_TOOLS_PACKAGE_DEPENDENCIES
"${extra_packages}")
endif()
endfunction()
# This function records a 'QtFooTools' package dependency for the ${main_target_name} target
# onto the ${dep_non_versioned_package_name} Tools package.
# main_target_name = WaylandCompositor
# dep_non_versioned_package_name = WaylandScannerTools
# This is just a convenience function to avoid hardcoding the qtified version in the dep package
# name.
function(qt_record_extra_qt_main_tools_package_dependency main_target_name
dep_non_versioned_package_name
dep_package_version)
# WaylandScannerTools -> Qt6WaylandScannerTools.
qt_internal_qtfy_target(qtfied_package_name "${dep_non_versioned_package_name}")
qt_record_extra_main_tools_package_dependency(
"${main_target_name}" "${qtfied_package_name_versioned}" "${dep_package_version}")
endfunction()
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
# Record an extra 3rd party target as a dependency for ${main_target_name}.
#
# Adds a find_package(${dep_target_package_name}) in ${main_target_name}Dependencies.cmake.
#
# Needed to record a dependency on the package that provides WrapVulkanHeaders::WrapVulkanHeaders.
# The package version, components, whether the package is optional, etc, are queried from the
# ${dep_target} target properties.
# Usually these are set at the qt_find_package() call site of a configure.cmake file e.g. using
# Qt's MARK_OPTIONAL option.
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
function(qt_record_extra_third_party_dependency main_target_name dep_target)
if(NOT TARGET "${main_target_name}")
qt_get_tool_target_name(main_target_name "${main_target_name}")
endif()
if(TARGET "${main_target_name}")
get_target_property(extra_deps "${main_target_name}" _qt_extra_third_party_dep_targets)
if(NOT extra_deps)
set(extra_deps "")
endif()
list(APPEND extra_deps "${dep_target}")
set_target_properties("${main_target_name}" PROPERTIES _qt_extra_third_party_dep_targets
"${extra_deps}")
endif()
endfunction()
# Sets out_var to TRUE if the non-namespaced ${lib} target is exported as part of Qt6Targets.cmake.
function(qt_internal_is_lib_part_of_qt6_package lib out_var)
if (lib STREQUAL "Platform"
OR lib STREQUAL "GlobalConfig"
OR lib STREQUAL "GlobalConfigPrivate"
OR lib STREQUAL "PlatformModuleInternal"
OR lib STREQUAL "PlatformPluginInternal"
OR lib STREQUAL "PlatformToolInternal"
OR lib STREQUAL "PlatformCommonInternal"
)
set(${out_var} "TRUE" PARENT_SCOPE)
else()
set(${out_var} "FALSE" PARENT_SCOPE)
endif()
endfunction()
CMake: Record used package version for each target dependency When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
# Try to get the CMake package version of a Qt target.
#
# Query the target's _qt_package_version property, or try to read it from the CMake package version
# variable set from calling find_package(Qt6${target}).
# Not all targets will have a find_package _VERSION variable, for example if the target is an
# executable.
# A heuristic is used to handle QtFooPrivate module targets.
# If no version can be found, fall back to ${PROJECT_VERSION} and issue a warning.
function(qt_internal_get_package_version_of_target target package_version_out_var)
qt_internal_is_lib_part_of_qt6_package("${target}" is_part_of_qt6)
if(is_part_of_qt6)
# When building qtbase, Qt6_VERSION is not set (unless examples are built in-tree,
# non-ExternalProject). Use the Platform target's version instead which would be the
# equivalent.
if(TARGET "${QT_CMAKE_EXPORT_NAMESPACE}::Platform")
get_target_property(package_version
"${QT_CMAKE_EXPORT_NAMESPACE}::Platform" _qt_package_version)
endif()
if(NOT package_version)
set(package_version "${${QT_CMAKE_EXPORT_NAMESPACE}_VERSION}")
endif()
else()
# Try to get the version from the target.
# Try the Private target first and if it doesn't exist, try the non-Private target later.
if(TARGET "${QT_CMAKE_EXPORT_NAMESPACE}::${target}")
get_target_property(package_version
"${QT_CMAKE_EXPORT_NAMESPACE}::${target}" _qt_package_version)
endif()
# Try to get the version from the corresponding package version variable.
if(NOT package_version)
set(package_version "${${QT_CMAKE_EXPORT_NAMESPACE}${target}_VERSION}")
endif()
# Try non-Private target.
if(NOT package_version AND target MATCHES "(.*)Private$")
set(target "${CMAKE_MATCH_1}")
endif()
if(NOT package_version AND TARGET "${QT_CMAKE_EXPORT_NAMESPACE}::${target}")
get_target_property(package_version
"${QT_CMAKE_EXPORT_NAMESPACE}::${target}" _qt_package_version)
endif()
if(NOT package_version)
set(package_version "${${QT_CMAKE_EXPORT_NAMESPACE}${target}_VERSION}")
endif()
endif()
if(NOT package_version)
set(package_version "${PROJECT_VERSION}")
if(FEATURE_developer_build)
message(WARNING
"Could not determine package version of target ${target}. "
"Defaulting to project version ${PROJECT_VERSION}.")
endif()
endif()
set(${package_version_out_var} "${package_version}" PARENT_SCOPE)
endfunction()
CMake: Record the precise package name where Private modules live Previously if a target depended on CorePrivate, we would write a _qt_internal_find_qt_dependencies(... Qt6CorePrivate) call into a FooDependencies.cmake file. That find_qt_deps call would remove the 'Private' suffix and would run find_dependency with NAMES set to both the altered and non-altered names. This would find the relevant package but it would set the wrong _FOUND variable name, e.g it would set Qt6CorePrivate_FOUND instead of Qt6Core_FOUND. This in turn could cause multiple lookups of the Qt6Core package during dependency handling because the correct _FOUND var would not be set. Instead of always looking for the Qt6CorePrivate package, make sure we look for an appropriately named package for all Privates modules, because we have the necessary info to determine the correct name. Note that INTERNAL modules will still be looked up via a Private suffixed package name because that's how the package name is chosen for them. Remove the code that accounted for Private modules in qt_internal_remove_qt_dependency_duplicates because it's not needed anymore. Warn when a package name can't be queried from a target's property because the target might not exist yet. Add a TODO comment for the code that searches with two NAMES. We can't remove it right now, because it might break user projects that use stale Dependencies.cmake files. The dbus subdirectory is added before the tools subdirectory to ensure that the new package name extraction does not error out, due to trying to access a target that does not yet exist. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Ib34ae5ed92f68b4265518c2b8802daeb1a3a04d6 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 16:12:18 +00:00
# Get the CMake package name that contains / exported the Qt module target.
function(qt_internal_get_package_name_of_target target package_name_out_var)
qt_internal_is_lib_part_of_qt6_package("${target}" is_part_of_qt6)
if(is_part_of_qt6)
set(package_name "${INSTALL_CMAKE_NAMESPACE}")
else()
# Get the package name from the module's target property.
# If not set, fallback to a name based on the target name.
#
# TODO: Remove fallback once sufficient time has passed, aka all developers updated
# their builds not to contain stale FooDependencies.cmakes files without the
# _qt_package_name property.
set(package_name "")
set(package_name_default "${INSTALL_CMAKE_NAMESPACE}${target}")
set(target_namespaced "${QT_CMAKE_EXPORT_NAMESPACE}::${target}")
if(TARGET "${target_namespaced}")
get_target_property(package_name_from_prop "${target_namespaced}" _qt_package_name)
if(package_name_from_prop)
set(package_name "${package_name_from_prop}")
endif()
endif()
if(NOT package_name)
message(WARNING
"Could not find target ${target_namespaced} to query its package name. "
"Defaulting to package name ${package_name_default}. Consider re-arranging the "
"project structure to ensure the target exists by this point."
)
set(package_name "${package_name_default}")
endif()
endif()
set(${package_name_out_var} "${package_name}" PARENT_SCOPE)
endfunction()
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 16:57:11 +00:00
# This function stores the list of Qt targets a library depend on,
# along with their version info, for usage in ${target}Depends.cmake file
function(qt_register_target_dependencies target public_libs private_libs)
get_target_property(target_deps "${target}" _qt_target_deps)
if(NOT target_deps)
set(target_deps "")
endif()
get_target_property(target_type ${target} TYPE)
set(lib_list ${public_libs})
set(target_is_shared FALSE)
set(target_is_static FALSE)
if(target_type STREQUAL "SHARED_LIBRARY")
set(target_is_shared TRUE)
elseif(target_type STREQUAL "STATIC_LIBRARY")
set(target_is_static TRUE)
endif()
# Record 'Qt::Foo'-like private dependencies of static library targets, this will be used to
# generate find_dependency() calls.
#
# Private static library dependencies will become $<LINK_ONLY:> dependencies in
# INTERFACE_LINK_LIBRARIES.
if(target_is_static)
list(APPEND lib_list ${private_libs})
endif()
foreach(lib IN LISTS lib_list)
if ("${lib}" MATCHES "^Qt::(.*)")
set(lib "${CMAKE_MATCH_1}")
CMake: Record the precise package name where Private modules live Previously if a target depended on CorePrivate, we would write a _qt_internal_find_qt_dependencies(... Qt6CorePrivate) call into a FooDependencies.cmake file. That find_qt_deps call would remove the 'Private' suffix and would run find_dependency with NAMES set to both the altered and non-altered names. This would find the relevant package but it would set the wrong _FOUND variable name, e.g it would set Qt6CorePrivate_FOUND instead of Qt6Core_FOUND. This in turn could cause multiple lookups of the Qt6Core package during dependency handling because the correct _FOUND var would not be set. Instead of always looking for the Qt6CorePrivate package, make sure we look for an appropriately named package for all Privates modules, because we have the necessary info to determine the correct name. Note that INTERNAL modules will still be looked up via a Private suffixed package name because that's how the package name is chosen for them. Remove the code that accounted for Private modules in qt_internal_remove_qt_dependency_duplicates because it's not needed anymore. Warn when a package name can't be queried from a target's property because the target might not exist yet. Add a TODO comment for the code that searches with two NAMES. We can't remove it right now, because it might break user projects that use stale Dependencies.cmake files. The dbus subdirectory is added before the tools subdirectory to ensure that the new package name extraction does not error out, due to trying to access a target that does not yet exist. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Ib34ae5ed92f68b4265518c2b8802daeb1a3a04d6 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 16:12:18 +00:00
qt_internal_get_package_name_of_target("${lib}" package_name)
CMake: Record used package version for each target dependency When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
qt_internal_get_package_version_of_target("${lib}" package_version)
CMake: Record the precise package name where Private modules live Previously if a target depended on CorePrivate, we would write a _qt_internal_find_qt_dependencies(... Qt6CorePrivate) call into a FooDependencies.cmake file. That find_qt_deps call would remove the 'Private' suffix and would run find_dependency with NAMES set to both the altered and non-altered names. This would find the relevant package but it would set the wrong _FOUND variable name, e.g it would set Qt6CorePrivate_FOUND instead of Qt6Core_FOUND. This in turn could cause multiple lookups of the Qt6Core package during dependency handling because the correct _FOUND var would not be set. Instead of always looking for the Qt6CorePrivate package, make sure we look for an appropriately named package for all Privates modules, because we have the necessary info to determine the correct name. Note that INTERNAL modules will still be looked up via a Private suffixed package name because that's how the package name is chosen for them. Remove the code that accounted for Private modules in qt_internal_remove_qt_dependency_duplicates because it's not needed anymore. Warn when a package name can't be queried from a target's property because the target might not exist yet. Add a TODO comment for the code that searches with two NAMES. We can't remove it right now, because it might break user projects that use stale Dependencies.cmake files. The dbus subdirectory is added before the tools subdirectory to ensure that the new package name extraction does not error out, due to trying to access a target that does not yet exist. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Ib34ae5ed92f68b4265518c2b8802daeb1a3a04d6 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 16:12:18 +00:00
list(APPEND target_deps "${package_name}\;${package_version}")
endif()
endforeach()
# Record 'Qt::Foo'-like shared private dependencies of shared library targets.
#
# Private shared library dependencies are listed in the target's
# IMPORTED_LINK_DEPENDENT_LIBRARIES and used in rpath-link calculation.
# See QTBUG-86533 for some details.
# We filter out static libraries and common platform targets, but include both SHARED and
# INTERFACE libraries. INTERFACE libraries in most cases will be FooPrivate libraries.
if(target_is_shared AND private_libs)
foreach(lib IN LISTS private_libs)
if ("${lib}" MATCHES "^Qt::(.*)")
set(lib_namespaced "${lib}")
set(lib "${CMAKE_MATCH_1}")
qt_internal_is_lib_part_of_qt6_package("${lib}" is_part_of_qt6)
get_target_property(lib_type "${lib_namespaced}" TYPE)
if(NOT lib_type STREQUAL "STATIC_LIBRARY" AND NOT is_part_of_qt6)
CMake: Record the precise package name where Private modules live Previously if a target depended on CorePrivate, we would write a _qt_internal_find_qt_dependencies(... Qt6CorePrivate) call into a FooDependencies.cmake file. That find_qt_deps call would remove the 'Private' suffix and would run find_dependency with NAMES set to both the altered and non-altered names. This would find the relevant package but it would set the wrong _FOUND variable name, e.g it would set Qt6CorePrivate_FOUND instead of Qt6Core_FOUND. This in turn could cause multiple lookups of the Qt6Core package during dependency handling because the correct _FOUND var would not be set. Instead of always looking for the Qt6CorePrivate package, make sure we look for an appropriately named package for all Privates modules, because we have the necessary info to determine the correct name. Note that INTERNAL modules will still be looked up via a Private suffixed package name because that's how the package name is chosen for them. Remove the code that accounted for Private modules in qt_internal_remove_qt_dependency_duplicates because it's not needed anymore. Warn when a package name can't be queried from a target's property because the target might not exist yet. Add a TODO comment for the code that searches with two NAMES. We can't remove it right now, because it might break user projects that use stale Dependencies.cmake files. The dbus subdirectory is added before the tools subdirectory to ensure that the new package name extraction does not error out, due to trying to access a target that does not yet exist. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Ib34ae5ed92f68b4265518c2b8802daeb1a3a04d6 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 16:12:18 +00:00
qt_internal_get_package_name_of_target("${lib}" package_name)
CMake: Record used package version for each target dependency When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
qt_internal_get_package_version_of_target("${lib}" package_version)
CMake: Record the precise package name where Private modules live Previously if a target depended on CorePrivate, we would write a _qt_internal_find_qt_dependencies(... Qt6CorePrivate) call into a FooDependencies.cmake file. That find_qt_deps call would remove the 'Private' suffix and would run find_dependency with NAMES set to both the altered and non-altered names. This would find the relevant package but it would set the wrong _FOUND variable name, e.g it would set Qt6CorePrivate_FOUND instead of Qt6Core_FOUND. This in turn could cause multiple lookups of the Qt6Core package during dependency handling because the correct _FOUND var would not be set. Instead of always looking for the Qt6CorePrivate package, make sure we look for an appropriately named package for all Privates modules, because we have the necessary info to determine the correct name. Note that INTERNAL modules will still be looked up via a Private suffixed package name because that's how the package name is chosen for them. Remove the code that accounted for Private modules in qt_internal_remove_qt_dependency_duplicates because it's not needed anymore. Warn when a package name can't be queried from a target's property because the target might not exist yet. Add a TODO comment for the code that searches with two NAMES. We can't remove it right now, because it might break user projects that use stale Dependencies.cmake files. The dbus subdirectory is added before the tools subdirectory to ensure that the new package name extraction does not error out, due to trying to access a target that does not yet exist. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Ib34ae5ed92f68b4265518c2b8802daeb1a3a04d6 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 16:12:18 +00:00
list(APPEND target_deps "${package_name}\;${package_version}")
endif()
endif()
endforeach()
endif()
set_target_properties("${target}" PROPERTIES _qt_target_deps "${target_deps}")
endfunction()
# Sets out_var to to TRUE if the target was marked to not be promoted to global scope.
function(qt_internal_should_not_promote_package_target_to_global target out_var)
get_property(should_not_promote TARGET "${target}" PROPERTY _qt_no_promote_global)
set("${out_var}" "${should_not_promote}" PARENT_SCOPE)
endfunction()