summaryrefslogtreecommitdiffstats
path: root/cmake/QtModuleDependencies.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-buildsAlexandru Croitor2021-08-191-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Don't backup cmake prefix when there are no tool dependenciesAlexandru Croitor2021-08-191-2/+2
| | | | | | | | | This is just a minor optimization. Pick-to: 6.2 Change-Id: Icf0fc615895e1def63c57a72694c89f7ae7ee5cf Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Use namespaced variables in Qt6*Dependencies.cmakeLi Xinwei2021-07-241-32/+32
| | | | | | | Pick-to: 6.2 6.1 Change-Id: I166988020cfd9750a4d58e519742215d0c03ad3e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Move dependency lookup functionality to the common macroAlexey Edelev2021-06-191-25/+3
| | | | | | | | | | Dependency lookup mechanism is the same for modules and plugins. It makes sense to wrap it using macro. Pick-to: 6.2 Change-Id: I73727743b0f5f40b2d94624f65ebfcf85e8dcc59 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Handle OPTIONAL_COMPONENTS in qt_find_packageAlexandru Croitor2021-06-171-0/+5
| | | | | | | | | | | | | | | | | | The optional components arguments were not handled before which caused the recorded package information for static builds to be incorrect, it only recorded the package name without the component. Remove REQUIRED_COMPONENTS TODO, there is no such find_package option, it's already handled by the regular COMPONENTS code path. Amends 07b6d3367debd8f15974abf0f5cdf48f0fe3a536 Pick-to: 6.1 6.2 Fixes: QTBUG-94501 Change-Id: Ib48a7befcb70e20c3f21315897d51d3064b48134 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Dominik Holland <dominik.holland@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Merge main and private targets of the internal modulesAlexey Edelev2021-05-201-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: use additional search paths also for tool packageSamuli Piippo2021-05-101-1/+5
| | | | | | | | | | Use paths configured with QT_ADDITIONAL_PACKAGES_PREFIX_PATH to search also for the tool packages. Task-number: QTBUG-93565 Pick-to: 6.1 Change-Id: I611b275dd7c4e7ecceb073d16643cd225bbb21d8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Improve support for QT_ADDITIONAL_PACKAGES_PREFIX_PATHKai Köhne2021-03-031-2/+4
| | | | | | | | | | | | | | | | | | | Allow to set QT_ADDITIONAL_PACKAGES_PREFIX_PATH as both an env variable and CMake cache variable. Also normalize path and list separators, so that they can be used similar to CMAKE_PREFIX_PATH. The environment variable is intended to be set by the conan virtualenv generator, so that e.g. find_package(Qt6 COMPONENTS NetworkAuth REQUIRED) also works if NetworkAuth is not installed into the Qt prefix. Pick-to: 6.1 Fixes: QTBUG-91142 Change-Id: Ia9f9b9fa2b1b051d33073629139640d0f4c7a843 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io>
* CMake: Use host variables instead of hardcoded directoriesAlexey Edelev2020-12-211-3/+3
| | | | | | | | | | | | | | | | | | | 'QT_HOST_PATH' indicates that we use crosscompilation toolchain to build project. In this case 'Qt6Config.cmake' loads 'Qt6HostInfoConfig.cmake' from host QT_HOST_PATH, that defines correct paths to host tools. Replace hardcoded paths for host tools by paths recorded in Qt6HostInfoConfig.cmake. Correct conditions for QT_HOST_PATH, evaluate it explicitly as string, but not as boolean expression. Fixes: QTBUG-86557 Pick-to: 6.0 Change-Id: Ib52bbd32478051d019a932dcb1f735e2d4aacfbf Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow finding Qt CMake packages in additional locationsAlexandru Croitor2020-09-281-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By default, when using the Qt6 CMake package to look for components, the find_package() calls for the components use NO_DEFAULT_PATH to ensure that CMake doesn't accidentally find system (distro) packages. Instead we limit the paths to one level up from where the Qt6 package is. Unfortunately that doesn't quite work for finding Qt packages that might have been installed into a different prefix than where the main Qt prefix is. This happens when Qt addons are built by Conan, and installed into a separate prefix. To allow calls like find_package(Qt6 COMPONENTS ConanAddon) to work in a scenario as described above, introduce a new variable called QT_ADDITIONAL_PACKAGES_PREFIX_PATH which can be used to specify additional paths where Qt CMake packages should be found. This is similar to previously introduced QT_EXAMPLES_CMAKE_PREFIX_PATH variable which was meant for a similar case, but only for examples. Additionally, allow disabling the NO_DEFAULT_PATH option by setting the QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES cache variable to TRUE. This would allow regular usage of CMAKE_PREFIX_PATH to work, at the risk that system Qt CMake packages might be found. Augments 5cd4001bf2a7f0894c6ac269860e833b02df6cde and ffe088941378e32ea30c142cca7e63c537a41ff1. Fixes: QTBUG-86882 Change-Id: Ia8e060cbba6d2a10c3d63d81892f2c71e4236a9a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Revert "Revert "CMake: Add facility to mark package dependencies as optional""Joerg Bornemann2020-09-141-4/+12
| | | | | | | | | This reverts commit b0c51f86f40b6b6d18fe2bb75cc851d36395240d. The build failure caused by 58c1c6ee5c986d502b56eb1cc57f1d9444d42031 has been fixed. Change-Id: Ic7458d54c7a874588e8b1bfeca61df1842763656 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Revert "Revert "CMake: Reduce the number of find_dependency calls""Joerg Bornemann2020-09-141-4/+3
| | | | | | | | | This reverts commit 6e1a570dc8560489d10120cbd019a665f33f49c2. The build failure caused by 58c1c6ee5c986d502b56eb1cc57f1d9444d42031 has been fixed. Change-Id: I67acaa2d1dd5fc88c205b054252be2e6e26898c7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Revert "Revert "CMake: Fix usage of find_dependency()""Joerg Bornemann2020-09-141-18/+10
| | | | | | | | ...and fix the build errors the original change caused. This reverts commit 127fb8bb5587db52216d0ac934f3111170a7cbe3. Change-Id: I4006b32734a51c5d101dd73c957f81d2a0f84ba1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Revert "CMake: Fix usage of find_dependency()"Lars Knoll2020-09-131-10/+18
| | | | | | | | | | This reverts commit 58c1c6ee5c986d502b56eb1cc57f1d9444d42031. This lead to configuration errors on some machines, blocking development. Change-Id: I744f6cc95fbaa273519ab8fc8fb492b87f5729b8 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Revert "CMake: Reduce the number of find_dependency calls"Lars Knoll2020-09-131-3/+4
| | | | | | | | | | This reverts commit a3cb002511d7e2cc73234611795c1947620aedd5. This lead to configuration errors on some machines, blocking development. Change-Id: Ibb785c96c7d85692a6e22a73e086119eb571df71 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Revert "CMake: Add facility to mark package dependencies as optional"Lars Knoll2020-09-131-12/+4
| | | | | | | | | | This reverts commit 3685483c4b79b4075bab6d341174a395359d1b4a. This lead to configuration errors on some machines, blocking development. Change-Id: I309cdd55a8ef64899afcbeca54458d1c6d686951 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* CMake: Add facility to mark package dependencies as optionalJoerg Bornemann2020-09-121-4/+12
| | | | | | | | | | | | | | | | Every public dependency of a Qt module results in a find_package call in the consuming project. But not all public dependencies are mandatory. For example, vulkan is only needed if the user project actually uses Qt classes that pull in vulkan headers. This patch adds the option MARK_OPTIONAL to qt_find_package. Dependencies that are marked as optional will not produce an error on find failure. Task-number: QTBUG-86421 Change-Id: Ia767e7f36991e236582c7509cbd37ea3487bb695 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Reduce the number of find_dependency callsJoerg Bornemann2020-09-121-4/+3
| | | | | | | | | | ...in code. The actual number of calls at runtime does not change. The reason for this stunt is that we want to replace find_dependency with find_package at runtime for optional dependencies, and this will reduce the diff size of the next commit. Change-Id: I304fdf09c69fea7b6d4adabf515712eb097f8c86 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix usage of find_dependency()Joerg Bornemann2020-09-121-18/+10
| | | | | | | | | | | | The find_dependency() macro calls return() on failure, meaning any code after it will be ignored, thus checking any XXX_FOUND variables after find_dependency() is pointless. Fix the places where we use find_dependency() and set the "failed" state before the call and the "success" state afterwards. Change-Id: Ia5239c704f02a9bec972210374ffed7808b14055 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix empty value of CMAKE_SIZEOF_VOID_P when looking for toolsAlexandru Croitor2020-08-131-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our initial approach to looking for host Qt tools when cross-compiling to a platform with a different architecture bitness compared to the host one was to unset CMAKE_SIZEOF_VOID_P before calling find_package(Qt6FooTools) and then restoring the value. That works to bypass the architecture bitness test in the ConfigVersion files, but it also influences the paths that find_package() searches in, specifically the lib<arch> paths like /usr/lib64 will not be searched in. Fortunately since CMake 3.14, write_basic_package_version_file() can take an additional ARCH_INDEPENDENT parameter. This disables the architecture bitness test when looking for the package, while allowing to still search in the /usr/lib64 like paths. Use it when creating the QtFooToolConfigVersion.cmake files. One could argue we should actually check if the tool executables could run on the host system where find_package is called for cross-compilation. We could do that in another change if the problem ever arises. Amends 03aa74e40d8f1270e1bb28d0791e5bc376ffa0b7 Amends 914b367c7f6a117130b8a56338c46a8102a1f77f Change-Id: I1181ff637ac80064a6a8538170b28a41743fc90c Fixes: QTBUG-81672 Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix handling of CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATHAlexandru Croitor2020-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Provide old style CMake variables for target infoAlexandru Croitor2020-07-171-0/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Fix old style find_package(Qt6Foo) to workAlexandru Croitor2020-07-171-0/+9
| | | | | | | | | | 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>
* CMake: Make it possible to build tools when cross-compilingLeander Beernaert2020-06-021-3/+19
| | | | | | | | | | | | | | | | | | | 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>
* Always append extra cmake modules to CMAKE_MODULE_PATH in Qt6ConfigAlexandru Croitor2019-10-011-10/+0
| | | | | | | | | | | | | | | | | | | | | | During a static build we need to use the find modules in 3rdparty/extra-cmake-modules/find-modules when generating a ModuleDependencies file, so that the generated find_dependency() calls succeed. This means that the files have to be shipped with Qt6 package, making them pseudo public API. There is also a need to use these files when building QtWayland. Instead of setting / unsetting CMAKE_MODULE_PATH only in module and plugin Dependencies cmake files, just set them once when finding Qt6. This will allow QtWayland and QtX11Extras to easily find the required third party packages, without having to hardcode the paths in multiple repos. Change-Id: I750d0421a269e5632afa1bb62498c2501d73cdb1 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix examples find_package calls to work in prefix buildsAlexandru Croitor2019-09-211-1/+1
| | | | | | | | | | | | | | | | | | | 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>
* Fix building against an installed static QtSimon Hausmann2019-06-251-3/+4
| | | | | | | | | | | | | | | | 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>
* Fix tools dependencies lookup when cross-compilingSimon Hausmann2019-06-241-0/+8
| | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/wip/qt6' into wip/cmakeAlexandru Croitor2019-06-141-1/+1
| | | | | | | | | | 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
* Fix static usage requirements for XcbQpaJean-Michaël Celerier2019-06-051-6/+2
| | | | | | | | | | | | | 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>
* cmake: register plug-ins, create dependencies fileJean-Michaël Celerier2019-06-041-0/+1
| | | | | | | | This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: move dependencies accumulation in QtPostProcess.cmakeJean-Michaël Celerier2019-05-031-0/+19
| | | | | | | | | 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>
* Make module package depend on its own tool packageAlexandru Croitor2019-05-021-0/+17
| | | | | | | | | | | | | | | | | | | | 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>
* Write find_dependency() calls in Qt Module config filesAlexandru Croitor2019-05-021-0/+34
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-27 19:18:46 +0000