CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously if a target depended on CorePrivate, we would write a
_qt_internal_find_qt_dependencies(... Qt6CorePrivate) call into a
FooDependencies.cmake file.
That find_qt_deps call would remove the 'Private' suffix and would run
find_dependency with NAMES set to both the altered and non-altered
names.
This would find the relevant package but it would set the wrong
_FOUND variable name, e.g it would set Qt6CorePrivate_FOUND instead
of Qt6Core_FOUND.
This in turn could cause multiple lookups of the Qt6Core package
during dependency handling because the correct _FOUND var would not be
set.
Instead of always looking for the Qt6CorePrivate package, make sure
we look for an appropriately named package for all Privates modules,
because we have the necessary info to determine the correct name.
Note that INTERNAL modules will still be looked up via a Private
suffixed package name because that's how the package name is chosen
for them.
Remove the code that accounted for Private modules in
qt_internal_remove_qt_dependency_duplicates because it's not needed
anymore.
Warn when a package name can't be queried from a target's property
because the target might not exist yet.
Add a TODO comment for the code that searches with two NAMES.
We can't remove it right now, because it might break user projects
that use stale Dependencies.cmake files.
The dbus subdirectory is added before the tools subdirectory
to ensure that the new package name extraction does not error out, due
to trying to access a target that does not yet exist.
Amends 425ff34aa1
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ib34ae5ed92f68b4265518c2b8802daeb1a3a04d6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Instead of trying to compute and validate the QT_HOST_PATH and
QT_HOST_PATH_CMAKE_DIR variables in the generated toolchain file,
do it in the Qt6 package.
This provides better error messages when a project is configured
without using the Qt generated toolchain file.
Because it's not done in the toolchain anymore, remove the various
host variables from __qt_toolchain_used_variables.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I1ca239ff83b8f783897e171fee352fc43e8ad7a8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Instead of checking if QT_HOST_PATH is set during user project
configuration to find out if Qt6HostInfo should be looked up,
record if QT_HOST_PATH was provided during Qt configuration
into Qt6Dependencies.cmake and look up the package in a user
project based on that information.
This improves handling of the case where cmake is directly used
to configure a Qt project (instead of qt-cmake), which means no
QT_HOST_PATH might be set by the user, and then cmake would error out
saying that e.g. Qt6CoreTools is not found, instead of saying that
Qt6HostInfo is not found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I0377d5440e4b5b295af73cfd4b5188f61d48e440
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Also replace the duplicate call in QtSetup using the
new function.
To do that, we have to actually the call it in QtBuild
after QtPublicDependencyHelpers.cmake is available.
That call is needed so that Qt6_HOST_INFO_foo variables
are available in qt_generate_qmake_and_qtpaths_wrapper_for_target.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ic5776c214bee6bedcea714b213b0e5a42c1bae06
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When a Qt component or dependency is not found, we will now show a
message that the user can reconfigure the project with
-DQT_DEBUG_FIND_PACKAGE=ON.
If the option is enabled, various variables that find_package uses to
find packages (like CMAKE_PREFIX_PATH, CMAKE_FIND_ROOT_PATH) will be
recorded before each find_package / find_dependency call that is
executed in any of the Qt package files.
If any find_package call fails (a package has its _FOUND variable set
to 0), the values of all those recorded variables will be shown.
This is useful to troubleshoot issues, especially when
cross-compiling, without having to manually modify the various
Config files.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I3654960597911bd704fbe3c419bcae347ab739a9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Depending on CMake version suggest usage of either
--debug-find-pkg or CMAKE_FIND_DEBUG_MODE to help troubleshoot
why dependent packages are not found.
To achieve that, append the hint message to the _NOT_FOUND_MESSAGE.
To ensure it works for qt dependencies, and not only tool and 3rd
party dependencies, _qt_internal_find_qt_dependencies
is modified to set variable names infixed by the target name, so the
name is consistent with the other dependency lookup functions.
The check and message are also added when a Qt6 component is not
found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I4ef23d1c53ac8e04eb72c260d6860c1eeec8d7a3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
So far we always recommended that developers set CMAKE_PREFIX_PATH to
point to the location of the Qt installation so that Qt packages are
found by CMake.
In Qt5 one could also set the Qt5_DIR variable to $qt/lib/cmake/Qt5
to allow the following signature to work:
find_package(Qt5 COMPONENTS Core)
This was not sufficient in Qt6 because the CoreTools dependency would
not be found.
Fix this by also looking into the parent folder of
CMAKE_CURRENT_LIST_DIR as well as _qt_cmake_dir, like we already do
for regular non-Tools packages in _qt_internal_find_dependencies.
Note that setting Qt6_DIR is not sufficient for cross-compilation if
the qt.toolchain.cmake file is not used.
Aside from platform specific options that would have to be passed
manually to CMake (like -DCMAKE_SYSTEM_NAME=iOS for iOS) and
passing a QT_HOST_PATH value, the code would also need to be
adapted to do the necessary CMAKE_FIND_ROOT_PATH manipulations
to ensure that dependent packages are found.
Pick-to: 6.4
Task-number: QTBUG-97615
Change-Id: I10c419632d43bb929e184bab3b9d3d27a35ea87a
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When a package's tools dependency is not found (e.g. Core's CoreTools)
set the _NOT_FOUND_MESSAGE variable the same way that find_dependency
does.
We can't use find_dependency directly because that returns immediately
without allowing us to reset the prefix paths vars.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I81e9817de8f30214fafbefe3d98ef7bc8848e715
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If find_package(Qt6 REQUIRED COMPONENTS Core) is called, don't
propagate the REQUIRED option to all the dependencies of Core,
regardless if it's a 3rd party library, tool or another Qt package
dependency.
Propagating REQUIRED causes the find_dependency -> find_package call
to exit the calling file immediately when the package is not found,
not giving an opportunity for find_dependency to set the
_NOT_FOUND_MESSAGE variable.
Instead force all find_dependency / find_package calls
to be optional, set the calling _FOUND variable to FALSE if the
dependency is not found, also set the _NOT_FOUND_MESSAGE variable.
Then the find_package call that loaded FooModuleConfig.cmake file
will show that message as the reason for the package not being
found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Idcf0b6ed6f6bb38dc082110bbd817b05e287c052
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Aside from moving the code to reduce duplication, the only changes in
the code are the replacement of @target@ to ${target}, using IN LISTS
with variable names to avoid macro expansion issues and replacing
the if(var) conditions with double variable evaluation
+ NOT STREQUAL "".
The function implementations are now in the same order as they
are used in the Dependencies.cmake files.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Iaae926414fd2a7cc09c2f5716376caaa0aade74b
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
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 7bb91398f2
Amends 60c87c6801
Amends 5bbd700124
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>
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>
