qt5base-lts/cmake/QtPostProcessHelpers.cmake

814 lines
34 KiB
CMake
Raw Normal View History

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")
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")
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})
# 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.
__qt_internal_strip_target_directory_scope_token("${dep}" dep)
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})
get_target_property(package_is_optional ${dep} INTERFACE_QT_PACKAGE_IS_OPTIONAL)
if(NOT package_is_optional AND dep IN_LIST optional_public_depends)
set(package_is_optional TRUE)
endif()
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()
get_target_property(package_optional_components ${dep}
INTERFACE_QT_PACKAGE_OPTIONAL_COMPONENTS)
if(NOT package_optional_components)
set(package_optional_components "")
endif()
list(APPEND third_party_deps
"${package_name}\;${package_is_optional}\;${package_version}\;${package_components}\;${package_optional_components}")
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 the library depends on the Private and non-Private targets,
# we only need to 'find_dependency' for one of them.
if(dep_seen EQUAL -1 AND "${dep}" MATCHES "(.+)Private\;(.+)")
list(FIND ${out_deps} "${CMAKE_MATCH_1};${CMAKE_MATCH_2}" dep_seen)
endif()
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()
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)
unset(optional_public_depends)
if(TARGET "${target}Private")
get_target_property(optional_public_depends "${target}Private" INTERFACE_LINK_LIBRARIES)
endif()
# 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$")
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()
# 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 "")
# 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()
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"
if (dep MATCHES "(Qt|${QT_CMAKE_EXPORT_NAMESPACE})::([-_A-Za-z0-9]+)")
set(dep "${CMAKE_MATCH_2}")
if (TARGET Qt::${dep})
get_target_property(dep_type Qt::${dep} TYPE)
if (NOT dep_type STREQUAL "INTERFACE_LIBRARY")
get_target_property(skip_module_depends_include Qt::${dep} QT_MODULE_SKIP_DEPENDS_INCLUDE)
if (skip_module_depends_include)
continue()
endif()
else()
get_target_property(is_versionless_target Qt::${dep} _qt_is_versionless_target)
if(is_versionless_target)
get_target_property(module_has_headers ${QT_CMAKE_EXPORT_NAMESPACE}::${dep}
_qt_module_has_headers)
else()
get_target_property(module_has_headers Qt::${dep} _qt_module_has_headers)
endif()
if (NOT module_has_headers)
continue()
endif()
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})
# 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)
list(APPEND tool_deps_seen ${dep})
list(APPEND tool_deps
"${INSTALL_CMAKE_NAMESPACE}${dep}Tools\;${PROJECT_VERSION}")
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)
list(APPEND main_module_tool_deps
"${INSTALL_CMAKE_NAMESPACE}${target}Tools\;${PROJECT_VERSION}")
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}(.+)")
# target_deps cointains elements that are a pair of target name and version,
# 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()
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}")
if (DEFINED qtdeps)
list(REMOVE_DUPLICATES qtdeps)
endif()
get_target_property(hasModuleHeaders "${target}" _qt_module_has_headers)
if (${hasModuleHeaders})
get_target_property(module_include_name "${target}" _qt_module_include_name)
qt_internal_write_depends_file(${target} ${module_include_name} ${qtdeps})
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})
# 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
)
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)
unset(optional_public_depends)
set(target_deps_seen "")
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}")
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}")
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}")
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
)
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)
unset(depends)
unset(optional_public_depends)
# 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()
if(third_party_deps)
# 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()
# This function creates the Qt<Module>Plugins.cmake used to list all
# the plug-in target files.
function(qt_internal_create_plugins_files)
# The plugins cmake configuration is only needed for static builds. Dynamic builds don't need
# the application to link against plugins at build time.
if(QT_BUILD_SHARED_LIBS)
return()
endif()
qt_internal_get_qt_repo_known_modules(repo_known_modules)
message("Generating Plugins files for ${repo_known_modules}...")
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.
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.
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
# Temporarily unset any failure markers.
unset(\${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE)
unset(\${CMAKE_FIND_PACKAGE_NAME}_FOUND)
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()
endif()")
endif()
get_target_property(qt_plugins "${QT_MODULE}" QT_PLUGINS)
if(qt_plugins OR QT_MODULE_PLUGIN_INCLUDES)
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()
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)
# Need to force set, because CMake itself initializes a value for CMAKE_BUILD_TYPE
# at the start of project configuration (with an empty value),
# so we need to force override it.
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(CMAKE_BUILD_TYPE \"${CMAKE_BUILD_TYPE}\" CACHE STRING \"Choose the type of build.\" FORCE)\n")
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
# configuration, rather than default to Debug.
if(multi_config_specific)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "
if(QT_BUILD_STANDALONE_TESTS)
set(CMAKE_BUILD_TYPE \"\${QT_MULTI_CONFIG_FIRST_CONFIG}\" CACHE STRING \"Choose the type of build.\" FORCE)
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()
if(DEFINED QT_UIKIT_SDK)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_UIKIT_SDK \"${QT_UIKIT_SDK}\" CACHE BOOL \"\")\n")
endif()
if(CMAKE_CROSSCOMPILING AND QT_BUILD_TOOLS_WHEN_CROSSCOMPILING)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"set(QT_BUILD_TOOLS_WHEN_CROSSCOMPILING \"TRUE\" CACHE BOOL \"\" FORCE)\n")
endif()
# 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
# 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()
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()
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()
if(NOT "${CMAKE_STAGING_PREFIX}" STREQUAL "")
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS
"
# If no explicit CMAKE_STAGING_PREFIX is provided, force set the original Qt staging prefix,
if(\"$\{CMAKE_STAGING_PREFIX}\" STREQUAL \"\"
AND NOT QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX)
set(CMAKE_STAGING_PREFIX \"${CMAKE_STAGING_PREFIX}\" CACHE PATH
\"Staging path prefix, prepended onto install directories on the host machine.\" FORCE)
endif()
")
endif()
qt_generate_install_prefixes(install_prefix_content)
string(APPEND QT_EXTRA_BUILD_INTERNALS_VARS "${install_prefix_content}")
if(NOT BUILD_SHARED_LIBS)
# 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
"
if(DEFINED QT_REPO_MODULE_VERSION AND NOT DEFINED QT_REPO_DEPENDENCIES AND NOT QT_SUPERBUILD)
qt_internal_read_repo_dependencies(QT_REPO_DEPENDENCIES \"$\{PROJECT_SOURCE_DIR}\")
endif()
")
endif()
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()
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})
qt_internal_android_dependencies(${target})
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()
get_target_property(is_3rd_party "${m}" QT_MODULE_IS_3RDPARTY_LIBRARY)
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()
# Ceate a Config file that calls find_package on the modules that were built as part
# of the current repo. This is used for standalone tests.
qt_internal_get_standalone_tests_config_file_name(tests_config_file_name)
configure_file(
"${QT_CMAKE_DIR}/QtStandaloneTestsConfig.cmake.in"
"${config_build_dir}/${tests_config_file_name}"
@ONLY
)
qt_install(FILES
"${config_build_dir}/${tests_config_file_name}"
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.
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 "")
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}/"
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()