AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7211771c64
qt5base-lts/cmake/QtPostProcessHelpers.cmake

847 lines
36 KiB
CMake
Raw Normal View History

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
function(qt_internal_write_depends_file target module_include_name)
set(outfile "${QT_BUILD_DIR}/include/${module_include_name}/${module_include_name}Depends")
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: 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
foreach(dep ${${depends_var}} ${optional_public_depends} ${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: 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
if(NOT package_is_optional AND dep IN_LIST optional_public_depends)
set(package_is_optional TRUE)
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
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: 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()
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)
get_target_property(target_type "${target}" TYPE)
if(target_type STREQUAL "INTERFACE_LIBRARY")
set(arg_HEADER_MODULE ON)
else()
set(arg_HEADER_MODULE OFF)
endif()
set(depends "")
if(target_type STREQUAL "STATIC_LIBRARY" AND NOT arg_HEADER_MODULE)
get_target_property(depends "${target}" LINK_LIBRARIES)
endif()
get_target_property(public_depends "${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(optional_public_depends)
if(TARGET "${target}Private")
get_target_property(optional_public_depends "${target}Private" INTERFACE_LINK_LIBRARIES)
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 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 "")
if(NOT arg_HEADER_MODULE)
get_target_property(extra_depends "${target}" QT_EXTRA_PACKAGE_DEPENDENCIES)
endif()
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 "")
# 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.
if(NOT arg_HEADER_MODULE)
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})
# 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})
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
get_target_property(module_include_name "${target}" _qt_module_include_name)
qt_internal_write_depends_file(${target} ${module_include_name} ${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)
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(optional_public_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
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)
unset(optional_public_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
# 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})
# 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
"${Qt${PROJECT_VERSION_MAJOR}HostInfo_DIR}/.." ABSOLUTE)
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})
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: Postpone target existence check for qml plugin targets Each included qml Qt6FooPluginTargets.cmake file checks whether all the dependency targets that are referenced in the file already exist by the time the file is included. If one of the referenced targets is missing, the file sets ${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE with a message mentioning which targets are missing and also sets ${CMAKE_FIND_PACKAGE_NAME}_FOUND to FALSE. All our qml package Config.cmake and Targets.cmake files are include()d by Qt6QmlPlugins.cmake using a file(GLOB) which means the order in which the files are loaded is implementation-defined. Furthermore we didn't check the above set variables after each inclusion, which means the values are overridden and the last plugin to be loaded determines whether the Qml package is found or not. If the last included file sets no error, it effectively silences any previously set error. Ever since we added dependencies between the qml plugin targets themselves, we hit the above situation and depending on the platform, no error was shown because the last file overrode any errors. But we finally got a specific platform (wasm) which unearthed the problem (QTBUG-97478). This can happen for any static Qt build though. To fix this properly, we will most likely have to rewrite the whole inclusion mechanism to use find_package() so that dependencies can be resolved recursively as needed. This is a non-trivial change that will have to be addressed in both qtbase and qtdeclarative. In the mean time, a stop-gap solution that this change implements is to include all the files while ignoring any error messages. Then include the files one more time and check for error message after each included file. All qml plugin targets should have been brought into scope with the first round of inclusions, thus circumventing "missing referenced target" errors, while still catching any other possible errors. Amends 6fd1216801f078f65be2cbc748cc459cb6912a4f 9fc302e6d146878103b3d105dce49c7695fcf93a c368175a9e0a0c120b5bb8a0a02859bfc0cf42ba in qtdeclarative. Pick-to: 6.2 6.2.1 Fixes: QTBUG-97478 Task-number: QTBUG-95609 Task-number: QTBUG-97099 Change-Id: I157fa93fc979d726cd221d969b995b3642aeec77 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-13 14:08:45 +00:00
# Qml plugin targets might have dependencies on other qml plugin targets, but the Targets.cmake
# files are included in the order that file(GLOB) returns, which means certain targets that are
# referenced might not have been created yet, and \${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
# might be set to a message saying those targets don't exist.
#
# Postpone checking of which targets don't exist until all Qml PluginConfig.cmake files have been
# included, by including all the files one more time and checking for errors at each step.
#
# TODO: Find a better way to deal with this, perhaps by using find_package() instead of include
# for the Qml PluginConfig.cmake files.
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
file(GLOB __qt_qml_plugins_config_file_list \"\${CMAKE_CURRENT_LIST_DIR}/QmlPlugins/${INSTALL_CMAKE_NAMESPACE}*Config.cmake\")
if (__qt_qml_plugins_config_file_list AND NOT QT_SKIP_AUTO_QML_PLUGIN_INCLUSION)
CMake: Postpone target existence check for qml plugin targets Each included qml Qt6FooPluginTargets.cmake file checks whether all the dependency targets that are referenced in the file already exist by the time the file is included. If one of the referenced targets is missing, the file sets ${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE with a message mentioning which targets are missing and also sets ${CMAKE_FIND_PACKAGE_NAME}_FOUND to FALSE. All our qml package Config.cmake and Targets.cmake files are include()d by Qt6QmlPlugins.cmake using a file(GLOB) which means the order in which the files are loaded is implementation-defined. Furthermore we didn't check the above set variables after each inclusion, which means the values are overridden and the last plugin to be loaded determines whether the Qml package is found or not. If the last included file sets no error, it effectively silences any previously set error. Ever since we added dependencies between the qml plugin targets themselves, we hit the above situation and depending on the platform, no error was shown because the last file overrode any errors. But we finally got a specific platform (wasm) which unearthed the problem (QTBUG-97478). This can happen for any static Qt build though. To fix this properly, we will most likely have to rewrite the whole inclusion mechanism to use find_package() so that dependencies can be resolved recursively as needed. This is a non-trivial change that will have to be addressed in both qtbase and qtdeclarative. In the mean time, a stop-gap solution that this change implements is to include all the files while ignoring any error messages. Then include the files one more time and check for error message after each included file. All qml plugin targets should have been brought into scope with the first round of inclusions, thus circumventing "missing referenced target" errors, while still catching any other possible errors. Amends 6fd1216801f078f65be2cbc748cc459cb6912a4f 9fc302e6d146878103b3d105dce49c7695fcf93a c368175a9e0a0c120b5bb8a0a02859bfc0cf42ba in qtdeclarative. Pick-to: 6.2 6.2.1 Fixes: QTBUG-97478 Task-number: QTBUG-95609 Task-number: QTBUG-97099 Change-Id: I157fa93fc979d726cd221d969b995b3642aeec77 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-13 14:08:45 +00:00
# First round of inclusions ensure all qml plugin targets are brought into scope.
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_qml_plugin_config_file \${__qt_qml_plugins_config_file_list})
include(\${__qt_qml_plugin_config_file})
CMake: Postpone target existence check for qml plugin targets Each included qml Qt6FooPluginTargets.cmake file checks whether all the dependency targets that are referenced in the file already exist by the time the file is included. If one of the referenced targets is missing, the file sets ${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE with a message mentioning which targets are missing and also sets ${CMAKE_FIND_PACKAGE_NAME}_FOUND to FALSE. All our qml package Config.cmake and Targets.cmake files are include()d by Qt6QmlPlugins.cmake using a file(GLOB) which means the order in which the files are loaded is implementation-defined. Furthermore we didn't check the above set variables after each inclusion, which means the values are overridden and the last plugin to be loaded determines whether the Qml package is found or not. If the last included file sets no error, it effectively silences any previously set error. Ever since we added dependencies between the qml plugin targets themselves, we hit the above situation and depending on the platform, no error was shown because the last file overrode any errors. But we finally got a specific platform (wasm) which unearthed the problem (QTBUG-97478). This can happen for any static Qt build though. To fix this properly, we will most likely have to rewrite the whole inclusion mechanism to use find_package() so that dependencies can be resolved recursively as needed. This is a non-trivial change that will have to be addressed in both qtbase and qtdeclarative. In the mean time, a stop-gap solution that this change implements is to include all the files while ignoring any error messages. Then include the files one more time and check for error message after each included file. All qml plugin targets should have been brought into scope with the first round of inclusions, thus circumventing "missing referenced target" errors, while still catching any other possible errors. Amends 6fd1216801f078f65be2cbc748cc459cb6912a4f 9fc302e6d146878103b3d105dce49c7695fcf93a c368175a9e0a0c120b5bb8a0a02859bfc0cf42ba in qtdeclarative. Pick-to: 6.2 6.2.1 Fixes: QTBUG-97478 Task-number: QTBUG-95609 Task-number: QTBUG-97099 Change-Id: I157fa93fc979d726cd221d969b995b3642aeec77 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-13 14:08:45 +00:00
CMake: Don't unset Qt6Qml_FOUND when including Qml plugins Removing the variable would cause nested find_dependency calls of FooQmlPluginDependencies.cmake files to look for the Qml package again and again. If we got to the point of including QmlPlugins.cmake, we already know that the Qml package was found. Set it to TRUE after every inclusion to avoid repeated Qml package loading. The second inclusion pass will ensure to set the found variable to FALSE in case if some dependency is actually missing. Amends aad4158959890b72afdd062614c1142c100c65b5 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I562a1c2ea0abac61453a743ab2e7d2f228de7ff0 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 16:29:22 +00:00
# Temporarily unset any failure markers and mark the Qml package as found.
CMake: Postpone target existence check for qml plugin targets Each included qml Qt6FooPluginTargets.cmake file checks whether all the dependency targets that are referenced in the file already exist by the time the file is included. If one of the referenced targets is missing, the file sets ${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE with a message mentioning which targets are missing and also sets ${CMAKE_FIND_PACKAGE_NAME}_FOUND to FALSE. All our qml package Config.cmake and Targets.cmake files are include()d by Qt6QmlPlugins.cmake using a file(GLOB) which means the order in which the files are loaded is implementation-defined. Furthermore we didn't check the above set variables after each inclusion, which means the values are overridden and the last plugin to be loaded determines whether the Qml package is found or not. If the last included file sets no error, it effectively silences any previously set error. Ever since we added dependencies between the qml plugin targets themselves, we hit the above situation and depending on the platform, no error was shown because the last file overrode any errors. But we finally got a specific platform (wasm) which unearthed the problem (QTBUG-97478). This can happen for any static Qt build though. To fix this properly, we will most likely have to rewrite the whole inclusion mechanism to use find_package() so that dependencies can be resolved recursively as needed. This is a non-trivial change that will have to be addressed in both qtbase and qtdeclarative. In the mean time, a stop-gap solution that this change implements is to include all the files while ignoring any error messages. Then include the files one more time and check for error message after each included file. All qml plugin targets should have been brought into scope with the first round of inclusions, thus circumventing "missing referenced target" errors, while still catching any other possible errors. Amends 6fd1216801f078f65be2cbc748cc459cb6912a4f 9fc302e6d146878103b3d105dce49c7695fcf93a c368175a9e0a0c120b5bb8a0a02859bfc0cf42ba in qtdeclarative. Pick-to: 6.2 6.2.1 Fixes: QTBUG-97478 Task-number: QTBUG-95609 Task-number: QTBUG-97099 Change-Id: I157fa93fc979d726cd221d969b995b3642aeec77 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-13 14:08:45 +00:00
unset(\${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE)
CMake: Don't unset Qt6Qml_FOUND when including Qml plugins Removing the variable would cause nested find_dependency calls of FooQmlPluginDependencies.cmake files to look for the Qml package again and again. If we got to the point of including QmlPlugins.cmake, we already know that the Qml package was found. Set it to TRUE after every inclusion to avoid repeated Qml package loading. The second inclusion pass will ensure to set the found variable to FALSE in case if some dependency is actually missing. Amends aad4158959890b72afdd062614c1142c100c65b5 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I562a1c2ea0abac61453a743ab2e7d2f228de7ff0 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 16:29:22 +00:00
set(\${CMAKE_FIND_PACKAGE_NAME}_FOUND 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
endforeach()
CMake: Postpone target existence check for qml plugin targets Each included qml Qt6FooPluginTargets.cmake file checks whether all the dependency targets that are referenced in the file already exist by the time the file is included. If one of the referenced targets is missing, the file sets ${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE with a message mentioning which targets are missing and also sets ${CMAKE_FIND_PACKAGE_NAME}_FOUND to FALSE. All our qml package Config.cmake and Targets.cmake files are include()d by Qt6QmlPlugins.cmake using a file(GLOB) which means the order in which the files are loaded is implementation-defined. Furthermore we didn't check the above set variables after each inclusion, which means the values are overridden and the last plugin to be loaded determines whether the Qml package is found or not. If the last included file sets no error, it effectively silences any previously set error. Ever since we added dependencies between the qml plugin targets themselves, we hit the above situation and depending on the platform, no error was shown because the last file overrode any errors. But we finally got a specific platform (wasm) which unearthed the problem (QTBUG-97478). This can happen for any static Qt build though. To fix this properly, we will most likely have to rewrite the whole inclusion mechanism to use find_package() so that dependencies can be resolved recursively as needed. This is a non-trivial change that will have to be addressed in both qtbase and qtdeclarative. In the mean time, a stop-gap solution that this change implements is to include all the files while ignoring any error messages. Then include the files one more time and check for error message after each included file. All qml plugin targets should have been brought into scope with the first round of inclusions, thus circumventing "missing referenced target" errors, while still catching any other possible errors. Amends 6fd1216801f078f65be2cbc748cc459cb6912a4f 9fc302e6d146878103b3d105dce49c7695fcf93a c368175a9e0a0c120b5bb8a0a02859bfc0cf42ba in qtdeclarative. Pick-to: 6.2 6.2.1 Fixes: QTBUG-97478 Task-number: QTBUG-95609 Task-number: QTBUG-97099 Change-Id: I157fa93fc979d726cd221d969b995b3642aeec77 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-10-13 14:08:45 +00:00
# For the second round of inclusions, check and bail out early if there are errors.
foreach(__qt_qml_plugin_config_file \${__qt_qml_plugins_config_file_list})
include(\${__qt_qml_plugin_config_file})
if(\${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE)
string(APPEND \${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
\"\nThe message was set in \${__qt_qml_plugin_config_file} \")
set(\${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
return()
endif()
endforeach()
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()
Fix loading of Qt6*Plugin.cmake files of per-repo builds When doing a per-repository build of Qt, as it is done for the installer packages, the build of qtbase has no knowledge of plugins that might be built and installed from other repositories. That means we must not write a fixed list of known plugins when exporting Qt modules of qtbase. In particular, qtsvg adds imageformat plugins that are supposed to be picked up by qtbase's QtGui module when linking a project against a statically linked Qt. ${install-prefix}/lib/cmake/Qt6Gui/Qt6GuiPlugins.cmake missed the include statements for qtsvg's plugin config files and operated on a fixed list of plugins, all from qtbase. Apart from that, the Qt6::Gui target's property QT_PLUGINS did only contain the qtbase plugins. This patch fixes the situation in the following way: 1. All Qt6*PluginConfig.cmake files in ${install-prefix}/lib/cmake/Qt6Gui are detected and included. 2. From those file names, the target names of the plugins are deduced. This is safe as the file name of those generated files is a direct result of the plugin's target name. 3. The QT_PLUGINS property of the module is updated with the detected plugin target names. Fixes: QTBUG-89643 Change-Id: Ifc3c39aa9948277ead5ebb209ec5eff64746308b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-01-07 15:55:51 +00:00
get_target_property(qt_plugins "${QT_MODULE}" QT_PLUGINS)
if(qt_plugins 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
INSTALL_DESCRIPTIONSDIR)
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
"
set(__qt_internal_initial_qt_cmake_build_type \"${CMAKE_BUILD_TYPE}\")
qt_internal_force_set_cmake_build_type_conditionally(
\"\${__qt_internal_initial_qt_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()
# When building standalone tests against a multi-config Qt, we want to choose the first
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
# configuration, rather than use CMake's default value.
# In the case of Windows, we definitely don't it to default to Debug, because that causes
# issues in the CI.
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(multi_config_specific)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "
if(QT_BUILD_STANDALONE_TESTS)
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
qt_internal_force_set_cmake_build_type_conditionally(
\"\${QT_MULTI_CONFIG_FIRST_CONFIG}\")
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")
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: 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
if(DEFINED QT_UIKIT_SDK)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_UIKIT_SDK \"${QT_UIKIT_SDK}\" CACHE BOOL \"\")\n")
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.
# Used by qtwayland/src/plugins/platforms/qwayland-generic/CMakeLists.txt. Otherwise
# the DEFAULT_IF condition is evaluated incorrectly.
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()
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()
# 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)
set(FEATURE_pkg_config \"${FEATURE_pkg_config}\" CACHE STRING \"Using pkg-config\" FORCE)
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}")
CMake: Don't create duplicate plugin targets in shared builds when building Qt repositories. When building for example qtquick3d, the Qt6QmlPlugins.cmake file should not load the qtquick3d specific plugin config files because the targets will be created as part of the build and cause duplicate errors. We already did it for static builds, but now we also do it for shared builds. Amends 7d6f1ee5a75cae9d122a3f0c7b3a6d03f380535e Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25 Pick-to: 6.4 Task-number: QTBUG-94066 Change-Id: I66ca71dfa6485eded94c1ecb5eb3b23daf908b39 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-08 09:35:25 +00:00
# The top-level check needs to happen inside QtBuildInternals, because it's possible
# to configure a top-level build with a few repos and then configure another repo
# using qt-configure-module in a separate build dir, where QT_SUPERBUILD will not
# be set anymore.
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"
CMake: Fix reconfiguration when using a static top-level build ... and configuring another repo using qt-configure-module. It's possible to configure a top-level Qt with a subset of repos and then afterwards configure additional repos with qt-configure-module. We didn't define QT_REPO_DEPENDENCIES in that case, which caused all plugin config files to be loaded on reconfiguration, thus causing duplicate target errors. Move the QT_SUPERBUILD check to be done every time in QtBuildInternals.cmake rather than when configuring qtbase/qt5. Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25 Pick-to: 6.1 Fixes: QTBUG-86670 Fixes: QTBUG-91887 Fixes: QTBUG-92578 Change-Id: I975835ffa02f702799a3c9f68a5e059d2763a951 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-29 14:55:16 +00:00
if(DEFINED QT_REPO_MODULE_VERSION AND NOT DEFINED QT_REPO_DEPENDENCIES AND NOT QT_SUPERBUILD)
Fix error when re-configuring an already installed Qt repository When building and installing a Qt repo that provides plugins for a Qt module within a different repository (for example, qtimageformats providing imageformat plugins for QtGui), re-configuring that repository would result in configuration errors like "add_library cannot create ALIAS target "Qt6::QTgaPlugin" because another target with the same name already exists." This happened, because the find_package(Qt6 COMPONENTS Gui) calls pulled in the Qt6*PluginConfig.cmake files that create imported targets for the plugins we want to build. To fix this, when building Qt, we now load only plugins that are provided by repositories the currently building repository depends on. We read the repo dependencies from dependencies.yaml when the Qt6BuildInternals package is loaded, but only in static builds and only if we're currently building a Qt repository. To find out whether we're building a Qt repository, we check whether QT_REPO_MODULE_VERSION is defined. We cannot check QT_BUILDING_QT, because that variable is not available for the first find_package calls in the repository's top-level project file. In each Qt6*PluginConfig.cmake file, we bail out if the plugin's repository is not one of the ones in QT_REPO_DEPENDENCIES. Fixes: QTBUG-86670 Fixes: QTBUG-91887 Change-Id: I8f6c8398032227032742f1ca019e983ff2bcd745 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-22 19:43:25 +00:00
qt_internal_read_repo_dependencies(QT_REPO_DEPENDENCIES \"$\{PROJECT_SOURCE_DIR}\")
endif()
")
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()
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: 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
qt_internal_get_standalone_tests_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()
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()
qt_path_join(tool_target_path "${CMAKE_INSTALL_PREFIX}" "${INSTALL_BINDIR}" "${filename}")
qt_path_join(tool_link_path "${INSTALL_PUBLICBINDIR}" "${filename}${PROJECT_VERSION_MAJOR}")
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()
Reference in New Issue Copy Permalink