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

898 lines
37 KiB
CMake
Raw Normal View History

Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 11:26:52 +00:00
# Copyright (C) 2022 The Qt Company Ltd.
Change the license of all CMakeLists.txt and *.cmake files to BSD Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-19 13:21:34 +00:00
# SPDX-License-Identifier: BSD-3-Clause
Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 11:26:52 +00:00
Replace the syncqt.pl script with syncqt tool syncqt.pl adds an extra dependency on perl when building Qt. Modern C++ provides the convenient cross-platform way to access a filesystem and to use regular expressions, so we may replace the perl script with C++ application. The syncqt executable is built at configure time and installed as QtCore tool. It's running at configure time to deliver the required header files for IDE to build a consistent code model and at the build time to keep tracking changes in header files and generate the missing aliases without reconfiguring. 'syncqt' only parses header files from a CMake build tree, so the resulting Qt installation only contains interfacing headers that belong to the platform that Qt is built for. 'sync.profile' files are not used as the 'source of truth' for sync qt procedure anymore, all the necessary information is taken from either CMake files at configure time or from the module header files while parsing them. syncqt.pl is still in place since it's required as fallback solution for a smooth transition to the new syncqt implementation for all qt repositories. This patchset only enables the C++ based syncqt for 'qtbase' repository. From the performance perspective C++ version works faster then perl script, also the configure time is reduced significally on subsequent reconfigurations - up x2 times faster when re-configuring repository, but it also takes time to compile the tool itself the first time. Numbers for qtbase: syncqt.pl syncqt.cpp initial: 0m16,035s 0m20,413s reconfig: 0m6,819s 0m3,725s The syncing procedure can be run separately for each module using <ModuleName>_sync_headers targets. The 'sync_headers' target can be used to sync all the modules at once. Task-number: QTBUG-87480 Task-number: QTBUG-103196 Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-15 16:29:41 +00:00
function(qt_internal_write_depends_file target)
get_target_property(module_depends_header ${target} _qt_module_depends_header)
set(outfile "${module_depends_header}")
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 11:16:10 +00:00
set(contents "/* This file was generated by cmake with the info from ${target} target. */\n")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
string(APPEND contents "#ifdef __cplusplus /* create empty PCH in C mode */\n")
foreach (m ${ARGN})
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
string(APPEND contents "# include <${m}/${m}>\n")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endforeach()
string(APPEND contents "#endif\n")
file(GENERATE OUTPUT "${outfile}" CONTENT "${contents}")
endfunction()
macro(qt_collect_third_party_deps target)
set(_target_is_static OFF)
get_target_property(_target_type ${target} TYPE)
if (${_target_type} STREQUAL "STATIC_LIBRARY")
set(_target_is_static ON)
endif()
unset(_target_type)
# If we are doing a non-static Qt build, we only want to propagate public dependencies.
# If we are doing a static Qt build, we need to propagate all dependencies.
set(depends_var "public_depends")
if(_target_is_static)
set(depends_var "depends")
endif()
unset(_target_is_static)
CMake: Don't export 3rdparty dependency find_package calls ...of private modules in public modules. This isn't necessary anymore since the Qt6FooPrivateDependencies.cmake files contain these 3rdparty dependencies proper. This reverts commit dae078e521c3932c66436cbdbfaf5294a1842901. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I2c425d49fe7beb790abf9a94f089d43fde8b047e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 16:22:45 +00:00
foreach(dep ${${depends_var}} ${extra_third_party_deps})
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# Gather third party packages that should be found when using the Qt module.
# Also handle nolink target dependencies.
string(REGEX REPLACE "_nolink$" "" base_dep "${dep}")
if(NOT base_dep STREQUAL dep)
# Resets target name like Vulkan_nolink to Vulkan, because we need to call
# find_package(Vulkan).
set(dep ${base_dep})
endif()
# Strip any directory scope tokens.
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_strip_target_directory_scope_token("${dep}" dep)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
if(TARGET ${dep})
list(FIND third_party_deps_seen ${dep} dep_seen)
get_target_property(package_name ${dep} INTERFACE_QT_PACKAGE_NAME)
if(dep_seen EQUAL -1 AND package_name)
list(APPEND third_party_deps_seen ${dep})
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
get_target_property(package_is_optional ${dep} INTERFACE_QT_PACKAGE_IS_OPTIONAL)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
get_target_property(package_version ${dep} INTERFACE_QT_PACKAGE_VERSION)
if(NOT package_version)
set(package_version "")
endif()
get_target_property(package_components ${dep} INTERFACE_QT_PACKAGE_COMPONENTS)
if(NOT package_components)
set(package_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
get_target_property(package_optional_components ${dep}
INTERFACE_QT_PACKAGE_OPTIONAL_COMPONENTS)
if(NOT package_optional_components)
set(package_optional_components "")
endif()
CMake: Record package provided targets in Dependencies.cmake files Each qt_find_package can specify a PROVIDED_TARGETS option, to inform which targets will be created by that package. The call then saves the package name, version, etc on each of the provided targets. Currently the provided targets info is not persisted anywhere after configuration ends. We will need this for SBOM creation, so that we can collect information about such dependencies when configuring leaf repos, where find_dependency calls are implicit, and don't contain the PROVIDED_TARGETS option, and we need to go from package name to target name (and any recorded info it the target has). This is especially relevant for static library builds, where private dependencies become public dependencies. Collect the provided targets information at post process time and persist it for each 'package name + components requested' combination into the Dependencies.cmake file. This information will be used in a later change for SBOM generation. Change-Id: I1693f81b1ad3beaf9b02e44b09a5e977923f0d85 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
get_target_property(package_components_id ${dep} _qt_package_components_id)
if(package_components_id)
list(APPEND third_party_deps_package_components_ids ${package_components_id})
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
list(APPEND third_party_deps
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
"${package_name}\;${package_is_optional}\;${package_version}\;${package_components}\;${package_optional_components}")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
endif()
endforeach()
endmacro()
CMake: Record package provided targets in Dependencies.cmake files Each qt_find_package can specify a PROVIDED_TARGETS option, to inform which targets will be created by that package. The call then saves the package name, version, etc on each of the provided targets. Currently the provided targets info is not persisted anywhere after configuration ends. We will need this for SBOM creation, so that we can collect information about such dependencies when configuring leaf repos, where find_dependency calls are implicit, and don't contain the PROVIDED_TARGETS option, and we need to go from package name to target name (and any recorded info it the target has). This is especially relevant for static library builds, where private dependencies become public dependencies. Collect the provided targets information at post process time and persist it for each 'package name + components requested' combination into the Dependencies.cmake file. This information will be used in a later change for SBOM generation. Change-Id: I1693f81b1ad3beaf9b02e44b09a5e977923f0d85 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
# Collect provided targets for the given list of package component ids.
#
# ${target} is merely used as a key infix to avoid name clashes in the Dependencies.cmake files.
# package_component_ids is a list of '${package_name}-${components}-${optional_components}' keys
# that are sanitized not to contain spaces or semicolons.
#
# The output is a list of variable assignments to add to the dependencies file.
# Each variable assignment is the list of provided targets for a given package component id.
#
# We use these extra assignments instead of adding the info to the existing 'third_party_deps' list
# to make the information more readable. That list already has 5 items per package, making it
# quite hard to read.
function(qt_internal_collect_third_party_dep_packages_info
target
package_components_ids
out_packages_info)
# There might be multiple calls to find the same package, so remove the duplicates.
list(REMOVE_DUPLICATES package_components_ids)
set(packages_info "")
foreach(package_key IN LISTS package_components_ids)
get_cmake_property(provided_targets _qt_find_package_${package_key}_provided_targets)
if(provided_targets)
set(key "__qt_${target}_third_party_package_${package_key}_provided_targets")
string(APPEND packages_info "set(${key} \"${provided_targets}\")\n")
endif()
endforeach()
set(${out_packages_info} "${packages_info}" 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
# Filter the dependency targets to collect unique set of the dependencies.
# non-Private and Private targets are treated as the single object in this context
# since they are defined by the same CMake package. For internal modules
# the CMake package will be always Private.
function(qt_internal_remove_qt_dependency_duplicates out_deps deps)
set(${out_deps} "")
foreach(dep ${deps})
if(dep)
list(FIND ${out_deps} "${dep}" dep_seen)
if(dep_seen EQUAL -1)
list(LENGTH dep len)
if(NOT (len EQUAL 2))
message(FATAL_ERROR "List '${dep}' should look like QtFoo;version")
endif()
list(GET dep 0 dep_name)
list(GET dep 1 dep_ver)
# Skip over Qt6 dependency, because we will manually handle it in the Dependencies
# file before everything else, to ensure that find_package(Qt6Core)-style works.
if(dep_name STREQUAL "${INSTALL_CMAKE_NAMESPACE}")
continue()
endif()
list(APPEND ${out_deps} "${dep_name}\;${dep_ver}")
endif()
endif()
endforeach()
set(${out_deps} "${${out_deps}}" PARENT_SCOPE)
endfunction()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
function(qt_internal_create_module_depends_file target)
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 20:14:50 +00:00
set(no_value_options "")
set(single_value_options "")
CMake: Simplify Qt6FooPrivate -> Qt6Foo package dependency setup This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Remove the EXTRA_PACKAGE_DEPENDENCIES argument that was added in mentioned commit, and use the qt_register_target_dependencies function instead to add the package dependency Qt6FooPrivate -> Qt6Foo. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I08a48954576dc3c0b6fde809f90d2022201d7eb0 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-06 10:15:12 +00:00
set(multi_value_options "")
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 20:14:50 +00:00
cmake_parse_arguments(PARSE_ARGV 1 arg
"${no_value_options}" "${single_value_options}" "${multi_value_options}"
)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
get_target_property(target_type "${target}" TYPE)
Rename arg_HEADER_MODULE variable to 'is_interface_lib' Variables starting with 'arg_' usually are the result of the cmake_parse_arguments call. It's better to not use them for the regular variables for readability. Change-Id: I4054c63d3e48b2a27d8a632cd8908a59302afa47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-10 14:25:19 +00:00
set(is_interface_lib FALSE)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
if(target_type STREQUAL "INTERFACE_LIBRARY")
Rename arg_HEADER_MODULE variable to 'is_interface_lib' Variables starting with 'arg_' usually are the result of the cmake_parse_arguments call. It's better to not use them for the regular variables for readability. Change-Id: I4054c63d3e48b2a27d8a632cd8908a59302afa47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-10 14:25:19 +00:00
set(is_interface_lib TRUE)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
set(depends "")
Rename arg_HEADER_MODULE variable to 'is_interface_lib' Variables starting with 'arg_' usually are the result of the cmake_parse_arguments call. It's better to not use them for the regular variables for readability. Change-Id: I4054c63d3e48b2a27d8a632cd8908a59302afa47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-10 14:25:19 +00:00
if(target_type STREQUAL "STATIC_LIBRARY")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
get_target_property(depends "${target}" LINK_LIBRARIES)
endif()
get_target_property(public_depends "${target}" INTERFACE_LINK_LIBRARIES)
# Used for collecting Qt module dependencies that should be find_package()'d in
# ModuleDependencies.cmake.
get_target_property(target_deps "${target}" _qt_target_deps)
set(target_deps_seen "")
set(qt_module_dependencies "")
Rename arg_HEADER_MODULE variable to 'is_interface_lib' Variables starting with 'arg_' usually are the result of the cmake_parse_arguments call. It's better to not use them for the regular variables for readability. Change-Id: I4054c63d3e48b2a27d8a632cd8908a59302afa47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-10 14:25:19 +00:00
if(NOT is_interface_lib)
Replace qt_record_extra_qt_package_dependency with qt_register_target_dependencies qt_register_target_dependencies does the same thing as qt_record_extra_qt_package_dependency but in more convenient way. Update the qt_register_target_dependencies signature and adjust naming, it now accepts PUBLIC and PRIVATE multi-value arguments and called qt_internal_register_target_dependencies. Use it and deprecate qt_record_extra_qt_package_dependency. Pick-to: 6.5 6.8 6.9 Change-Id: I0594cf699ec1e3af7210dd7450fa3f81c1f565ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-07 16:51:30 +00:00
# TODO: deprecated code path. QT_EXTRA_PACKAGE_DEPENDENCIES shouldn't be used for the Qt
# packages.
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
get_target_property(extra_depends "${target}" QT_EXTRA_PACKAGE_DEPENDENCIES)
endif()
Replace qt_record_extra_qt_package_dependency with qt_register_target_dependencies qt_register_target_dependencies does the same thing as qt_record_extra_qt_package_dependency but in more convenient way. Update the qt_register_target_dependencies signature and adjust naming, it now accepts PUBLIC and PRIVATE multi-value arguments and called qt_internal_register_target_dependencies. Use it and deprecate qt_record_extra_qt_package_dependency. Pick-to: 6.5 6.8 6.9 Change-Id: I0594cf699ec1e3af7210dd7450fa3f81c1f565ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-07 16:51:30 +00:00
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
if(NOT extra_depends MATCHES "-NOTFOUND$")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
list(APPEND target_deps "${extra_depends}")
endif()
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
# Extra 3rd party targets who's packages should be considered dependencies.
get_target_property(extra_third_party_deps "${target}" _qt_extra_third_party_dep_targets)
if(NOT extra_third_party_deps)
set(extra_third_party_deps "")
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# Used for assembling the content of an include/Module/ModuleDepends.h header.
set(qtdeps "")
# Used for collecting third party dependencies that should be find_package()'d in
# ModuleDependencies.cmake.
set(third_party_deps "")
set(third_party_deps_seen "")
CMake: Record package provided targets in Dependencies.cmake files Each qt_find_package can specify a PROVIDED_TARGETS option, to inform which targets will be created by that package. The call then saves the package name, version, etc on each of the provided targets. Currently the provided targets info is not persisted anywhere after configuration ends. We will need this for SBOM creation, so that we can collect information about such dependencies when configuring leaf repos, where find_dependency calls are implicit, and don't contain the PROVIDED_TARGETS option, and we need to go from package name to target name (and any recorded info it the target has). This is especially relevant for static library builds, where private dependencies become public dependencies. Collect the provided targets information at post process time and persist it for each 'package name + components requested' combination into the Dependencies.cmake file. This information will be used in a later change for SBOM generation. Change-Id: I1693f81b1ad3beaf9b02e44b09a5e977923f0d85 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
set(third_party_deps_package_components_ids "")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# Used for collecting Qt tool dependencies that should be find_package()'d in
# ModuleToolsDependencies.cmake.
set(tool_deps "")
set(tool_deps_seen "")
# Used for collecting Qt tool dependencies that should be find_package()'d in
# ModuleDependencies.cmake.
set(main_module_tool_deps "")
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
# Extra QtFooModuleTools packages to be added as dependencies to
# QtModuleDependencies.cmake. Needed for QtWaylandCompositor / QtWaylandClient.
Rename arg_HEADER_MODULE variable to 'is_interface_lib' Variables starting with 'arg_' usually are the result of the cmake_parse_arguments call. It's better to not use them for the regular variables for readability. Change-Id: I4054c63d3e48b2a27d8a632cd8908a59302afa47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-10 14:25:19 +00:00
if(NOT is_interface_lib)
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
get_target_property(extra_tools_package_dependencies "${target}"
QT_EXTRA_TOOLS_PACKAGE_DEPENDENCIES)
if(extra_tools_package_dependencies)
list(APPEND main_module_tool_deps "${extra_tools_package_dependencies}")
endif()
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
qt_internal_get_qt_all_known_modules(known_modules)
set(all_depends ${depends} ${public_depends})
foreach (dep ${all_depends})
# Normalize module by stripping leading "Qt::" and trailing "Private"
CMake: Fix Core -> Core dependency in static build Fix the overly strict regex in qt_internal_create_module_depends_file to allow for - and _ in module names. We had the above mentioned dependency cycle, because the module name Core_qobject was translated to just Core, creating a Core -> Core dependency. Amends da7609e7d0592b76ccb7cfb6c3136267172dc6bf. Fixes: QTBUG-88437 Change-Id: I866f7ce31e9a1b92fe4c0a6450295c2f3c761558 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2020-11-12 10:39:02 +00:00
if (dep MATCHES "(Qt|${QT_CMAKE_EXPORT_NAMESPACE})::([-_A-Za-z0-9]+)")
cmake: Handle exported namespace when computing deps We need to handle the possibility of versioned dep (Qt6::Foo). Change-Id: I66797dbc59f00500892958e9c99c4555cddcb980 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-10 14:15:09 +00:00
set(dep "${CMAKE_MATCH_2}")
CMake: Fix exclusion of QtFoo in QtBarDepends for 3rd party libs When configuring a static Qt with the -qt-zlib option and the build system creates a 3rd party header module QtZlib, syncqt does not generate a QtZlib header file that would include all its public headers. Then when the QtSvgDepends header is generated, it would add an #include <QtZlib> which would break compilation of the QtSvg PCH file (which compiles QtSvgDepends). We have logic to exclude addition of headers from regular 3rd party static libraries, but not header only 3rd party libraries. Adjust the code to handle header-only 3rd party libraries, as well as make sure it works across repos by exporting the relevant properties. As a drive-by, also rename and export some other informational properties. Amends af00402d6446c0f8f085a2a482fc83c4318aa457 Amends 6fdeaea24f9035ad53ba2548a9467b3264cf01ad Amends be2745e4788cecb0d3122081e3328e4b66923609 Pick-to: 6.2 6.3 Change-Id: I087f50b193dd845e4a5ec906e8851d63122faf80 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-02-22 15:57:00 +00:00
set(real_dep_target "Qt::${dep}")
if(TARGET "${real_dep_target}")
get_target_property(is_versionless_target "${real_dep_target}"
_qt_is_versionless_target)
if(is_versionless_target)
set(real_dep_target "${QT_CMAKE_EXPORT_NAMESPACE}::${dep}")
endif()
get_target_property(skip_module_depends_include "${real_dep_target}"
_qt_module_skip_depends_include)
if(skip_module_depends_include)
continue()
endif()
get_target_property(module_has_headers "${real_dep_target}"
_qt_module_has_headers)
if(NOT module_has_headers)
continue()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
endif()
endif()
list(FIND known_modules "${dep}" _pos)
if (_pos GREATER -1)
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
qt_internal_module_info(module ${QT_CMAKE_EXPORT_NAMESPACE}::${dep})
list(APPEND qtdeps ${module})
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# Make the ModuleTool package depend on dep's ModuleTool package.
list(FIND tool_deps_seen ${dep} dep_seen)
if(dep_seen EQUAL -1 AND ${dep} IN_LIST QT_KNOWN_MODULES_WITH_TOOLS)
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("${dep}" dep_package_version)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
list(APPEND tool_deps_seen ${dep})
list(APPEND tool_deps
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
"${INSTALL_CMAKE_NAMESPACE}${dep}Tools\;${dep_package_version}")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
endif()
endforeach()
qt_collect_third_party_deps(${target})
CMake: Record package provided targets in Dependencies.cmake files Each qt_find_package can specify a PROVIDED_TARGETS option, to inform which targets will be created by that package. The call then saves the package name, version, etc on each of the provided targets. Currently the provided targets info is not persisted anywhere after configuration ends. We will need this for SBOM creation, so that we can collect information about such dependencies when configuring leaf repos, where find_dependency calls are implicit, and don't contain the PROVIDED_TARGETS option, and we need to go from package name to target name (and any recorded info it the target has). This is especially relevant for static library builds, where private dependencies become public dependencies. Collect the provided targets information at post process time and persist it for each 'package name + components requested' combination into the Dependencies.cmake file. This information will be used in a later change for SBOM generation. Change-Id: I1693f81b1ad3beaf9b02e44b09a5e977923f0d85 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
qt_internal_collect_third_party_dep_packages_info(${target}
"${third_party_deps_package_components_ids}"
packages_info)
set(third_party_deps_extra_info "")
if(packages_info)
string(APPEND third_party_deps_extra_info "${packages_info}")
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# Add dependency to the main ModuleTool package to ModuleDependencies file.
if(${target} IN_LIST QT_KNOWN_MODULES_WITH_TOOLS)
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("${target}" main_module_tool_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
list(APPEND main_module_tool_deps
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
"${INSTALL_CMAKE_NAMESPACE}${target}Tools\;${main_module_tool_package_version}")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
foreach(dep ${target_deps})
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
if(NOT dep MATCHES ".+Private$" AND
dep MATCHES "${INSTALL_CMAKE_NAMESPACE}(.+)")
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
# target_deps contains elements that are a pair of target name and version,
Remove unnecessary version of module from _MODULE_DEPENDENCIES _<module>_MODULE_DEPENDENCIES variable in the <module>Dependnecies.cmake should only contain the list of targets that module depends on, but not versions. Version of the first module appears in the list because of the regression introduced in 425ff34aa10a02524f2d52f544dc00b539ef9a26 Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Pick-to: 6.2 Change-Id: Iaa42120af6bac742bdf0f8d389bd8e5bdef9c1d1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-18 17:26:08 +00:00
# e.g. 'Core\;6.2'
# After the extracting from the target_deps list, the element becomes a list itself,
# because it loses escape symbol before the semicolon, so ${CMAKE_MATCH_1} is the list:
# Core;6.2.
# We need to store only the target name in the qt_module_dependencies variable.
list(GET CMAKE_MATCH_1 0 dep_name)
if(dep_name)
list(APPEND qt_module_dependencies "${dep_name}")
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
endforeach()
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
list(REMOVE_DUPLICATES qt_module_dependencies)
qt_internal_remove_qt_dependency_duplicates(target_deps "${target_deps}")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
if (DEFINED qtdeps)
list(REMOVE_DUPLICATES qtdeps)
endif()
Use _qt_module_has_headers instead of INTERFACE_MODULE_HAS_HEADERS After introducing the _qt_module_has_headers target property, it's better to replace the INTERFACE_MODULE_HAS_HEADERS use by _qt_module_has_headers since properties duplicate each other. Pick-to: 6.2 Change-Id: I4d62ed71b8ed8263f51d8575628693122580b4a7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-30 09:41:47 +00:00
get_target_property(hasModuleHeaders "${target}" _qt_module_has_headers)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
if (${hasModuleHeaders})
Replace the syncqt.pl script with syncqt tool syncqt.pl adds an extra dependency on perl when building Qt. Modern C++ provides the convenient cross-platform way to access a filesystem and to use regular expressions, so we may replace the perl script with C++ application. The syncqt executable is built at configure time and installed as QtCore tool. It's running at configure time to deliver the required header files for IDE to build a consistent code model and at the build time to keep tracking changes in header files and generate the missing aliases without reconfiguring. 'syncqt' only parses header files from a CMake build tree, so the resulting Qt installation only contains interfacing headers that belong to the platform that Qt is built for. 'sync.profile' files are not used as the 'source of truth' for sync qt procedure anymore, all the necessary information is taken from either CMake files at configure time or from the module header files while parsing them. syncqt.pl is still in place since it's required as fallback solution for a smooth transition to the new syncqt implementation for all qt repositories. This patchset only enables the C++ based syncqt for 'qtbase' repository. From the performance perspective C++ version works faster then perl script, also the configure time is reduced significally on subsequent reconfigurations - up x2 times faster when re-configuring repository, but it also takes time to compile the tool itself the first time. Numbers for qtbase: syncqt.pl syncqt.cpp initial: 0m16,035s 0m20,413s reconfig: 0m6,819s 0m3,725s The syncing procedure can be run separately for each module using <ModuleName>_sync_headers targets. The 'sync_headers' target can be used to sync all the modules at once. Task-number: QTBUG-87480 Task-number: QTBUG-103196 Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-15 16:29:41 +00:00
qt_internal_write_depends_file(${target} ${qtdeps})
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
if(third_party_deps OR main_module_tool_deps OR target_deps)
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}${target}")
qt_path_join(config_build_dir ${QT_CONFIG_BUILD_DIR} ${path_suffix})
qt_path_join(config_install_dir ${QT_CONFIG_INSTALL_DIR} ${path_suffix})
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
# All module packages should look for the Qt6 package version that qtbase was originally
# built as.
qt_internal_get_package_version_of_target(Platform main_qt_package_version)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# Configure and install ModuleDependencies file.
configure_file(
"${QT_CMAKE_DIR}/QtModuleDependencies.cmake.in"
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Dependencies.cmake"
@ONLY
)
qt_install(FILES
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Dependencies.cmake"
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
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
message(TRACE "Recorded dependencies for module: ${target}\n"
" Qt dependencies: ${target_deps}\n"
" 3rd-party dependencies: ${third_party_deps}")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
if(tool_deps)
# The value of the property will be used by qt_export_tools.
set_property(TARGET "${target}" PROPERTY _qt_tools_package_deps "${tool_deps}")
endif()
endfunction()
function(qt_internal_create_plugin_depends_file target)
get_target_property(plugin_install_package_suffix "${target}" _qt_plugin_install_package_suffix)
get_target_property(depends "${target}" LINK_LIBRARIES)
get_target_property(public_depends "${target}" INTERFACE_LINK_LIBRARIES)
get_target_property(target_deps "${target}" _qt_target_deps)
set(target_deps_seen "")
CMake: Process extra dependencies for plugin targets as well We started recording extra dependencies for the QtNetwork TLS plugin, but we never actually processed them to write out the necessary find_package calls. This broke static builds of qtopcua, because the OpenSSL::SSL target was no longer created in the root scope, but only in some child ones like src/opcua, whereas the target was referenced in generator expressions in a different sibling scope src/declarative_opcua, leading to errors like CMake Error at lib/cmake/Qt6/QtPrlHelpers.cmake:116 (file): Error evaluating generator expression: $<TARGET_LINKER_FILE:OpenSSL::SSL> No target "OpenSSL::SSL" Call Stack (most recent call first): lib/cmake/Qt6/QtModuleHelpers.cmake:837 (qt_generate_prl_file) lib/cmake/Qt6/QtScopeFinalizerHelpers.cmake:21:EVAL:1 (qt_finalize_module) src/declarative_opcua/CMakeLists.txt:DEFERRED Make sure to process the extra deps for plugins as well. Amends d754e43721e4f40a8dffa8b69ef883ca383a4a61 Amends 3c233175523a61e734dd5cd9bdcbb2994566f7f0 Pick-to: 6.4 Task-number: QTBUG-96283 Change-Id: I11876e0844198b3a794bc06b6691ee694fd3b1c2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-08 09:20:18 +00:00
# Extra 3rd party targets who's packages should be considered dependencies.
get_target_property(extra_third_party_deps "${target}" _qt_extra_third_party_dep_targets)
if(NOT extra_third_party_deps)
set(extra_third_party_deps "")
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
qt_collect_third_party_deps(${target})
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
qt_internal_remove_qt_dependency_duplicates(target_deps "${target_deps}")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
if(third_party_deps OR target_deps)
# Setup build and install paths
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 15:03:02 +00:00
# Plugins should look for their dependencies in their associated module package folder as
# well as the Qt6 package folder which is stored by the Qt6 package in _qt_cmake_dir.
set(find_dependency_paths "\${CMAKE_CURRENT_LIST_DIR}/..;\${_qt_cmake_dir}")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
if(plugin_install_package_suffix)
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}${plugin_install_package_suffix}")
if(plugin_install_package_suffix MATCHES "/QmlPlugins")
# Qml plugins are one folder deeper.
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 15:03:02 +00:00
set(find_dependency_paths "\${CMAKE_CURRENT_LIST_DIR}/../..;\${_qt_cmake_dir}")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
else()
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}${target}")
endif()
qt_path_join(config_build_dir ${QT_CONFIG_BUILD_DIR} ${path_suffix})
qt_path_join(config_install_dir ${QT_CONFIG_INSTALL_DIR} ${path_suffix})
# Configure and install ModuleDependencies file.
configure_file(
"${QT_CMAKE_DIR}/QtPluginDependencies.cmake.in"
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Dependencies.cmake"
@ONLY
)
qt_install(FILES
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}Dependencies.cmake"
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
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
message(TRACE "Recorded dependencies for plugin: ${target}\n"
" Qt dependencies: ${target_deps}\n"
" 3rd-party dependencies: ${third_party_deps}")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
endfunction()
function(qt_internal_create_qt6_dependencies_file)
# This is used for substitution in the configured file.
set(target "${INSTALL_CMAKE_NAMESPACE}")
# This is the actual target we're querying.
set(actual_target Platform)
get_target_property(public_depends "${actual_target}" INTERFACE_LINK_LIBRARIES)
CMake: Export 3rdparty dependency find_package calls of private modules Consider a Qt module with a 3rdparty library target in PRIVATE_MODULE_INTERFACE, e.g. XKB::XKB in Qt6::GuiPrivate. Consumers of GuiPrivate automatically depend on XKB::XKB. In order to do that they must find_package(XKB ...). As all find_package calls for GuiPrivate are in the same place as the ones for Gui, this package must be marked as optional. Otherwise all consumers of Qt6::Gui would have to have the xkbcommon package installed too. This patch exports find_package calls for every 3rdparty public dependency of private modules and marks them as optional. Change-Id: Ia1eeb09c29927fb6634ef08b477684ed6f123267 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-24 10:02:44 +00:00
unset(depends)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
CMake: Export 3rd party dep info also for the Qt6 package It usually looks up the Threads target, so we want it to be recorded as a provided target. Amends 58eefbd0b6169d0749b312268c1ae1e594e04362 Pick-to: 6.8 Change-Id: I0f06aaae98fd99da8fb6436d232a147e163580a2 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 17:10:26 +00:00
set(third_party_deps "")
set(third_party_deps_seen "")
set(third_party_deps_package_components_ids "")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# We need to collect third party deps that are set on the public Platform target,
# like Threads::Threads.
# This mimics find_package part of the CONFIG += thread assignment in mkspecs/features/qt.prf.
qt_collect_third_party_deps(${actual_target})
CMake: Export 3rd party dep info also for the Qt6 package It usually looks up the Threads target, so we want it to be recorded as a provided target. Amends 58eefbd0b6169d0749b312268c1ae1e594e04362 Pick-to: 6.8 Change-Id: I0f06aaae98fd99da8fb6436d232a147e163580a2 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-07-01 17:10:26 +00:00
qt_internal_collect_third_party_dep_packages_info("${INSTALL_CMAKE_NAMESPACE}"
"${third_party_deps_package_components_ids}"
packages_info)
set(third_party_deps_extra_info "")
if(packages_info)
string(APPEND third_party_deps_extra_info "${packages_info}")
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# For Threads we also need to write an extra variable assignment.
set(third_party_extra "")
if(third_party_deps MATCHES "Threads")
string(APPEND third_party_extra "if(NOT QT_NO_THREADS_PREFER_PTHREAD_FLAG)
set(THREADS_PREFER_PTHREAD_FLAG TRUE)
endif()")
endif()
CMake: Improve Qt6HostInfo package lookup condition Instead of checking if QT_HOST_PATH is set during user project configuration to find out if Qt6HostInfo should be looked up, record if QT_HOST_PATH was provided during Qt configuration into Qt6Dependencies.cmake and look up the package in a user project based on that information. This improves handling of the case where cmake is directly used to configure a Qt project (instead of qt-cmake), which means no QT_HOST_PATH might be set by the user, and then cmake would error out saying that e.g. Qt6CoreTools is not found, instead of saying that Qt6HostInfo is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I0377d5440e4b5b295af73cfd4b5188f61d48e440 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-18 12:14:41 +00:00
_qt_internal_determine_if_host_info_package_needed(platform_requires_host_info_package)
CMake: Move QT_HOST_PATH check and computation into Qt6 package Instead of trying to compute and validate the QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR variables in the generated toolchain file, do it in the Qt6 package. This provides better error messages when a project is configured without using the Qt generated toolchain file. Because it's not done in the toolchain anymore, remove the various host variables from __qt_toolchain_used_variables. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I1ca239ff83b8f783897e171fee352fc43e8ad7a8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-18 14:09:30 +00:00
if(platform_requires_host_info_package)
# TODO: Figure out how to make the initial QT_HOST_PATH var relocatable in relation
# to the target CMAKE_INSTALL_DIR, if at all possible to do so in a reliable way.
get_filename_component(qt_host_path_absolute "${QT_HOST_PATH}" ABSOLUTE)
get_filename_component(qt_host_path_cmake_dir_absolute
Avoid using the PROJECT_VERSION when accessing the HostInfo package variables The related functionality meant to be enabled by BuildInternals, which makes the lookup of the pre-defined HostInfo version based on either calculated or pre-defined INSTALL_CMAKE_NAMESPACE. The PROJECT_VESION(_MAJOR) meanwhile is hardcoded by the current Qt repo, which is not necessary aligned with BuildInternals/HostInfo. Pick-to: 6.5 6.8 6.9 Change-Id: I61052c93ce2d6ee3c6d8025da2e078edcde48d0d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-17 16:54:32 +00:00
"${${INSTALL_CMAKE_NAMESPACE}HostInfo_DIR}/.." ABSOLUTE)
CMake: Move QT_HOST_PATH check and computation into Qt6 package Instead of trying to compute and validate the QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR variables in the generated toolchain file, do it in the Qt6 package. This provides better error messages when a project is configured without using the Qt generated toolchain file. Because it's not done in the toolchain anymore, remove the various host variables from __qt_toolchain_used_variables. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I1ca239ff83b8f783897e171fee352fc43e8ad7a8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-18 14:09:30 +00:00
endif()
CMake: Improve Qt6HostInfo package lookup condition Instead of checking if QT_HOST_PATH is set during user project configuration to find out if Qt6HostInfo should be looked up, record if QT_HOST_PATH was provided during Qt configuration into Qt6Dependencies.cmake and look up the package in a user project based on that information. This improves handling of the case where cmake is directly used to configure a Qt project (instead of qt-cmake), which means no QT_HOST_PATH might be set by the user, and then cmake would error out saying that e.g. Qt6CoreTools is not found, instead of saying that Qt6HostInfo is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I0377d5440e4b5b295af73cfd4b5188f61d48e440 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-18 12:14:41 +00:00
if(third_party_deps OR platform_requires_host_info_package)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# Setup build and install paths.
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}")
qt_path_join(config_build_dir ${QT_CONFIG_BUILD_DIR} ${path_suffix})
qt_path_join(config_install_dir ${QT_CONFIG_INSTALL_DIR} ${path_suffix})
# Configure and install QtDependencies file.
configure_file(
"${QT_CMAKE_DIR}/QtConfigDependencies.cmake.in"
"${config_build_dir}/${target}Dependencies.cmake"
@ONLY
)
qt_install(FILES
"${config_build_dir}/${target}Dependencies.cmake"
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
endif()
endfunction()
# Create Depends.cmake & Depends.h files for all modules and plug-ins.
function(qt_internal_create_depends_files)
qt_internal_get_qt_repo_known_modules(repo_known_modules)
if(PROJECT_NAME STREQUAL "QtBase")
qt_internal_create_qt6_dependencies_file()
endif()
foreach (target ${repo_known_modules})
qt_internal_create_module_depends_file(${target})
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 20:14:50 +00:00
if(TARGET "${target}Private")
CMake: Simplify Qt6FooPrivate -> Qt6Foo package dependency setup This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Remove the EXTRA_PACKAGE_DEPENDENCIES argument that was added in mentioned commit, and use the qt_register_target_dependencies function instead to add the package dependency Qt6FooPrivate -> Qt6Foo. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I08a48954576dc3c0b6fde809f90d2022201d7eb0 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-06 10:15:12 +00:00
qt_internal_create_module_depends_file(${target}Private)
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 20:14:50 +00:00
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endforeach()
foreach (target ${QT_KNOWN_PLUGINS})
qt_internal_create_plugin_depends_file(${target})
endforeach()
endfunction()
CMake: Create and include plugin packages in shared builds Previously QtModulePlugins.cmake files were only created and included in static library Qt builds. Having the targets available in shared library builds would be useful for custom project deployment purposes. One could query the location of the plugins or use various generator expressions referencing their location. Ensure we always generate and include the QtModulePlugins.cmake files regardless of the build type. Allow opting out of including the files by setting QT_SKIP_AUTO_PLUGIN_INCLUSION to ON, just like we allow for Qml plugins with QT_SKIP_AUTO_QML_PLUGIN_INCLUSION. Pick-to: 6.4 Fixes: QTBUG-94066 Change-Id: I69a5dc17762a8e43265578fc33b82b5c4b7a1f5c Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-01 12:45:54 +00:00
# This function creates Qt<Module>Plugins.cmake files used to include all
# the plugin Config files that belong to that module.
function(qt_internal_create_plugins_auto_inclusion_files)
# For static library builds, the plugin targets need to be available for linking.
# For shared library builds, the plugin targets are useful for deployment purposes.
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
qt_internal_get_qt_repo_known_modules(repo_known_modules)
CMake: Improve 'Generating Plugins' message Use message(STATUS) for the 'Generating Plugins' message. This way it will go to stdout instead of stderr, which follows the convention we have for most of our other messages. Also list only the modules that actually have plugins, rather than all known modules. Pick-to: 6.2 6.3 6.4 Change-Id: I1ea0ed71418ede54790cabd32e03e82fc69f2858 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-01 13:00:50 +00:00
set(modules_with_plugins "")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
foreach (QT_MODULE ${repo_known_modules})
get_target_property(target_type "${QT_MODULE}" TYPE)
if(target_type STREQUAL "INTERFACE_LIBRARY")
# No plugins are provided by a header only module.
continue()
endif()
qt_path_join(config_build_dir ${QT_CONFIG_BUILD_DIR} ${INSTALL_CMAKE_NAMESPACE}${QT_MODULE})
qt_path_join(config_install_dir ${QT_CONFIG_INSTALL_DIR} ${INSTALL_CMAKE_NAMESPACE}${QT_MODULE})
set(QT_MODULE_PLUGIN_INCLUDES "")
if(QT_MODULE STREQUAL "Qml")
set(QT_MODULE_PLUGIN_INCLUDES "${QT_MODULE_PLUGIN_INCLUDES}
CMake: Move qml plugin auto inclusion code into a separate macro The code is moved into a macro without any modifications aside from removing the escaping of variable evaluation and escaping of quotes. It's kept as a macro similar to __qt_internal_include_plugin_packages, because there might be calls to find_package() that set variables in the current scope. The reason for moving is easier maintenance (no more escaping). Pick-to: 6.8 6.9 Change-Id: Ie6ddc26fe4ff8db0134f3542c2886f8b5d68dc51 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2025-01-23 17:23:24 +00:00
__qt_internal_include_qml_plugin_packages()
")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
Change the way we detect the need of adding Qt<Module>Plugins.cmake Currently we assume that only modules that have plugins built in the current build tree need to generate and install the Qt<Module>Plugins.cmake file. This approach is weak since other Qt modules might still want to provide the plugins of the certain types, even if the module that the plugin type belongs too didn't have plugins initially. The fix unblocks the formally 3rd-party plugin installation and loading chain. Pick-to: 6.2 6.5 6.6 6.7 Fixes: QAA-2266 Change-Id: Ifc616e26a00674371c8e2fe2ca12237d153e5707 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-01-30 12:03:06 +00:00
get_target_property(module_plugin_types "${QT_MODULE}" MODULE_PLUGIN_TYPES)
if(module_plugin_types OR QT_MODULE_PLUGIN_INCLUDES)
CMake: Improve 'Generating Plugins' message Use message(STATUS) for the 'Generating Plugins' message. This way it will go to stdout instead of stderr, which follows the convention we have for most of our other messages. Also list only the modules that actually have plugins, rather than all known modules. Pick-to: 6.2 6.3 6.4 Change-Id: I1ea0ed71418ede54790cabd32e03e82fc69f2858 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-01 13:00:50 +00:00
list(APPEND modules_with_plugins "${QT_MODULE}")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
configure_file(
"${QT_CMAKE_DIR}/QtPlugins.cmake.in"
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${QT_MODULE}Plugins.cmake"
@ONLY
)
qt_install(FILES
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${QT_MODULE}Plugins.cmake"
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
endif()
endforeach()
CMake: Improve 'Generating Plugins' message Use message(STATUS) for the 'Generating Plugins' message. This way it will go to stdout instead of stderr, which follows the convention we have for most of our other messages. Also list only the modules that actually have plugins, rather than all known modules. Pick-to: 6.2 6.3 6.4 Change-Id: I1ea0ed71418ede54790cabd32e03e82fc69f2858 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-01 13:00:50 +00:00
if(modules_with_plugins)
message(STATUS "Generated QtModulePlugins.cmake files for the following modules:"
" ${modules_with_plugins}")
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endfunction()
function(qt_generate_install_prefixes out_var)
set(content "\n")
set(vars INSTALL_BINDIR INSTALL_INCLUDEDIR INSTALL_LIBDIR INSTALL_MKSPECSDIR INSTALL_ARCHDATADIR
INSTALL_PLUGINSDIR INSTALL_LIBEXECDIR INSTALL_QMLDIR INSTALL_DATADIR INSTALL_DOCDIR
INSTALL_TRANSLATIONSDIR INSTALL_SYSCONFDIR INSTALL_EXAMPLESDIR INSTALL_TESTSDIR
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 17:02:56 +00:00
INSTALL_DESCRIPTIONSDIR INSTALL_SBOMDIR)
Export `INSTALL_PUBLICBINDIR` to `QtBuildInternalsExtra.cmake` `INSTALL_PUBLICBINDIR` is only exported if it was defined by the user when building QtBase. The conditional check aligns with the one used in `qt_internal_generate_user_facing_tools_info` Fixes: QTBUG-107016 Pick-to: 6.8 6.9 Change-Id: Id5c38555e1d22cb3c16d85261cb052c695b4de03 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-21 13:33:59 +00:00
# INSTALL_PUBLICBINDIR is processed only if it is not empty
# See usage in qt_internal_generate_user_facing_tools_info
if(NOT "${INSTALL_PUBLICBINDIR}" STREQUAL "")
list(APPEND vars INSTALL_PUBLICBINDIR)
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
foreach(var ${vars})
get_property(docstring CACHE "${var}" PROPERTY HELPSTRING)
string(APPEND content "set(${var} \"${${var}}\" CACHE STRING \"${docstring}\" FORCE)\n")
endforeach()
set(${out_var} "${content}" PARENT_SCOPE)
endfunction()
function(qt_wrap_string_in_if_multi_config content out_var)
set(${out_var} "
get_property(__qt_is_multi_config GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
if(__qt_is_multi_config)
${content}endif()
unset(__qt_is_multi_config)\n" PARENT_SCOPE)
endfunction()
function(qt_wrap_string_in_if_ninja_multi_config content out_var)
set(${out_var} "if(CMAKE_GENERATOR STREQUAL \"Ninja Multi-Config\")
${content}endif()\n" PARENT_SCOPE)
endfunction()
function(qt_create_hostinfo_package)
set(package "${INSTALL_CMAKE_NAMESPACE}HostInfo")
qt_path_join(config_file_path "${QT_CONFIG_BUILD_DIR}/${package}/${package}Config.cmake")
qt_path_join(install_destination ${QT_CONFIG_INSTALL_DIR} ${package})
set(var_prefix "QT${PROJECT_VERSION_MAJOR}_HOST_INFO_")
configure_package_config_file(
"${CMAKE_CURRENT_LIST_DIR}/QtHostInfoConfig.cmake.in"
"${config_file_path}"
INSTALL_DESTINATION "${install_destination}"
NO_SET_AND_CHECK_MACRO
NO_CHECK_REQUIRED_COMPONENTS_MACRO)
qt_install(FILES "${config_file_path}" DESTINATION "${install_destination}")
endfunction()
function(qt_generate_build_internals_extra_cmake_code)
if(PROJECT_NAME STREQUAL "QtBase")
qt_create_hostinfo_package()
foreach(var IN LISTS QT_BASE_CONFIGURE_TESTS_VARS_TO_EXPORT)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "set(${var} \"${${var}}\" CACHE INTERNAL \"\")\n")
endforeach()
set(QT_SOURCE_TREE "${QtBase_SOURCE_DIR}")
qt_path_join(extra_file_path
${QT_CONFIG_BUILD_DIR}
${INSTALL_CMAKE_NAMESPACE}BuildInternals/QtBuildInternalsExtra.cmake)
if(CMAKE_BUILD_TYPE)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
CMake: Support overriding CMAKE_BUILD_TYPE per-repo or test One might want to build qtbase in Release, but qtsvg or some test in Debug mode. Before if qtbase was configured as Release, there was no way to override that. Now we try to detect whether a custom build type was specified to qt-cmake / qt-configure-module / qt-cmake-standalone-test / qt-internal-configure-tests Note mixing won't work on Windows due to different C/C++ runtimes. Also, now we don't force set a single build type when a multi config generator is used as well as one opts out via the QT_NO_FORCE_SET_CMAKE_BUILD_TYPE variable. Pick-to: 6.2 6.3 Change-Id: I6dc4325087ff7f905ad677d87b0267e2f3e4693f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2022-01-19 12:13:12 +00:00
"
CMake: Simplify default CMAKE_BUILD_TYPE logic Previously we had four-ish locations where the CMAKE_BUILD_TYPE was force set. Twice in QtBuildInternalsExtra.cmake via qt_internal_force_set_cmake_build_type_conditionally(), depending on some conditions. This was executed right at find_package(Qt6 COMPONENTS BuildInternals) time. And twice in qt_internal_set_default_build_type() via qt_build_repo_begin() / qt_prepare_standalone_project() that goes through QtSetup.cmake. This was executed only if the relevant functions were called, rather than directly at find_package() time. The exact logic of which build type ended up being set was very confusing. Refactor the code to decide the build type in one single location when qt_build_repo_begin() / qt_prepare_standalone_project() are called, rather than directly at find_package() time. The actual logic when we override the build type depends on many factors: - when an explicit CMAKE_BUILD_TYPE is given, honor it, unless it's a multi-config build - when it's a multi-config build, don't set any CMAKE_BUILD_TYPE, use the value of CMAKE_CONFIGURATION_TYPES - when it's a qtbase build, compute a default unless an explicit value was given - the default is Debug if FEATURE_developer_build is ON - otherwise the default is Release - when it's a top-level build, only choose a build type for qtbase - when it's another repo build, use the original build type unless another was given explicitly (including in a top-level build) - when it's a standalone tests build - if qt is multi-config, the tests will be single config, due to various CI failure reasons, this hasn't changed - if qt is single config, use the original unless an explicit value was given - when it's a single standalone test build, use the original unless an explicit value was given To determine when an explicit CMAKE_BUILD_TYPE was given in contrast to when it was default initialized, we now have one single function that uses a few heuristics. The heuristics are needed because we can't reliably determine an explicitly given 'Debug' build on Windows, because CMake default initializes to that. The heuristics include: - checking whether CMAKE_BUILD_TYPE_INIT is different from CMAKE_BUILD_TYPE - checking what the CMAKE_BUILD_TYPE was before the first project() call when CMake default initializes - we save the previous value in the qt.toolchain.cmake file - also in QtAutoDetect during qtbase configuration - also when building the sqldrivers project - honoring the value of QT_NO_FORCE_SET_CMAKE_BUILD_TYPE As a result of the above changes, the build type will be set exactly zero or one times, for a particular build directory. Note that the configure script also has some logic on which CMAKE_BUILD_TYPE / CMAKE_CONFIGURATION_TYPES to pass to CMake depending on whether -debug / -release / -debug-and-release / -force-debug-info were passed. But once the values are passed, CMake will honor them. Amends 48841c34d2e86a741ec9992b9704c0fa5973503c Amends 8c912cddebe544010e7da3f87af5b21f3328d7ec Pick-to: 6.7 Task-number: QTBUG-114958 Task-number: QTBUG-120436 Change-Id: I30db14d1e8e9ff9bd2d7ea1d2256cdeb9493ca0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2024-01-22 17:11:31 +00:00
# Used by qt_internal_set_cmake_build_type.
CMake: Support overriding CMAKE_BUILD_TYPE per-repo or test One might want to build qtbase in Release, but qtsvg or some test in Debug mode. Before if qtbase was configured as Release, there was no way to override that. Now we try to detect whether a custom build type was specified to qt-cmake / qt-configure-module / qt-cmake-standalone-test / qt-internal-configure-tests Note mixing won't work on Windows due to different C/C++ runtimes. Also, now we don't force set a single build type when a multi config generator is used as well as one opts out via the QT_NO_FORCE_SET_CMAKE_BUILD_TYPE variable. Pick-to: 6.2 6.3 Change-Id: I6dc4325087ff7f905ad677d87b0267e2f3e4693f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2022-01-19 12:13:12 +00:00
set(__qt_internal_initial_qt_cmake_build_type \"${CMAKE_BUILD_TYPE}\")
")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
if(CMAKE_CONFIGURATION_TYPES)
string(APPEND multi_config_specific
" set(CMAKE_CONFIGURATION_TYPES \"${CMAKE_CONFIGURATION_TYPES}\" CACHE STRING \"\" FORCE)\n")
endif()
if(CMAKE_TRY_COMPILE_CONFIGURATION)
string(APPEND multi_config_specific
" set(CMAKE_TRY_COMPILE_CONFIGURATION \"${CMAKE_TRY_COMPILE_CONFIGURATION}\")\n")
endif()
if(multi_config_specific)
qt_wrap_string_in_if_multi_config(
"${multi_config_specific}"
multi_config_specific)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "${multi_config_specific}")
endif()
if(QT_MULTI_CONFIG_FIRST_CONFIG)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"\nset(QT_MULTI_CONFIG_FIRST_CONFIG \"${QT_MULTI_CONFIG_FIRST_CONFIG}\")\n")
endif()
if(CMAKE_CROSS_CONFIGS)
string(APPEND ninja_multi_config_specific
" set(CMAKE_CROSS_CONFIGS \"${CMAKE_CROSS_CONFIGS}\" CACHE STRING \"\")\n")
endif()
if(CMAKE_DEFAULT_BUILD_TYPE)
string(APPEND ninja_multi_config_specific
" set(CMAKE_DEFAULT_BUILD_TYPE \"${CMAKE_DEFAULT_BUILD_TYPE}\" CACHE STRING \"\")\n")
endif()
if(CMAKE_DEFAULT_CONFIGS)
string(APPEND ninja_multi_config_specific
" set(CMAKE_DEFAULT_CONFIGS \"${CMAKE_DEFAULT_CONFIGS}\" CACHE STRING \"\")\n")
endif()
if(ninja_multi_config_specific)
qt_wrap_string_in_if_ninja_multi_config(
"${ninja_multi_config_specific}"
ninja_multi_config_specific)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "${ninja_multi_config_specific}")
endif()
if(DEFINED BUILD_WITH_PCH)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(BUILD_WITH_PCH \"${BUILD_WITH_PCH}\" CACHE STRING \"\")\n")
endif()
CMake: Fix building multi-arch universal macOS Qt Use the same approach we use for iOS, which is to set multiple CMAKE_OSX_ARCHITECTURES values and let the clang front end deal with lipo-ing the final libraries. For now, Qt can be configured to build universal macOS libraries by passing 2 architectures to CMake, either via: -DCMAKE_OSX_ARCHITECTURES="x86_64;arm64" or -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" Currently we recommend specifying the intel x86_64 arch as the first one, to get an intel slice configuration that is comparable to a non-universal intel build. Specifying the arm64 slice first could pessimize optimizations and reduce the feature set for the intel slice due to the limitation that we run configure tests only once. The first specified architecture is the one used to do all the configure tests. It 'mostly' defines the common feature set of both architecture slices, with the excepion of some special handling for sse2 and neon instructions. In the future we might want to run at least the Qt architecture config test for all specified architectures, so that we can extract all the supported sub-arches and instruction sets in a reliable way. For now, we use the same sse2 hack as for iOS simulator_and_device builds, otherwise QtGui fails to link due to missing qt_memfill32_sse2 and other symbols. The hack is somewhat augmented to ensure that reconfiguration still succeeds (same issue happened with iOS). Previously the sse2 feature condition was broken due to force setting the feature to be ON. Now the condition also checks for a special QT_FORCE_FEATURE_sse2 variable which we set internally. Note that we shouldn't build for arm64e, because the binaries get killed when running on AS with the following message: kernel: exec_mach_imgact: not running binary built against preview arm64e ABI. Aslo, by default, we disable the arm64 slice for qt sql plugins, mostly because the CI provisioned sql libraries that we depend on only contain x86_64 slices, and trying to build the sql plugins for both slices will fail with linker errors. This behavior can be disabled for all targets marked by qt_internal_force_macos_intel_arch, by setting the QT_FORCE_MACOS_ALL_ARCHES CMake option to ON. To disble it per-target one can set QT_FORCE_MACOS_ALL_ARCHES_${target} to ON. Task-number: QTBUG-85447 Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-03-24 15:03:35 +00:00
if(DEFINED QT_IS_MACOS_UNIVERSAL)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_IS_MACOS_UNIVERSAL \"${QT_IS_MACOS_UNIVERSAL}\" CACHE BOOL \"\")\n")
endif()
cmake: Rename QT_UIKIT_SDK to QT_APPLE_SDK The SDK is relevant for all Apple systems, including macOS, iOS, tvOS, watchOS, and visionOS. We still pick up -DQT_UIKIT_SDK for iOS for compatibility. [ChangeLog][CMake] The -sdk configure argument now maps to the QT_APPLE_SDK CMake variable. QT_UIKIT_SDK is still supported for iOS builds for compatibility. Change-Id: I983a2f23c2414eb73cd35bb83738088defb45cbd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-03-18 10:58:22 +00:00
if(DEFINED QT_APPLE_SDK)
CMake: Save value of QT_UIKIT_SDK in QtBuildInternalsExtra.cmake The value of QT_UIKIT_SDK is used in configure tests via qt_config_compile_test -> qt_get_platform_try_compile_vars. Up till now QT_UIKIT_SDK was only available in qtbase only. Save the value in BuildInternals to ensure it's used for other repos as well. Change-Id: I46f372267782f1c8e7d48c237fe0264ac72d33bb Pick-to: 6.2 Task-number: QTBUG-95838 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 07:56:35 +00:00
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
cmake: Rename QT_UIKIT_SDK to QT_APPLE_SDK The SDK is relevant for all Apple systems, including macOS, iOS, tvOS, watchOS, and visionOS. We still pick up -DQT_UIKIT_SDK for iOS for compatibility. [ChangeLog][CMake] The -sdk configure argument now maps to the QT_APPLE_SDK CMake variable. QT_UIKIT_SDK is still supported for iOS builds for compatibility. Change-Id: I983a2f23c2414eb73cd35bb83738088defb45cbd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-03-18 10:58:22 +00:00
"set(QT_APPLE_SDK \"${QT_APPLE_SDK}\" CACHE BOOL \"\")\n")
CMake: Save value of QT_UIKIT_SDK in QtBuildInternalsExtra.cmake The value of QT_UIKIT_SDK is used in configure tests via qt_config_compile_test -> qt_get_platform_try_compile_vars. Up till now QT_UIKIT_SDK was only available in qtbase only. Save the value in BuildInternals to ensure it's used for other repos as well. Change-Id: I46f372267782f1c8e7d48c237fe0264ac72d33bb Pick-to: 6.2 Task-number: QTBUG-95838 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 07:56:35 +00:00
endif()
CMake: also allow building tools when found elsewhere in host builds Previously, this was only supported when cross-compiling, but that's an unnecessary limitation. Instead, make it possible to build the "host" tools (notably qmake) even when they've been found elsewhere due to QT_FORCE_FIND_TOOLS=ON and a supplied QT_HOST_PATH. The combination of QT_FORCE_FIND_TOOLS and QT_FORCE_BUILD_TOOLS set to ON is useful for developers who touch content that ends up in the bootstrap library. QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is deprecated in favor of QT_FORCE_BUILD_TOOLS. [ChangeLog][CMake] QT_BUILD_TOOLS_WHEN_CROSSCOMPILING has been deprecated in favor of QT_FORCE_BUILD_TOOLS. The latter can be used in combination with QT_FORCE_FIND_TOOLS and QT_HOST_PATH to use tools from a host Qt even for a non-cross build and still build the tools. Fixes: QTBUG-99683 Change-Id: I0e5f6bec596a4a78bd3bfffd16c8fb486181f9b6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2022-01-10 18:12:32 +00:00
if(QT_FORCE_FIND_TOOLS)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
CMake: also allow building tools when found elsewhere in host builds Previously, this was only supported when cross-compiling, but that's an unnecessary limitation. Instead, make it possible to build the "host" tools (notably qmake) even when they've been found elsewhere due to QT_FORCE_FIND_TOOLS=ON and a supplied QT_HOST_PATH. The combination of QT_FORCE_FIND_TOOLS and QT_FORCE_BUILD_TOOLS set to ON is useful for developers who touch content that ends up in the bootstrap library. QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is deprecated in favor of QT_FORCE_BUILD_TOOLS. [ChangeLog][CMake] QT_BUILD_TOOLS_WHEN_CROSSCOMPILING has been deprecated in favor of QT_FORCE_BUILD_TOOLS. The latter can be used in combination with QT_FORCE_FIND_TOOLS and QT_HOST_PATH to use tools from a host Qt even for a non-cross build and still build the tools. Fixes: QTBUG-99683 Change-Id: I0e5f6bec596a4a78bd3bfffd16c8fb486181f9b6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2022-01-10 18:12:32 +00:00
"set(QT_FORCE_FIND_TOOLS \"TRUE\" CACHE BOOL \"\" FORCE)\n")
endif()
if(QT_FORCE_BUILD_TOOLS)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_FORCE_BUILD_TOOLS \"TRUE\" CACHE BOOL \"\" FORCE)\n")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()
CMake: Rename QT_INTERNAL_CUSTOM_INSTALL_DIR to QT_INTERNAL_EXAMPLES_INSTALL_PREFIX so it's clear that the variable only affects the location of where examples are installed. And make sure the paths are passed as CMake paths. Amends 1031fa15472bba3f20691cda2305e0821391c5db Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: Ib92c55488b736d980da2bd88255de78e183de824 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-21 10:13:20 +00:00
if(QT_INTERNAL_EXAMPLES_INSTALL_PREFIX)
file(TO_CMAKE_PATH
"${QT_INTERNAL_EXAMPLES_INSTALL_PREFIX}" examples_install_prefix)
CMake: Allow installing examples outside of the Qt prefix Introduce a new QT_INTERNAL_CUSTOM_INSTALL_DIR variable to allow specifying an 'examples install dir' outside of the Qt prefix. It will be used in a follow-up change to ensure we don't package the example binaries in our CI artifacts (thus saving space). This will be even more important when the examples will contain code to deploy Qt libraries alongside each deployed example (which would significantly increase the package size). Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I06b4a8f9e8c57a712a356bca0f5c351a9362bc30 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-12-16 11:55:07 +00:00
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
CMake: Rename QT_INTERNAL_CUSTOM_INSTALL_DIR to QT_INTERNAL_EXAMPLES_INSTALL_PREFIX so it's clear that the variable only affects the location of where examples are installed. And make sure the paths are passed as CMake paths. Amends 1031fa15472bba3f20691cda2305e0821391c5db Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: Ib92c55488b736d980da2bd88255de78e183de824 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-21 10:13:20 +00:00
"set(QT_INTERNAL_EXAMPLES_INSTALL_PREFIX \"${examples_install_prefix}\" CACHE STRING \"\")\n")
CMake: Allow installing examples outside of the Qt prefix Introduce a new QT_INTERNAL_CUSTOM_INSTALL_DIR variable to allow specifying an 'examples install dir' outside of the Qt prefix. It will be used in a follow-up change to ensure we don't package the example binaries in our CI artifacts (thus saving space). This will be even more important when the examples will contain code to deploy Qt libraries alongside each deployed example (which would significantly increase the package size). Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I06b4a8f9e8c57a712a356bca0f5c351a9362bc30 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-12-16 11:55:07 +00:00
endif()
CMake: Export QT_QPA_DEFAULT_PLATFORM in QtBuildInternalsExtra The value is useful for QPA plugins built in repos other than qtbase, to decide if it should be a default plugin or not. Currently useful for qtwayland. Also export a qmake value assignment when doing static builds, just like src/gui/configure.pri does. Change-Id: I1253f1a7e178b24b16e2615ba20d1e92b0b87b1a Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-26 13:50:23 +00:00
# Save the default qpa platform.
if(DEFINED QT_QPA_DEFAULT_PLATFORM)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_QPA_DEFAULT_PLATFORM \"${QT_QPA_DEFAULT_PLATFORM}\" CACHE STRING \"\")\n")
endif()
Change the -qpa configure argument logic Parse the -qpa configure argument as list and translate it to the QT_QPA_PLATFORMS cmake variable. This variable is new to the Qt build procedure. The QT_QPA_DEFAULT_PLATFORM variable supposed to get multiple values, but this didn't work at all, since the variable value then was used in the compile definition that is expected to be a single value QPA platfrom definition. This inconsistency forced to introduce a new variable. The QT_QPA_DEFAULT_PLATFORM variable now controls the first-choice QPA plugin for the GUI applications. The new configure argument -default-qpa is now translated to the QT_QPA_DEFAULT_PLATFORM variable instead the of -qpa one. The -qpa configure argument is now translated to the QT_QPA_PLATFORMS variable, which is new one as well. The variable contains the list of QPA plugins that are "default" for this Qt configuration. The meaning of the "default" plugins is related to the DEFAULT_IF argument of qt_internal_add_plugin command. Plugins that are listed in the QT_QPA_PLATFORMS variable will be treated as default by the build system and will be deployed within user applications when using deployment API or linked statically when using static Qt. The QT_QPA_DEFAULT_PLATFORM falls back to the QT_QPA_PLATFORMS first value in the list if it's not set explicitly and either '-DQT_QPA_PLATFORMS' or '-qpa' arguments are specified. [ChangeLog][CMake] Added QT_QPA_PLATFORMS variable which controls the list of QPA plugins that will be deployed within the applications by default. [ChangeLog][CMake] The '-qpa' configure argument now is mapped to the QT_QPA_PLATFORMS variable and has different functionality. It doesn't control the platform plugin that the GUI application is using by default, but controls the list of QPA plugins that will be deployed within the applications by default. [ChangeLog][CMake] Added '-default-qpa' argument which replaces the '-qpa' one. The argument is translated to the QT_DEFAULT_QPA_PLATFORM CMake variable and selects the default platform that should be used by GUI application if QT_QPA_PLATFORM environment variable is not set. Task-number: QTBUG-124265 Task-number: QTBUG-87805 Task-number: QTBUG-124449 Change-Id: Ibcebaccc535aaed6374f15ccfeddb3e6128f5ce0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-04-11 08:55:53 +00:00
# Save the list of default qpa platforms.
# Used by qtwayland/src/plugins/platforms/qwayland-generic/CMakeLists.txt. Otherwise
# the DEFAULT_IF condition is evaluated incorrectly.
if(DEFINED QT_QPA_PLATFORMS)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_QPA_PLATFORMS \"${QT_QPA_PLATFORMS}\" CACHE STRING \"\")\n")
endif()
CMake: Enable NEW policies by CMake version with a global default When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-30 07:46:49 +00:00
# Save minimum and policy-related CMake versions to ensure the same minimum is
CMake: Enforce minimum CMake version in user projects This change introduces new behavior to error out when configuring user projects if the CMake version used is too old for Qt to work with. The main motivator is the requirement of new CMake features to ensure object libraries are placed in the proper place on the link line in static builds. The minimum CMake version is computed based on whether Qt was configured as shared or static libraries. At the moment the required versions for building and using Qt are the same. The minimum versions are defined in qtbase/.cmake.conf in the following variables QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_SHARED QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_STATIC QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_SHARED QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_STATIC Qt Packagers can disable the version check when configuring Qt by setting QT_FORCE_MIN_CMAKE_VERSION_FOR_BUILDING_QT and QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT. In this case it is the packagers responsibility to ensure such a Qt works correctly with the specified CMake version. User projects can also set QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT to disable the version check. Then it's the project's developer responsibility to ensure such a Qt works correctly. No official support is provided for these cases. Implementation notes. The versions required to build Qt are stored in QtBuildInternalsExtra.cmake whereas the versions required to use Qt are stored in a new QtConfigExtras.cmake. Also the policy range variables stored in QtBuildInternalsExtra.cmake are now regular variables instead of cache variables, to properly allow overrides per-repository. Some renaming of functions and variables was done for a bit more clarity and easier grep-ability. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: I4279f2e10b6d3977319237ba21e2f4ed676aa48b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-22 14:23:51 +00:00
# checked for when building other downstream repos (qtsvg, etc) and the policy settings
# will be consistent unless the downstream repos explicitly override them.
# Policy settings can be overridden per-repo, but the minimum CMake version is global for all of
# Qt.
qt_internal_get_supported_min_cmake_version_for_building_qt(
supported_min_version_for_building_qt)
qt_internal_get_computed_min_cmake_version_for_building_qt(
computed_min_version_for_building_qt)
qt_internal_get_min_new_policy_cmake_version(min_new_policy_version)
qt_internal_get_max_new_policy_cmake_version(max_new_policy_version)
CMake: Bump the minimum required CMake version to build Qt to 3.18 Add a new function that returns the minimum CMake version required to build Qt. Pass that value to cmake_minimum_required() when building qtbase and its standalone tests. The minimum supported CMake version is read from qtbase/.cmake.conf and its value should be updated when the need arises. It's the main source of truth for all repos. Provide a way to lower the minimum CMake version at configure time by passing a value via QT_FORCE_MIN_CMAKE_VERSION. This is not an officially supported way of building Qt. If the specified version is lower than Qt's supported minimum, show a warning. Nevertheless the option is useful for testing how Qt builds with a different minimum CMake version due to different policies being enabled by default. Issue warnings for CMake versions that are higher than the minimum version but are known to cause issues when building Qt. A counterpart change is needed in qt5 to ensure the minimum CMake version is set at the proper time for top-level builds. Ideally we would use the same 'check the CMake minimum version` code in all our repositories, but that will cause lots of duplication because we can't really find_package() the code and doing something like include(../qtbase/foo.cmake) hardcodes assumptions about repo locations. So for now we don't bump the minimum version in child repo cmake_minimum_required calls (qtsvg, qtdeclarative, etc). Instead we record both the minimum supported version and the computed minimum version (in case a different version was forced) in QtBuildInternalsExtra.cmake. Then we require qtbase's computed min version in qt_build_repo_begin(). This won't set policies as cmake_minimum_required would, but at least it propagates what minimum CMake version should be used for child repos. We might still have to bump the versions in child repos at some point. Task-number: QTBUG-88086 Change-Id: Ida1c0d5d3e0fbb15d2aee9b68abab7a1648774b9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-30 16:42:34 +00:00
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# Rpath related things that need to be re-used when building other repos.
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(CMAKE_INSTALL_RPATH \"${CMAKE_INSTALL_RPATH}\" CACHE STRING \"\")\n")
if(DEFINED QT_DISABLE_RPATH)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_DISABLE_RPATH \"${QT_DISABLE_RPATH}\" CACHE STRING \"\")\n")
endif()
CMake: Handle -D, -I, -F and -L configure arguments Introduce new CMake variables and map -D to QT_EXTRA_DEFINES, -I to QT_EXTRA_INCLUDEPATHS, -L to QT_EXTRA_LIBDIRS, and -F to QT_EXTRA_FRAMEWORKPATHS. Those variables only affect the Qt build, not user projects. Fixes: QTBUG-85878 Change-Id: I229df2eed1505a2619068d0d32975962b052569a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-13 12:36:50 +00:00
if(DEFINED QT_EXTRA_DEFINES)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_EXTRA_DEFINES \"${QT_EXTRA_DEFINES}\" CACHE STRING \"\")\n")
endif()
if(DEFINED QT_EXTRA_INCLUDEPATHS)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_EXTRA_INCLUDEPATHS \"${QT_EXTRA_INCLUDEPATHS}\" CACHE STRING \"\")\n")
endif()
if(DEFINED QT_EXTRA_FRAMEWORKPATHS)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_EXTRA_FRAMEWORKPATHS \"${QT_EXTRA_FRAMEWORKPATHS}\" CACHE STRING \"\")\n")
endif()
if(DEFINED QT_EXTRA_LIBDIRS)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_EXTRA_LIBDIRS \"${QT_EXTRA_LIBDIRS}\" CACHE STRING \"\")\n")
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
if(DEFINED QT_EXTRA_RPATHS)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_EXTRA_RPATHS \"${QT_EXTRA_RPATHS}\" CACHE STRING \"\")\n")
endif()
Add -disable-deprecated-up-to parameter to configure script And also teach CMake to treat it properly instead of hardcoding the version number. [ChangeLog][Build System] The configure script now accepts a new parameter -disable-deprecated-up-to which is used to remove all deprecated code from API and ABI while building the libraries. The version number must be specified in a hex format. For example, it can be used like this: /path/to/qt/configure -disable-deprecated-up-to 0x060500 to remove all code deprecated in Qt 6.5.0 or earlier releases. Task-number: QTBUG-101510 Change-Id: I557cf83e29b867fa1052bb097985e144b5eaf34d Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-16 11:02:27 +00:00
if(DEFINED QT_DISABLE_DEPRECATED_UP_TO)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_DISABLE_DEPRECATED_UP_TO \"${QT_DISABLE_DEPRECATED_UP_TO}\""
" CACHE STRING \"\")\n")
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# Save pkg-config feature value to be able to query it internally as soon as BuildInternals
# package is loaded. This is to avoid any pkg-config package from being found when
# find_package(Qt6Core) is called in case if the feature was disabled.
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "
if(NOT QT_SKIP_BUILD_INTERNALS_PKG_CONFIG_FEATURE)
FEATURE_pkg_config Should be BOOL It might not matter as far as I understand, but having it saved as BOOL is better if it's a boolean. Change-Id: If35485425257ca5518f0f8a49ca5353b9ac875a8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-28 09:44:25 +00:00
set(FEATURE_pkg_config \"${FEATURE_pkg_config}\" CACHE BOOL \"Using pkg-config\" FORCE)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endif()\n")
# The OpenSSL root dir needs to be saved so that repos other than qtbase (like qtopcua) can
# still successfully find_package(WrapOpenSSL) in the CI.
# qmake saves any additional include paths passed via the configure like '-I/foo'
# in mkspecs/qmodule.pri, so this file is the closest equivalent.
if(DEFINED OPENSSL_ROOT_DIR)
file(TO_CMAKE_PATH "${OPENSSL_ROOT_DIR}" openssl_root_cmake_path)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(OPENSSL_ROOT_DIR \"${openssl_root_cmake_path}\" CACHE STRING \"\")\n")
endif()
qt_generate_install_prefixes(install_prefix_content)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "${install_prefix_content}")
Pass OpenGL_GL_PREFERENCE variable to other Qt repos When building Linux packages, we pass OpenGL_GL_PREFERENCE=LEGACY when building qtbase. This is done to link against legacy OpenGL libs. When building non-qtbase repos, we also need to set this variable to the same value we have in qtbase. Pick-to: 6.1 Task-number: QTBUG-89754 Fixes: QTBUG-94040 Change-Id: I567b629d245025d2b1544b91cfc265a9c921725f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-01 10:51:36 +00:00
if(DEFINED OpenGL_GL_PREFERENCE)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"
# Use the OpenGL_GL_PREFERENCE value qtbase was built with. But do not FORCE it.
set(OpenGL_GL_PREFERENCE \"${OpenGL_GL_PREFERENCE}\" CACHE STRING \"\")
")
endif()
Centralize copyright information for Qt Maintain one central place - .cmake.conf - for information about Qt's copyright. Pick-to: 6.2 6.5 Change-Id: Ibcbce4313eba9660d459061b0ad00307e267b8f7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-14 12:31:39 +00:00
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"
set(QT_COPYRIGHT \"${QT_COPYRIGHT}\" CACHE STRING \"\")
")
CMake: Fix configuring a standalone test on Apple platforms Configuring a test as standalone would fail with the following error: Invalid max SDK version: It should be a major version number, without minor This happened because _qt_internal_check_apple_sdk_and_xcode_versions expects QT_SUPPORTED_MAX_MACOS_SDK_VERSION to be available, but it is not yet set due to Qt6 package not being found yet. Avoid the issue by exporting the version requirements into both Qt6ConfigExtras.cmake and Qt6BuildInternalsConfigExtra.cmake. Make sure to assign the variables only once. Amends a29bff3d80219f54d0837b0e6e0577192011dea1 Amends a0bdd2195f24d8a7d880ba506afc16b41337218e Pick-to: 6.6 6.7 Task-number: QTBUG-119490 Change-Id: Ic297eeaabf22c8c42ded1a766906f88fdb91fd3d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2024-02-02 11:07:43 +00:00
# Add the apple version requirements to the BuildInternals extra code, so the info is
# available when configuring a standalone test.
# Otherwise when QtSetup is included after a
# find_package(Qt6BuildInternals REQUIRED COMPONENTS STANDALONE_TEST)
# call, Qt6ConfigExtras.cmake is not included yet, the requirements are not available and
# _qt_internal_check_apple_sdk_and_xcode_versions() would fail.
_qt_internal_export_apple_sdk_and_xcode_version_requirements(apple_requirements)
if(apple_requirements)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "
${apple_requirements}
")
endif()
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
qt_compute_relative_path_from_cmake_config_dir_to_prefix()
configure_file(
"${CMAKE_CURRENT_LIST_DIR}/QtBuildInternalsExtra.cmake.in"
"${extra_file_path}"
@ONLY
)
endif()
endfunction()
# For every Qt module check if there any android dependencies that require
# processing.
function(qt_modules_process_android_dependencies)
qt_internal_get_qt_repo_known_modules(repo_known_modules)
foreach (target ${repo_known_modules})
CMake: make sure to collect Android dependencies for plugins androiddeployqt relies on *-android-dependencies.xml files to know what dependencies like jar files and permissions a Qt module requires. CMake create those files under Qt prefix's lib dir but CMake was not accounting for module plugins. Fixes: QTBUG-90812 Pick-to: 6.1 6.0 Change-Id: Ib3b2e2bb237159b4851ac0f23dc75f8e56af3f7a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-02-09 22:07:58 +00:00
qt_internal_android_dependencies(${target})
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
endforeach()
endfunction()
function(qt_create_tools_config_files)
# Create packages like Qt6CoreTools/Qt6CoreToolsConfig.cmake.
foreach(module_name ${QT_KNOWN_MODULES_WITH_TOOLS})
qt_export_tools("${module_name}")
endforeach()
endfunction()
function(qt_internal_create_config_file_for_standalone_tests)
set(standalone_tests_config_dir "StandaloneTests")
qt_path_join(config_build_dir
${QT_CONFIG_BUILD_DIR}
"${INSTALL_CMAKE_NAMESPACE}BuildInternals" "${standalone_tests_config_dir}")
qt_path_join(config_install_dir
${QT_CONFIG_INSTALL_DIR}
"${INSTALL_CMAKE_NAMESPACE}BuildInternals" "${standalone_tests_config_dir}")
# Filter out bundled system libraries. Otherwise when looking for their dependencies
# (like PNG for Freetype) FindWrapPNG is searched for during configuration of
# standalone tests, and it can happen that Core or Gui features are not
# imported early enough, which means FindWrapPNG will try to find a system PNG library instead
# of the bundled one.
set(modules)
foreach(m ${QT_REPO_KNOWN_MODULES})
get_target_property(target_type "${m}" TYPE)
# Interface libraries are never bundled system libraries (hopefully).
if(target_type STREQUAL "INTERFACE_LIBRARY")
list(APPEND modules "${m}")
continue()
endif()
CMake: Fix exclusion of QtFoo in QtBarDepends for 3rd party libs When configuring a static Qt with the -qt-zlib option and the build system creates a 3rd party header module QtZlib, syncqt does not generate a QtZlib header file that would include all its public headers. Then when the QtSvgDepends header is generated, it would add an #include <QtZlib> which would break compilation of the QtSvg PCH file (which compiles QtSvgDepends). We have logic to exclude addition of headers from regular 3rd party static libraries, but not header only 3rd party libraries. Adjust the code to handle header-only 3rd party libraries, as well as make sure it works across repos by exporting the relevant properties. As a drive-by, also rename and export some other informational properties. Amends af00402d6446c0f8f085a2a482fc83c4318aa457 Amends 6fdeaea24f9035ad53ba2548a9467b3264cf01ad Amends be2745e4788cecb0d3122081e3328e4b66923609 Pick-to: 6.2 6.3 Change-Id: I087f50b193dd845e4a5ec906e8851d63122faf80 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-02-22 15:57:00 +00:00
get_target_property(is_3rd_party "${m}" _qt_module_is_3rdparty_library)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
if(NOT is_3rd_party)
list(APPEND modules "${m}")
endif()
endforeach()
list(JOIN modules " " QT_REPO_KNOWN_MODULES_STRING)
string(STRIP "${QT_REPO_KNOWN_MODULES_STRING}" QT_REPO_KNOWN_MODULES_STRING)
# Skip generating and installing file if no modules were built. This make sure not to install
# anything when build qtx11extras on macOS for example.
if(NOT QT_REPO_KNOWN_MODULES_STRING)
return()
endif()
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
# Create a Config file that calls find_package on the modules that were built as part
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
# of the current repo. This is used for standalone tests.
CMake: Allow building all examples as standalone just like tests Introduce a new libexec/qt-internal-configure-examples script that allows to configure and build "standalone examples" just like "standalone tests". This is a prerequisite for using deployment api in examples for prefix builds, otherwise deployment api gets confused not finding various information that it expects from an installed qt. Because the various conditions in the build system for standalone examples are similar to standalone tests, introduce a new QT_BUILD_STANDALONE_PARTS variable and use that in the conditions. The variable should not be set by the user, and is instead set by the build system whenever QT_BUILD_STANDALONE_TESTS/EXAMPLES is set. Unfortunately due to no common file being available before the first project() call, in qtbase builds, per-repo builds and top-level builds, we need to duplicate the code for setting QT_BUILD_STANDALONE_PARTS for all three cases. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: Ia40d03a0e8f5142abe5c7cd4ff3000df4a5f7a8a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2024-03-06 16:43:04 +00:00
qt_internal_get_standalone_parts_config_file_name(tests_config_file_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
# Standalone tests Config files should follow the main versioning scheme.
qt_internal_get_package_version_of_target(Platform main_qt_package_version)
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
configure_file(
"${QT_CMAKE_DIR}/QtStandaloneTestsConfig.cmake.in"
CMake: Make standalone tests TestsConfig file repo-target-set specific Conan CI builds can built a qt repository in a repo-target-set configuration. An example of that is qtscxml. When building standalone tests, qt_build_tests includes a repo specific TestsConfig.cmake file to call find_package on the modules that were built as part of that repo. That doesn't quite work with a repo-target-set build which is enabled when the repo is built with a QT_BUILD_SINGLE_REPO_TARGET_SET value. The TestsConfig.cmake file would be overridden with different contents on each configuration. Fix that by including the QT_BUILD_SINGLE_REPO_TARGET_SET value as part of the TestsConfig.cmake file to be generated and included. This means that when configuring the standalone tests, the same QT_BUILD_SINGLE_REPO_TARGET_SET value should be passed, so that the correct packages are found. Add some debug statements to allow checking which TestsConfig.cmake file is loaded when the standalone tests are configured with --log-level=DEBUG. Adjusts to 4b09522c23e9efdf83ba8d4af436d8a700ccb66e Amends de3a806def4b9a754825a2233c9d4952a9b2d0eb Amends e7f188b2d2f10941006be7b0e7197b3c1ebdefdb Pick-to: 6.2 Task-number: QTBUG-96253 Change-Id: I7c22aaad88fe8e6fce23046543363316203f6e8d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-07 16:43:20 +00:00
"${config_build_dir}/${tests_config_file_name}"
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
@ONLY
)
qt_install(FILES
CMake: Make standalone tests TestsConfig file repo-target-set specific Conan CI builds can built a qt repository in a repo-target-set configuration. An example of that is qtscxml. When building standalone tests, qt_build_tests includes a repo specific TestsConfig.cmake file to call find_package on the modules that were built as part of that repo. That doesn't quite work with a repo-target-set build which is enabled when the repo is built with a QT_BUILD_SINGLE_REPO_TARGET_SET value. The TestsConfig.cmake file would be overridden with different contents on each configuration. Fix that by including the QT_BUILD_SINGLE_REPO_TARGET_SET value as part of the TestsConfig.cmake file to be generated and included. This means that when configuring the standalone tests, the same QT_BUILD_SINGLE_REPO_TARGET_SET value should be passed, so that the correct packages are found. Add some debug statements to allow checking which TestsConfig.cmake file is loaded when the standalone tests are configured with --log-level=DEBUG. Adjusts to 4b09522c23e9efdf83ba8d4af436d8a700ccb66e Amends de3a806def4b9a754825a2233c9d4952a9b2d0eb Amends e7f188b2d2f10941006be7b0e7197b3c1ebdefdb Pick-to: 6.2 Task-number: QTBUG-96253 Change-Id: I7c22aaad88fe8e6fce23046543363316203f6e8d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-07 16:43:20 +00:00
"${config_build_dir}/${tests_config_file_name}"
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
endfunction()
function(qt_internal_install_prl_files)
CMake: Install prl files from all repo build dirs in a top-level build Previously, in a top-level build we always generated the final prl file somewhere under QT_BUILD_DIR (which is qtbase_build_dir). After each repo was processed by QtPostProcess.cmake, we installed the prl files found in PROJECT_BINARY_DIR. For qtquickcontrols2 this meant that qml plugin prl files were placed under qtbase/qml, but we tried installing the prl files from qtquickcontrols2/qml, which didn't have any prl files. In a static Qt build, qmake's qt.prf calls qmlimportscanner to identify which plugins should be linked to the executable. This worked fine because the plugin .pri files were installed correctly. None of the qml plugin library dependencies were linked in though. This is supposed to happen in qmake's C++ code where it tries to find the associated prl file of a linked library in order to extract all its dependencies. Because no prl file was found, linking failed with multiple undefined symbols. Fix this by installing the prl files from QT_BUILD_DIR rather than PROJECT_BINARY_DIR. Note that this will create multiple install rules for certain files, but it's harmless. An example is imageformats. We process qtbase plugins, see qjpeg, issue an install rule from under the qtbase/plugins/imageformats folder. We then process qtimageformats plugins, see webp, issue another install rule from under qtbase/plugins/imageformats. The first install rule will install both qjpeg and qwebp, the second install rule will merely say all plugins are up-to-date. Pick-to: 6.1 6.0 Change-Id: I8a4bb67bfafc1d016eab62f4fe66b6ba378ceeb2 Fixes: QTBUG-93021 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-23 16:25:49 +00:00
# Get locations relative to QT_BUILD_DIR from which prl files should be installed.
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
get_property(prl_install_dirs GLOBAL PROPERTY QT_PRL_INSTALL_DIRS)
CMake: Install prl files from all repo build dirs in a top-level build Previously, in a top-level build we always generated the final prl file somewhere under QT_BUILD_DIR (which is qtbase_build_dir). After each repo was processed by QtPostProcess.cmake, we installed the prl files found in PROJECT_BINARY_DIR. For qtquickcontrols2 this meant that qml plugin prl files were placed under qtbase/qml, but we tried installing the prl files from qtquickcontrols2/qml, which didn't have any prl files. In a static Qt build, qmake's qt.prf calls qmlimportscanner to identify which plugins should be linked to the executable. This worked fine because the plugin .pri files were installed correctly. None of the qml plugin library dependencies were linked in though. This is supposed to happen in qmake's C++ code where it tries to find the associated prl file of a linked library in order to extract all its dependencies. Because no prl file was found, linking failed with multiple undefined symbols. Fix this by installing the prl files from QT_BUILD_DIR rather than PROJECT_BINARY_DIR. Note that this will create multiple install rules for certain files, but it's harmless. An example is imageformats. We process qtbase plugins, see qjpeg, issue an install rule from under the qtbase/plugins/imageformats folder. We then process qtimageformats plugins, see webp, issue another install rule from under qtbase/plugins/imageformats. The first install rule will install both qjpeg and qwebp, the second install rule will merely say all plugins are up-to-date. Pick-to: 6.1 6.0 Change-Id: I8a4bb67bfafc1d016eab62f4fe66b6ba378ceeb2 Fixes: QTBUG-93021 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-23 16:25:49 +00:00
# Clear the list of install dirs so the previous values don't pollute the list of install dirs
# for the next repository in a top-level build.
set_property(GLOBAL PROPERTY QT_PRL_INSTALL_DIRS "")
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
foreach(prl_install_dir ${prl_install_dirs})
CMake: Install prl files from all repo build dirs in a top-level build Previously, in a top-level build we always generated the final prl file somewhere under QT_BUILD_DIR (which is qtbase_build_dir). After each repo was processed by QtPostProcess.cmake, we installed the prl files found in PROJECT_BINARY_DIR. For qtquickcontrols2 this meant that qml plugin prl files were placed under qtbase/qml, but we tried installing the prl files from qtquickcontrols2/qml, which didn't have any prl files. In a static Qt build, qmake's qt.prf calls qmlimportscanner to identify which plugins should be linked to the executable. This worked fine because the plugin .pri files were installed correctly. None of the qml plugin library dependencies were linked in though. This is supposed to happen in qmake's C++ code where it tries to find the associated prl file of a linked library in order to extract all its dependencies. Because no prl file was found, linking failed with multiple undefined symbols. Fix this by installing the prl files from QT_BUILD_DIR rather than PROJECT_BINARY_DIR. Note that this will create multiple install rules for certain files, but it's harmless. An example is imageformats. We process qtbase plugins, see qjpeg, issue an install rule from under the qtbase/plugins/imageformats folder. We then process qtimageformats plugins, see webp, issue another install rule from under qtbase/plugins/imageformats. The first install rule will install both qjpeg and qwebp, the second install rule will merely say all plugins are up-to-date. Pick-to: 6.1 6.0 Change-Id: I8a4bb67bfafc1d016eab62f4fe66b6ba378ceeb2 Fixes: QTBUG-93021 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-23 16:25:49 +00:00
qt_install(DIRECTORY "${QT_BUILD_DIR}/${prl_install_dir}/"
CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmake The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 08:24:57 +00:00
DESTINATION ${prl_install_dir}
FILES_MATCHING PATTERN "*.prl"
)
endforeach()
endfunction()
Generate information about user-facing applications in build dir When packaging different Qt versions for Linux distributions (or any distribution with a common bin dir), Qt tools cannot be installed to /usr/bin, because the executable names of the different Qt versions clash. To solve this conflict, our recommendation is to install Qt's tools to /usr/lib/qt6/bin and to create versioned symlinks to user-facing tools in /usr/bin. User-facing tools are tools that are supposed to be started manually by the user. They are marked in Qt's build system. Distro package maintainers can now configure with -DCMAKE_INSTALL_PREFIX=/usr -DINSTALL_BINDIR=/usr/lib/qt6/bin -DINSTALL_PUBLICBINDIR=/usr/bin and will find a file called user_facing_tool_links.txt in the build directory after the cmake run. Nothing will be installed to INSTALL_PUBLICBINDIR. Each line of user_facing_tool_links.txt consists of the installation path of a user-facing application followed by a space and the versioned link name in INSTALL_PUBLICBINDIR. Example content: /usr/lib/qt6/bin/qmake /usr/bin/qmake6 To actually create the versioned symlinks, the content of this file can be fed to ln like this: xargs ln -s < build-dir/user_facing_tool_links.txt Or the package maintainer may decide to do something completely different as suits their needs. This patch adds the USER_FACING argument to qt_internal_add_tool to mark tools as user-facing. In addition, every Qt created by qt_internal_add_app is treated as user-facing. The only tool this patch marks as user-facing in qtbase is qmake. Pick-to: 6.1 Fixes: QTBUG-89170 Change-Id: I52673b1c8d40f40f56a74203065553115e2c4de5 Reviewed-by: Kai Koehne <kai.koehne@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2021-02-11 13:01:58 +00:00
function(qt_internal_generate_user_facing_tools_info)
if("${INSTALL_PUBLICBINDIR}" STREQUAL "")
return()
endif()
Make user tools symlinks relative Fixes: QTBUG-132724 Pick-to: 6.8 6.9 Change-Id: I0f1d95ef6b66c81e2d12730eae3d5c0452a3a7a1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-10 17:28:47 +00:00
qt_path_join(tool_link_base_dir "${CMAKE_INSTALL_PREFIX}" "${INSTALL_PUBLICBINDIR}")
Generate information about user-facing applications in build dir When packaging different Qt versions for Linux distributions (or any distribution with a common bin dir), Qt tools cannot be installed to /usr/bin, because the executable names of the different Qt versions clash. To solve this conflict, our recommendation is to install Qt's tools to /usr/lib/qt6/bin and to create versioned symlinks to user-facing tools in /usr/bin. User-facing tools are tools that are supposed to be started manually by the user. They are marked in Qt's build system. Distro package maintainers can now configure with -DCMAKE_INSTALL_PREFIX=/usr -DINSTALL_BINDIR=/usr/lib/qt6/bin -DINSTALL_PUBLICBINDIR=/usr/bin and will find a file called user_facing_tool_links.txt in the build directory after the cmake run. Nothing will be installed to INSTALL_PUBLICBINDIR. Each line of user_facing_tool_links.txt consists of the installation path of a user-facing application followed by a space and the versioned link name in INSTALL_PUBLICBINDIR. Example content: /usr/lib/qt6/bin/qmake /usr/bin/qmake6 To actually create the versioned symlinks, the content of this file can be fed to ln like this: xargs ln -s < build-dir/user_facing_tool_links.txt Or the package maintainer may decide to do something completely different as suits their needs. This patch adds the USER_FACING argument to qt_internal_add_tool to mark tools as user-facing. In addition, every Qt created by qt_internal_add_app is treated as user-facing. The only tool this patch marks as user-facing in qtbase is qmake. Pick-to: 6.1 Fixes: QTBUG-89170 Change-Id: I52673b1c8d40f40f56a74203065553115e2c4de5 Reviewed-by: Kai Koehne <kai.koehne@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2021-02-11 13:01:58 +00:00
get_property(user_facing_tool_targets GLOBAL PROPERTY QT_USER_FACING_TOOL_TARGETS)
set(lines "")
foreach(target ${user_facing_tool_targets})
get_target_property(filename ${target} OUTPUT_NAME)
if(NOT filename)
set(filename ${target})
endif()
CMake: Fix user_facing_tool_links.txt for Apple platforms User-facing apps that are app bundles on macOS weren't linked correctly. For example, for Qt Designer we're creating now an entry like the following: .../Designer.app/Contents/MacOS/Designer /usr/bin/designer6 Pick-to: 6.6 6.7 Fixes: QTBUG-120487 Change-Id: I3eada15c4c5bf31b9b08829333d3c87f76ede7a2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Kai Köhne <kai.koehne@qt.io>
2024-01-02 20:11:59 +00:00
set(linkname ${filename})
if(APPLE)
get_target_property(is_macos_bundle ${target} MACOSX_BUNDLE )
if(is_macos_bundle)
set(filename "${filename}.app/Contents/MacOS/${filename}")
endif()
endif()
Generate information about user-facing applications in build dir When packaging different Qt versions for Linux distributions (or any distribution with a common bin dir), Qt tools cannot be installed to /usr/bin, because the executable names of the different Qt versions clash. To solve this conflict, our recommendation is to install Qt's tools to /usr/lib/qt6/bin and to create versioned symlinks to user-facing tools in /usr/bin. User-facing tools are tools that are supposed to be started manually by the user. They are marked in Qt's build system. Distro package maintainers can now configure with -DCMAKE_INSTALL_PREFIX=/usr -DINSTALL_BINDIR=/usr/lib/qt6/bin -DINSTALL_PUBLICBINDIR=/usr/bin and will find a file called user_facing_tool_links.txt in the build directory after the cmake run. Nothing will be installed to INSTALL_PUBLICBINDIR. Each line of user_facing_tool_links.txt consists of the installation path of a user-facing application followed by a space and the versioned link name in INSTALL_PUBLICBINDIR. Example content: /usr/lib/qt6/bin/qmake /usr/bin/qmake6 To actually create the versioned symlinks, the content of this file can be fed to ln like this: xargs ln -s < build-dir/user_facing_tool_links.txt Or the package maintainer may decide to do something completely different as suits their needs. This patch adds the USER_FACING argument to qt_internal_add_tool to mark tools as user-facing. In addition, every Qt created by qt_internal_add_app is treated as user-facing. The only tool this patch marks as user-facing in qtbase is qmake. Pick-to: 6.1 Fixes: QTBUG-89170 Change-Id: I52673b1c8d40f40f56a74203065553115e2c4de5 Reviewed-by: Kai Koehne <kai.koehne@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2021-02-11 13:01:58 +00:00
qt_path_join(tool_target_path "${CMAKE_INSTALL_PREFIX}" "${INSTALL_BINDIR}" "${filename}")
CMake: Fix user_facing_tool_links.txt for Apple platforms User-facing apps that are app bundles on macOS weren't linked correctly. For example, for Qt Designer we're creating now an entry like the following: .../Designer.app/Contents/MacOS/Designer /usr/bin/designer6 Pick-to: 6.6 6.7 Fixes: QTBUG-120487 Change-Id: I3eada15c4c5bf31b9b08829333d3c87f76ede7a2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Kai Köhne <kai.koehne@qt.io>
2024-01-02 20:11:59 +00:00
qt_path_join(tool_link_path "${INSTALL_PUBLICBINDIR}" "${linkname}${PROJECT_VERSION_MAJOR}")
Make user tools symlinks relative Fixes: QTBUG-132724 Pick-to: 6.8 6.9 Change-Id: I0f1d95ef6b66c81e2d12730eae3d5c0452a3a7a1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-10 17:28:47 +00:00
_qt_internal_relative_path(tool_target_path BASE_DIRECTORY ${tool_link_base_dir})
Generate information about user-facing applications in build dir When packaging different Qt versions for Linux distributions (or any distribution with a common bin dir), Qt tools cannot be installed to /usr/bin, because the executable names of the different Qt versions clash. To solve this conflict, our recommendation is to install Qt's tools to /usr/lib/qt6/bin and to create versioned symlinks to user-facing tools in /usr/bin. User-facing tools are tools that are supposed to be started manually by the user. They are marked in Qt's build system. Distro package maintainers can now configure with -DCMAKE_INSTALL_PREFIX=/usr -DINSTALL_BINDIR=/usr/lib/qt6/bin -DINSTALL_PUBLICBINDIR=/usr/bin and will find a file called user_facing_tool_links.txt in the build directory after the cmake run. Nothing will be installed to INSTALL_PUBLICBINDIR. Each line of user_facing_tool_links.txt consists of the installation path of a user-facing application followed by a space and the versioned link name in INSTALL_PUBLICBINDIR. Example content: /usr/lib/qt6/bin/qmake /usr/bin/qmake6 To actually create the versioned symlinks, the content of this file can be fed to ln like this: xargs ln -s < build-dir/user_facing_tool_links.txt Or the package maintainer may decide to do something completely different as suits their needs. This patch adds the USER_FACING argument to qt_internal_add_tool to mark tools as user-facing. In addition, every Qt created by qt_internal_add_app is treated as user-facing. The only tool this patch marks as user-facing in qtbase is qmake. Pick-to: 6.1 Fixes: QTBUG-89170 Change-Id: I52673b1c8d40f40f56a74203065553115e2c4de5 Reviewed-by: Kai Koehne <kai.koehne@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2021-02-11 13:01:58 +00:00
list(APPEND lines "${tool_target_path} ${tool_link_path}")
endforeach()
string(REPLACE ";" "\n" content "${lines}")
string(APPEND content "\n")
set(out_file "${PROJECT_BINARY_DIR}/user_facing_tool_links.txt")
file(WRITE "${out_file}" "${content}")
endfunction()