AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
550623a8ef
qt5base-lts/cmake/QtModuleDependencies.cmake.in

86 lines
2.7 KiB
CMake
Raw Normal View History

CMake: Fix old style find_package(Qt6Foo) to work Each module package needs to first find the Qt6 package to ensure that all the necessary info is setup for further depedencies to be found. Task-number: QTBUG-81672 Change-Id: I3ee608d24c1efbb63a063261fb36341bf52fb78d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 09:25:47 +00:00
# Make sure @INSTALL_CMAKE_NAMESPACE@ is found before anything else.
find_dependency(@INSTALL_CMAKE_NAMESPACE@ @PROJECT_VERSION@
PATHS "${CMAKE_CURRENT_LIST_DIR}/.." ${QT_EXAMPLES_CMAKE_PREFIX_PATH} NO_DEFAULT_PATH
)
if (NOT @INSTALL_CMAKE_NAMESPACE@_FOUND)
set(@INSTALL_CMAKE_NAMESPACE@@target@_FOUND FALSE)
return()
endif()
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
# note: _third_party_deps example: "ICU\\;1.0\\;i18n uc data;ZLIB\\;\\;"
set(_third_party_deps "@third_party_deps@")
foreach(_target_dep ${_third_party_deps})
list(GET _target_dep 0 pkg)
list(GET _target_dep 1 version)
list(GET _target_dep 2 components)
set(find_package_args "${pkg}")
if(version)
list(APPEND find_package_args "${version}")
endif()
if(components)
Fix building against an installed static Qt For ICU we have multiple components, and ICU becomes a public dependency to QtCore. When storing the INTERFACE_QT_PACKAGE_COMPONENTS property, make sure to store the entire list of components, not just the first component -- by turning the semi-colon separated list into a space separated list. When processing the components at find_dependency time, we need to reverse that and pass COMPONENTS directly to ensure a correct parameter expansion. Change-Id: I24a0708520e7d5fba039395a151034aee4d4c0e2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-25 12:44:29 +00:00
string(REPLACE " " ";" components "${components}")
find_dependency(${find_package_args} COMPONENTS ${components})
else()
find_dependency(${find_package_args})
Write find_dependency() calls in Qt Module config files This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-24 15:14:25 +00:00
endif()
if (NOT ${pkg}_FOUND)
set(@INSTALL_CMAKE_NAMESPACE@@target@_FOUND FALSE)
return()
endif()
endforeach()
Make module package depend on its own tool package Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-29 12:36:25 +00:00
# Find Qt tool package.
set(_tool_deps "@main_module_tool_deps@")
Fix tools dependencies lookup when cross-compiling When the host system uses 64-bits for pointers and the target 32-bits, then locating the tools dependencies would fail due to the mismatch. Since the tools dependencies don't create linkable targets but merely import executables, we can skip this check like in commit 914b367c7f6a117130b8a56338c46a8102a1f77f. Change-Id: I1ebd0867e4cce34f42df21dc8e8d9176a83a9cac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-24 12:56:15 +00:00
CMake: Make it possible to build tools when cross-compiling This patch allows tools to be built for the target platform when the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration time. To avoid naming conflicts, the target tools are suffixed with "_native". The qt_get_tool_target_name() function can be used to get the tool name for both scenarios (cross and non-cross compilation). Extend pro2cmake to refer to the right target name for tools. The relevant write_XXX functions have a new target_ref parameter that will be "${target_name}" for tools and literally the target name for everything else. Fixes: QTBUG-81901 Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-27 13:04:57 +00:00
if(QT_HOST_PATH)
# Make sure that the tools find the host tools first
set(BACKUP_@target@_CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH})
set(BACKUP_@target@_CMAKE_FIND_ROOT_PATH ${CMAKE_FIND_ROOT_PATH})
CMake: Fix handling of CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH While trying to implement the 'host artifact reuse' Coin instructions change, a bug surfaced where the qemu configurations didn't find the host tools and instead tried to use the cross-compiled tools while building qtbase, which failed due to not finding the runtime linker (another unsolved issue). Before the host artifact reuse change, the host tools were found successfully. The difference that caused the issue is that the target install prefix was a direct subfolder of the host prefix. host - /home/qt/work/qt/install target - /home/qt/work/qt/install/target Before the host reuse change the install prefixes were as follows host - /home/qt/work/qt/install/host target - /home/qt/work/qt/install/target While looking for the Qt6CoreTools package, we temporarily set CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH to contain first '/home/qt/work/qt/install' and then '/home/qt/work/qt/install/target'. CMake then reroots the CMAKE_PREFIX_PATH values onto values in CMAKE_FIND_ROOT_PATH, making an MxN list of prefixes to search. Rerooting essentially means concatenating 2 paths, unless the considered prefix is a subfolder of the root path. What happened was that the first considered value was '/home/qt/work/qt/install/home/qt/work/qt/install', a non-existent location that gets discarded. The second considered value was '/home/qt/work/qt/install/target. The second value is the result of seeing that '/home/qt/work/qt/install/target' is a subfolder of '/home/qt/work/qt/install' and thus the root path is stripped. All of this is done in cmFindPackageCommand::FindConfig() -> cmFindCommon::RerootPaths. The behavior above caused the target tools be found instead of the host ones. Before the host reuse change, both of the initial constructed prefixes were discared due to them not existing, e.g. '/home/qt/work/qt/install/target/home/qt/work/qt/install/target' and '/home/qt/work/qt/install/host/home/qt/work/qt/install/host' One of the later prefixes combined CMAKE_FIND_ROOT_PATH == '/home/qt/work/qt/install/host' + CMAKE_PREFIX_PATH == '/' resulting in '/home/qt/work/qt/install/host/' and this accidentally found the host tools package. We actually stumbled upon this issue a while ago when implementing Qt 5.14 Android CMake support in 52c799ed4425076df4353c02950ea1444fe5f102 That commit message mentions the fix is to add a "lib/cmake" suffix to the PATHS option of find_package(). This would cause the subfolder => strip root behavior mentioned above. So finally the fix. First, make sure not to append QT_HOST_PATH in the toolchain file, there shouldn't be any need to do that, give that we temporarily set it when looking for Tools packages. Second, recreate the subdir scenario in the Qt toolchain file by setting CMAKE_FIND_ROOT_PATH to the current (relocated) install prefix as usual, but also setting CMAKE_PREFIX_PATH to a new value poining to the CMake directory. Aka '/home/alex/qt' and '/home/alex/qt/lib/cmake'. Third, when a QT_HOST_PATH is given, save 2 paths in the generated Qt toolchain: QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. There are the host equivalents of the target ones above. Use these values when looking for host tools in Qt6CoreModuleDependencies.cmake, again facilitaing the subdir behavior. Note these are currently absolute paths and are not relocatable. We'll have to figure out if it's even possible to make the host path relocatable. Finally as a cleanup, look for the Qt6HostInfo package in QtSetup strictly in the given QT_HOST_PATH, so CMake doesn't accidentally find a system Qt package. Change-Id: Iefbcfbbcedd35f1c33417ab7e9f44eaf35ff6337 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-21 15:34:40 +00:00
list(PREPEND CMAKE_PREFIX_PATH "${QT_HOST_PATH_CMAKE_DIR}")
CMake: Make it possible to build tools when cross-compiling This patch allows tools to be built for the target platform when the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration time. To avoid naming conflicts, the target tools are suffixed with "_native". The qt_get_tool_target_name() function can be used to get the tool name for both scenarios (cross and non-cross compilation). Extend pro2cmake to refer to the right target name for tools. The relevant write_XXX functions have a new target_ref parameter that will be "${target_name}" for tools and literally the target name for everything else. Fixes: QTBUG-81901 Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-27 13:04:57 +00:00
list(PREPEND CMAKE_FIND_ROOT_PATH "${QT_HOST_PATH}")
endif()
Make module package depend on its own tool package Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-29 12:36:25 +00:00
foreach(_target_dep ${_tool_deps})
list(GET _target_dep 0 pkg)
list(GET _target_dep 1 version)
Fix static usage requirements for XcbQpa In particular, Qt targets extended with other qt targets (eg. Qt::VulkanSupport or Qt::LinuxAccessibilitySupport) after the first add_qt_module were not taken into account when generating Depends files. Note that this patch updates the minimum required version to CMake 3.15 Change-Id: I747deedd4d59e385876bc1a834ef9bdb6078911b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-05 08:08:44 +00:00
find_dependency(${pkg} ${version})
Make module package depend on its own tool package Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-29 12:36:25 +00:00
if (NOT ${pkg}_FOUND)
set(@INSTALL_CMAKE_NAMESPACE@@target@_FOUND FALSE)
CMake: Make it possible to build tools when cross-compiling This patch allows tools to be built for the target platform when the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration time. To avoid naming conflicts, the target tools are suffixed with "_native". The qt_get_tool_target_name() function can be used to get the tool name for both scenarios (cross and non-cross compilation). Extend pro2cmake to refer to the right target name for tools. The relevant write_XXX functions have a new target_ref parameter that will be "${target_name}" for tools and literally the target name for everything else. Fixes: QTBUG-81901 Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-27 13:04:57 +00:00
if(QT_HOST_PATH)
set(CMAKE_PREFIX_PATH ${BACKUP_@target@_CMAKE_PREFIX_PATH})
set(CMAKE_FIND_ROOT_PATH ${BACKUP_@target@_CMAKE_FIND_ROOT_PATH})
endif()
Make module package depend on its own tool package Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-29 12:36:25 +00:00
return()
endif()
endforeach()
CMake: Make it possible to build tools when cross-compiling This patch allows tools to be built for the target platform when the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration time. To avoid naming conflicts, the target tools are suffixed with "_native". The qt_get_tool_target_name() function can be used to get the tool name for both scenarios (cross and non-cross compilation). Extend pro2cmake to refer to the right target name for tools. The relevant write_XXX functions have a new target_ref parameter that will be "${target_name}" for tools and literally the target name for everything else. Fixes: QTBUG-81901 Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-27 13:04:57 +00:00
if(QT_HOST_PATH)
set(CMAKE_PREFIX_PATH ${BACKUP_@target@_CMAKE_PREFIX_PATH})
set(CMAKE_FIND_ROOT_PATH ${BACKUP_@target@_CMAKE_FIND_ROOT_PATH})
endif()
Make module package depend on its own tool package Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-29 12:36:25 +00:00
Merge remote-tracking branch 'origin/wip/qt6' into wip/cmake This changes many different CMake places to mention Qt6 instead of Qt5. Note that some old qt5 cmake config files in corelib are probably not needed anymore, but I still renamed and kept them for now. Change-Id: Ie69e81540386a5af153f76c0242e18d48211bec4
2019-06-14 10:59:07 +00:00
# note: target_deps example: "Qt6Core\;5.12.0;Qt6Gui\;5.12.0"
cmake: move dependencies accumulation in QtPostProcess.cmake This is needed because dependencies added after add_qt_module with extend_target are currently not taken into account. Task-number: QTBUG-75538 Change-Id: I2c72207fb88b2480e41a2c8550978fb194275617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 09:38:41 +00:00
set(_target_deps "@target_deps@")
foreach(_target_dep ${_target_deps})
list(GET _target_dep 0 pkg)
list(GET _target_dep 1 version)
if (NOT ${pkg}_FOUND)
find_dependency(${pkg} ${version}
Fix examples find_package calls to work in prefix builds To build examples as part of a non-installed Qt prefix build, not-yet-installed Config files need to be found by find_package() calls inside example projects. Facilitate that by propagating the CMAKE_PREFIX_PATH and QT_EXAMPLES_CMAKE_PREFIX_PATH paths in all relevant find_package() calls where NO_DEFAULT_PATH is used. Also adjust the inclusion of the QtFeature.cmake file to be relative to the qt6 directory, rather than the current list directory. This is needed to successfully find the file when parsing a Config file from a non-installed build directory. Change-Id: I36031279628f1f7741d8f4d7571484a6545227f7 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-19 11:46:37 +00:00
PATHS "${CMAKE_CURRENT_LIST_DIR}/.." ${QT_EXAMPLES_CMAKE_PREFIX_PATH} NO_DEFAULT_PATH
cmake: move dependencies accumulation in QtPostProcess.cmake This is needed because dependencies added after add_qt_module with extend_target are currently not taken into account. Task-number: QTBUG-75538 Change-Id: I2c72207fb88b2480e41a2c8550978fb194275617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 09:38:41 +00:00
)
endif()
if (NOT ${pkg}_FOUND)
set(@INSTALL_CMAKE_NAMESPACE@@target@_FOUND FALSE)
return()
endif()
endforeach()
CMake: Provide old style CMake variables for target info This change provides the following per-module variables Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS, Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS. These are deprecated and are only intended for easier porting from Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets e.g target_link_libraries(app PRIVATE Qt6::Widgets) Note that the variable contents includes transitive values for everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS will contain values for Widgets, Gui and Core. Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when that is used in target_link_libraries(), CMake will take care of the transitivity. Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-07-14 16:08:07 +00:00
set(_@QT_CMAKE_EXPORT_NAMESPACE@@target@_MODULE_DEPENDENCIES "@qt_module_dependencies@")
cmake: move dependencies accumulation in QtPostProcess.cmake This is needed because dependencies added after add_qt_module with extend_target are currently not taken into account. Task-number: QTBUG-75538 Change-Id: I2c72207fb88b2480e41a2c8550978fb194275617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-03 09:38:41 +00:00
Reference in New Issue Copy Permalink