AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8152053a0b
qt5base-lts/cmake/QtFindPackageHelpers.cmake

454 lines
21 KiB
CMake
Raw Normal View History

CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# 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.
#
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
# Uses __qt_internal_walk_libs.
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
function(qt_find_package_promote_targets_to_global_scope target)
CMake: Make qt_internal_walk_libs available in public projects Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 10:47:52 +00:00
__qt_internal_walk_libs("${target}" _discarded_out_var _discarded_out_var_2
"qt_find_package_targets_dict" "promote_global")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endfunction()
macro(qt_find_package)
# Get the target names we expect to be provided by the package.
Revert "Revert "CMake: Add facility to mark package dependencies as optional"" This reverts commit b0c51f86f40b6b6d18fe2bb75cc851d36395240d. The build failure caused by 58c1c6ee5c986d502b56eb1cc57f1d9444d42031 has been fixed. Change-Id: Ic7458d54c7a874588e8b1bfeca61df1842763656 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-14 07:37:03 +00:00
set(find_package_options CONFIG NO_MODULE MODULE REQUIRED)
set(options ${find_package_options} MARK_OPTIONAL)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
set(oneValueArgs MODULE_NAME QMAKE_LIB)
CMake: Handle OPTIONAL_COMPONENTS in qt_find_package The optional components arguments were not handled before which caused the recorded package information for static builds to be incorrect, it only recorded the package name without the component. Remove REQUIRED_COMPONENTS TODO, there is no such find_package option, it's already handled by the regular COMPONENTS code path. Amends 07b6d3367debd8f15974abf0f5cdf48f0fe3a536 Pick-to: 6.1 6.2 Fixes: QTBUG-94501 Change-Id: Ib48a7befcb70e20c3f21315897d51d3064b48134 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Dominik Holland <dominik.holland@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-17 10:04:16 +00:00
set(multiValueArgs PROVIDED_TARGETS COMPONENTS OPTIONAL_COMPONENTS)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
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
CMake: Fix typos Found by codespell Pick-to: 6.4 Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-10 14:41:59 +00:00
# dependency. Return early, so that CMake doesn't fail with an error with trying to promote the
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# 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)
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()
CMake: Allow printing config summary even if module is not built In the future it might be useful to print the config summary entries of a Qt module configure.cmake file even if the associated module is not built and thus qt_feature_module_begin is not called. The repo src/CMakeLists.txt could then use a combination of qt_feature_evaluate_features and a conditional qt_feature_record_summary_entries to ensure the that summary entries are still shown. Change-Id: I124efc82163ddae48d9e72c70a677ec4c6588fac Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-27 10:32:06 +00:00
# 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()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# 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()
CMake: Handle OPTIONAL_COMPONENTS in qt_find_package The optional components arguments were not handled before which caused the recorded package information for static builds to be incorrect, it only recorded the package name without the component. Remove REQUIRED_COMPONENTS TODO, there is no such find_package option, it's already handled by the regular COMPONENTS code path. Amends 07b6d3367debd8f15974abf0f5cdf48f0fe3a536 Pick-to: 6.1 6.2 Fixes: QTBUG-94501 Change-Id: Ib48a7befcb70e20c3f21315897d51d3064b48134 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Dominik Holland <dominik.holland@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-17 10:04:16 +00:00
if(arg_OPTIONAL_COMPONENTS)
# Re-append optional components to forward them.
list(APPEND arg_UNPARSED_ARGUMENTS "OPTIONAL_COMPONENTS;${arg_OPTIONAL_COMPONENTS}")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# 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.
CMake: Fix qt_find_package to work when CMP00126 is set to NEW When CMP00126 is set to NEW, set(CACHE) doesn't remove regular variable bindings with the same name as the cache variable. This introduced an issue in qt_find_package, which called find_package(CONFIG QUIET) to try and find a package config file, but did not clean up the non-cache _FOUND variable which is automatically set to 0 by CMake if no Config file is found. Make sure to unset both the regular and cache _FOUND variables if either the package config file was not found, or if none of the provided targets found even if the Config file was found. Also move the _DIR cache variable cleaning into the same code block. Amends 4c31ce68d5367a6ec4dd3cf2f55e4b226add876d Amends 34b1c1c23cbddf67f878579bee9d10dcac29d8ca Fixes: QTBUG-95635 Pick-to: 6.2 Change-Id: I871987217526e0f0a20038a8da52625838e49488 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-06 16:39:04 +00:00
unset(_qt_any_target_found)
unset(_qt_should_unset_found_var)
if(${ARGV0}_FOUND AND arg_PROVIDED_TARGETS)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
foreach(expected_target ${arg_PROVIDED_TARGETS})
if (TARGET ${expected_target})
CMake: Fix qt_find_package to work when CMP00126 is set to NEW When CMP00126 is set to NEW, set(CACHE) doesn't remove regular variable bindings with the same name as the cache variable. This introduced an issue in qt_find_package, which called find_package(CONFIG QUIET) to try and find a package config file, but did not clean up the non-cache _FOUND variable which is automatically set to 0 by CMake if no Config file is found. Make sure to unset both the regular and cache _FOUND variables if either the package config file was not found, or if none of the provided targets found even if the Config file was found. Also move the _DIR cache variable cleaning into the same code block. Amends 4c31ce68d5367a6ec4dd3cf2f55e4b226add876d Amends 34b1c1c23cbddf67f878579bee9d10dcac29d8ca Fixes: QTBUG-95635 Pick-to: 6.2 Change-Id: I871987217526e0f0a20038a8da52625838e49488 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-06 16:39:04 +00:00
set(_qt_any_target_found TRUE)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
break()
endif()
endforeach()
CMake: Fix qt_find_package to work when CMP00126 is set to NEW When CMP00126 is set to NEW, set(CACHE) doesn't remove regular variable bindings with the same name as the cache variable. This introduced an issue in qt_find_package, which called find_package(CONFIG QUIET) to try and find a package config file, but did not clean up the non-cache _FOUND variable which is automatically set to 0 by CMake if no Config file is found. Make sure to unset both the regular and cache _FOUND variables if either the package config file was not found, or if none of the provided targets found even if the Config file was found. Also move the _DIR cache variable cleaning into the same code block. Amends 4c31ce68d5367a6ec4dd3cf2f55e4b226add876d Amends 34b1c1c23cbddf67f878579bee9d10dcac29d8ca Fixes: QTBUG-95635 Pick-to: 6.2 Change-Id: I871987217526e0f0a20038a8da52625838e49488 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-06 16:39:04 +00:00
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)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
endif()
endif()
# Ensure the options are back in the original unparsed arguments
Revert "Revert "CMake: Add facility to mark package dependencies as optional"" This reverts commit b0c51f86f40b6b6d18fe2bb75cc851d36395240d. The build failure caused by 58c1c6ee5c986d502b56eb1cc57f1d9444d42031 has been fixed. Change-Id: Ic7458d54c7a874588e8b1bfeca61df1842763656 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-14 07:37:03 +00:00
foreach(opt IN LISTS find_package_options)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
if(arg_${opt})
list(APPEND arg_UNPARSED_ARGUMENTS ${opt})
endif()
endforeach()
CMake: Refactor optimization flag handling and add optimize_full Introduce a bunch of helper functions to manipulate compiler flags and linker flags for the CMAKE_<LANG>_FLAGS_<CONFIG> and CMAKE_<LINK_TYPE>_LINKER_FLAGS_<CONFIG> CMake variables. These variables can be assigned and modified either in the cache or for a specific subdirectory scope, which will apply the flags only to targets in that scope. Add qt_internal_add_optimize_full_flags() function which mimics qmake's CONFIG += optimize_full behavior. Calling it will force usage of the '-O3' optimization flag on supported platforms (falling back '-O2' where not supported). Use the function for the Core and Gui subdirectories, to enable full optimization for the respective Qt modules as it is done in the qmake projects. To ensure that the global qmake-like compiler flags are assigned eveywhere, qt_internal_set_up_config_optimizations_like_in_qmake() needs to be called after Qt global features like optimize_size and optimize_full are available. This means that qtbase and its standalone tests need some special handling in regards to when to call that function. Task-number: QTBUG-86866 Change-Id: Ic7ac23de0265561cb06a0ba55089b6c0d3347441 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-02 13:38:47 +00:00
# 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).
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
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()
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()
Revert "Revert "CMake: Add facility to mark package dependencies as optional"" This reverts commit b0c51f86f40b6b6d18fe2bb75cc851d36395240d. The build failure caused by 58c1c6ee5c986d502b56eb1cc57f1d9444d42031 has been fixed. Change-Id: Ic7458d54c7a874588e8b1bfeca61df1842763656 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-14 07:37:03 +00:00
set_target_properties(${qt_find_package_target_name} PROPERTIES
INTERFACE_QT_PACKAGE_NAME ${ARGV0}
INTERFACE_QT_PACKAGE_IS_OPTIONAL ${arg_MARK_OPTIONAL})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
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()
CMake: Handle OPTIONAL_COMPONENTS in qt_find_package The optional components arguments were not handled before which caused the recorded package information for static builds to be incorrect, it only recorded the package name without the component. Remove REQUIRED_COMPONENTS TODO, there is no such find_package option, it's already handled by the regular COMPONENTS code path. Amends 07b6d3367debd8f15974abf0f5cdf48f0fe3a536 Pick-to: 6.1 6.2 Fixes: QTBUG-94501 Change-Id: Ib48a7befcb70e20c3f21315897d51d3064b48134 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Dominik Holland <dominik.holland@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-17 10:04:16 +00:00
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()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
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})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
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 "")
CMake: Rename internal variable Rename QT_QMAKE_LIB_TARGETS_foo to QT_TARGETS_OF_QMAKE_LIB_foo, because we want to introduce the counterpart QT_QMAKE_LIB_OF_TARGET_bar in a subsequent commit. Pick-to: 6.0 Task-number: QTBUG-88951 Change-Id: I33f00f4fe65c5977da6e74c632ebeab3b891c89a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-26 16:47:16 +00:00
set(QT_TARGETS_OF_QMAKE_LIB_${arg_QMAKE_LIB} ${arg_PROVIDED_TARGETS} CACHE INTERNAL "")
CMake: Fill QT.<module-name>.uses entries in module .pri files Those entries were always empty. The INTERFACE_QT_MODULE_USES property was never set. Map each public dependency to its qmake lib name and place this value into the module's QT.<module-name>.uses variable. Take into account the "_nolink" target modifier and translate it to qmake's "/nolink". Pick-to: 6.0 Fixes: QTBUG-88951 Change-Id: Ib6ef65b842a1fe1da3ade55867583343b4ee76ee Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-26 16:52:12 +00:00
foreach(provided_target ${arg_PROVIDED_TARGETS})
set(QT_QMAKE_LIB_OF_TARGET_${provided_target} ${arg_QMAKE_LIB} CACHE INTERNAL "")
endforeach()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
endif()
endmacro()
CMake: Fill QT.<module-name>.uses entries in module .pri files Those entries were always empty. The INTERFACE_QT_MODULE_USES property was never set. Map each public dependency to its qmake lib name and place this value into the module's QT.<module-name>.uses variable. Take into account the "_nolink" target modifier and translate it to qmake's "/nolink". Pick-to: 6.0 Fixes: QTBUG-88951 Change-Id: Ib6ef65b842a1fe1da3ade55867583343b4ee76ee Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-26 16:52:12 +00:00
# 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()
CMake: Provide way to register extra tool package dependencies This is needed for qtwayland, where QtWaylandCompositor package should call find_package(QtWaylandScanner) in the 'Tools' section of the ModuleDependencies.cmake file, rather than the regular 'Qt' section. This takes care of handling host path prefixes, to ensure that a host package is found even when tools have also been cross-compiled via the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING option. Task-number: QTBUG-83968 Change-Id: I4725a630214d053105fb6d2a0f7c5ff6128d13f9 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-09-10 16:43:09 +00:00
# This function records a dependency between ${main_target_name} and ${dep_package_name}.
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# 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)
CMake: Register qtwaylandscanner dependency when cross-compiling qt_record_extra_package_dependency is called by qtwayland to register a dependency between the qtwaylandscanner tool and the waylandscanner tool. When cross-compiling the tools in a Yocto environment, the adjusted target name was not taken into account. Task-number: QTBUG-83968 Change-Id: Ibf7b94876bf29827cf0d9c9bb471f359ef6ff15f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-09 16:47:03 +00:00
if(NOT TARGET "${main_target_name}")
qt_get_tool_target_name(main_target_name "${main_target_name}")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
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.
Adjust the EntryPoint target name according to the internal module naming policy Pick-to: 6.2 Task-number: QTBUG-87775 Change-Id: I1d6097c950f97e102c44e2952edc98caa4deb6c6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-11 11:36:10 +00:00
# E.g. Qt6CoreConfig.cmake needs to find_package(Qt6EntryPointPrivate).
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# main_target_name = Core
Adjust the EntryPoint target name according to the internal module naming policy Pick-to: 6.2 Task-number: QTBUG-87775 Change-Id: I1d6097c950f97e102c44e2952edc98caa4deb6c6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-11 11:36:10 +00:00
# dep_target_name = EntryPointPrivate
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# 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)
Adjust the EntryPoint target name according to the internal module naming policy Pick-to: 6.2 Task-number: QTBUG-87775 Change-Id: I1d6097c950f97e102c44e2952edc98caa4deb6c6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-11 11:36:10 +00:00
# EntryPointPrivate -> Qt6EntryPointPrivate.
Do not use qt_internal_module_info for non-module targets The qt_internal_module_info function suppose to provide the information only about the Qt modules. Avoid using it for the tool and extra package dependencies, since some targets do not always exist, when function is called. Add the qt_internal_qtfy_target function to make the prefixed target names. Change-Id: Ifa8c61064d9c6c430889f00a4ead304029da711b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-28 15:24:30 +00:00
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}")
CMake: Provide way to register extra tool package dependencies This is needed for qtwayland, where QtWaylandCompositor package should call find_package(QtWaylandScanner) in the 'Tools' section of the ModuleDependencies.cmake file, rather than the regular 'Qt' section. This takes care of handling host path prefixes, to ensure that a host package is found even when tools have also been cross-compiled via the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING option. Task-number: QTBUG-83968 Change-Id: I4725a630214d053105fb6d2a0f7c5ff6128d13f9 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-09-10 16:43:09 +00:00
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.
Do not use qt_internal_module_info for non-module targets The qt_internal_module_info function suppose to provide the information only about the Qt modules. Avoid using it for the tool and extra package dependencies, since some targets do not always exist, when function is called. Add the qt_internal_qtfy_target function to make the prefixed target names. Change-Id: Ifa8c61064d9c6c430889f00a4ead304029da711b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-28 15:24:30 +00:00
qt_internal_qtfy_target(qtfied_package_name "${dep_non_versioned_package_name}")
CMake: Provide way to register extra tool package dependencies This is needed for qtwayland, where QtWaylandCompositor package should call find_package(QtWaylandScanner) in the 'Tools' section of the ModuleDependencies.cmake file, rather than the regular 'Qt' section. This takes care of handling host path prefixes, to ensure that a host package is found even when tools have also been cross-compiled via the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING option. Task-number: QTBUG-83968 Change-Id: I4725a630214d053105fb6d2a0f7c5ff6128d13f9 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-09-10 16:43:09 +00:00
qt_record_extra_main_tools_package_dependency(
"${main_target_name}" "${qtfied_package_name_versioned}" "${dep_package_version}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
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.
CMake: Clarify qt_record_extra_third_party_dependency docs Pick-to: 6.4 Change-Id: I458a5b488741c639650c8b3b6668c82c80b5e93f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-08 15:11:59 +00:00
# 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()
CMake: Fix -rpath-link dependencies take two The previous implementation would pick up static Qt deps of a shared Qt library as packages to find, but packages are not created for these static libraries in a shared Qt build. For example Qt::BundledSpirv_Cross is a static helper lib that is linked directly into ShaderTools shared lib and no CMake package is created for it, so we shouldn't look for it. Separate the code path to filter out private dependencies of a shared library target that don't have packages. Amends 87215c70c0ff0bdc52dfa463f050d2aa049cdd91 Pick-to: 6.2 Fixes: QTBUG-97673 Task-number: QTBUG-86533 Change-Id: I43490b4d20c150256ccfa8b511a6e0e6b0f4b313 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-21 12:01:29 +00:00
# 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")
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()
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,
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# 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})
CMake: Fix -rpath-link dependencies take two The previous implementation would pick up static Qt deps of a shared Qt library as packages to find, but packages are not created for these static libraries in a shared Qt build. For example Qt::BundledSpirv_Cross is a static helper lib that is linked directly into ShaderTools shared lib and no CMake package is created for it, so we shouldn't look for it. Separate the code path to filter out private dependencies of a shared library target that don't have packages. Amends 87215c70c0ff0bdc52dfa463f050d2aa049cdd91 Pick-to: 6.2 Fixes: QTBUG-97673 Task-number: QTBUG-86533 Change-Id: I43490b4d20c150256ccfa8b511a6e0e6b0f4b313 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-21 12:01:29 +00:00
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)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
list(APPEND lib_list ${private_libs})
endif()
foreach(lib IN LISTS lib_list)
if ("${lib}" MATCHES "^Qt::(.*)")
set(lib "${CMAKE_MATCH_1}")
CMake: Fix -rpath-link dependencies take two The previous implementation would pick up static Qt deps of a shared Qt library as packages to find, but packages are not created for these static libraries in a shared Qt build. For example Qt::BundledSpirv_Cross is a static helper lib that is linked directly into ShaderTools shared lib and no CMake package is created for it, so we shouldn't look for it. Separate the code path to filter out private dependencies of a shared library target that don't have packages. Amends 87215c70c0ff0bdc52dfa463f050d2aa049cdd91 Pick-to: 6.2 Fixes: QTBUG-97673 Task-number: QTBUG-86533 Change-Id: I43490b4d20c150256ccfa8b511a6e0e6b0f4b313 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-21 12:01:29 +00:00
qt_internal_is_lib_part_of_qt6_package("${lib}" is_part_of_qt6)
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: Fix -rpath-link dependencies take two The previous implementation would pick up static Qt deps of a shared Qt library as packages to find, but packages are not created for these static libraries in a shared Qt build. For example Qt::BundledSpirv_Cross is a static helper lib that is linked directly into ShaderTools shared lib and no CMake package is created for it, so we shouldn't look for it. Separate the code path to filter out private dependencies of a shared library target that don't have packages. Amends 87215c70c0ff0bdc52dfa463f050d2aa049cdd91 Pick-to: 6.2 Fixes: QTBUG-97673 Task-number: QTBUG-86533 Change-Id: I43490b4d20c150256ccfa8b511a6e0e6b0f4b313 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-21 12:01:29 +00:00
if (is_part_of_qt6)
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
list(APPEND target_deps "Qt6\;${package_version}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
else()
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
list(APPEND target_deps "${INSTALL_CMAKE_NAMESPACE}${lib}\;${package_version}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
endif()
endforeach()
CMake: Fix -rpath-link dependencies take two The previous implementation would pick up static Qt deps of a shared Qt library as packages to find, but packages are not created for these static libraries in a shared Qt build. For example Qt::BundledSpirv_Cross is a static helper lib that is linked directly into ShaderTools shared lib and no CMake package is created for it, so we shouldn't look for it. Separate the code path to filter out private dependencies of a shared library target that don't have packages. Amends 87215c70c0ff0bdc52dfa463f050d2aa049cdd91 Pick-to: 6.2 Fixes: QTBUG-97673 Task-number: QTBUG-86533 Change-Id: I43490b4d20c150256ccfa8b511a6e0e6b0f4b313 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-21 12:01:29 +00:00
# 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 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)
list(APPEND target_deps "${INSTALL_CMAKE_NAMESPACE}${lib}\;${package_version}")
CMake: Fix -rpath-link dependencies take two The previous implementation would pick up static Qt deps of a shared Qt library as packages to find, but packages are not created for these static libraries in a shared Qt build. For example Qt::BundledSpirv_Cross is a static helper lib that is linked directly into ShaderTools shared lib and no CMake package is created for it, so we shouldn't look for it. Separate the code path to filter out private dependencies of a shared library target that don't have packages. Amends 87215c70c0ff0bdc52dfa463f050d2aa049cdd91 Pick-to: 6.2 Fixes: QTBUG-97673 Task-number: QTBUG-86533 Change-Id: I43490b4d20c150256ccfa8b511a6e0e6b0f4b313 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-21 12:01:29 +00:00
endif()
endif()
endforeach()
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
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()
Reference in New Issue Copy Permalink