...in _qt_internal_find_qt_dependencies. In the case where a package is
loaded via its own dependencies (Qt6FooPrivate -> Qt6Foo ->
Qt6FooPrivate) the inner _qt_internal_find_qt_dependencies call did
unset the backup value of QT_NO_PRIVATE_MODULE_WARNING. This could lead
to an unwanted display of the private module warning.
Treat the backup variable as a stack to deal with this situation.
Pick-to: 6.9
Change-Id: I0ee3700a040b0df8c6090470ea6fc515cb93a7d6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Avoid hardcoding the HostInfo package version, use the
INSTALL_CMAKE_NAMESPACE as the reference for the find_package calls.
If we assume that the package follows the versioning in the future,
we should consider the Qt version, to avoid any version related
issues.
Pick-to: 6.5 6.8 6.9
Change-Id: If84550ab82f8de51ff5af41c7f31838c4ed53a67
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If users set QT_FIND_PRIVATE_MODULES we may assume that they know
what they are doing and it's the conscious decision, and the
Private module warning is not needed.
Ammends a9f26c3f9a9eb6758e3ef116e319a6cca8715a1c
Change-Id: I2d7bf86060b87365bda0a8355427c52b1b38c456
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If a private module package is pulled in by another Qt module we showed
the private module warning message. The user couldn't act on the warning
other than disabling it completely. This doesn't seem useful.
Now, we only show the warning if the user explicitly does
find_package(Qt6FooPrivate).
There's the situation where a private module is pulled in as dependency
and later pulled in by the user. For example, in a static Linux build
find_package(Qt6 REQUIRED COMPONENTS Gui CorePrivate)
will pull in CorePrivate as transitive dependency of Gui's plugins.
To still see a warning for CorePrivate in this case we need to trigger
the warning in Qt6Config.cmake when handling the COMPONENTS.
To achieve that, the warning code has been moved to a function which is
called in Qt6Config.cmake and Qt6FooPrivateConfig.cmake
Task-number: QTBUG-87776
Change-Id: Ie9cc2d287d1fcb94db77045165f703cebcb6983d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...that tried to load Qt6Foo instead of Qt6FooPrivate. This might now
load the wrong package, since we've split CMake packages of public and
private Qt modules.
Enough time has passed, and we can assume that all
Qt6*Dependencies.cmake files have the _qt_package_name property set by
now.
Pick-to: 6.9
Task-number: QTBUG-87776
Change-Id: Icf18872dd49b1e3a82b7327027f7d6e48b656b70
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Set __qt_${target}_find_package_args once per the
_qt_internal_find_tool_dependencies call. It doesn't make sense to call
set it in loop, since variable doesn't depend on loop parameters.
Pick-to: 6.5 6.8 6.9
Change-Id: Ia1024625b870364a1db8e07f61bf7ea6ab4e9f84
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The plugin lookup mechanism doesn't handle the situation, when the
plugin is available but it's private dependency(static plugin case)
is missing. In this case we currently silently bypass the dependency
lookup and create targets. So users see the confusing message about
missing linked target, like:
Qt6QSQLiteDriverPluginTargets.cmake:61 (set_target_properties):
The link interface of target "Qt6::QSQLiteDriverPlugin" contains:
SQLite::SQLite3
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
This indeed should be handled properly and we should omit creating
targets especially if users don't really use the plugin directly.
Also if dependencies are not satisfied it looks logically to set
the <plugin>_FOUND to false as this will be yet another indicator
for user that the plugin is not found.
Task-number: QTBUG-132244
Pick-to: 6.8 6.9 6.5
Change-Id: I8685163df0dee3a728c724901f69780569ffcad5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Clean up the dead code according to TODO statement.
Pick-to: 6.8 6.9
Change-Id: I9bdf10067d3a1324d584cebc51cf4555f00f717a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
A developer can cross-compile Qt and force the build of the tools
for the target architecture. In this case, the resulting Qt libraries
and tools can theoretically be used as an SDK on the target platform
without having to rely on host tools or packages.
Examples of this scenario include Boot2Qt, cross-building a Qt SDK for
a raspberry pi on a more powerful machine, or cross-building an arm64
macOS SDK on an x86_64 machine.
To achieve that, the build system needs a way of disabling the
mandatory host path check and the lookup of the Qt6HostInfo package
that are added due to the nature of 'usual' cross-compilation cases.
This was partially addressed in
0f8017efb6d037c4f33f947eb3c56aeafa28313c by offering an opt out via
the QT_REQUIRE_HOST_PATH_CHECK and QT_NO_REQUIRE_HOST_PATH_CHECK
variables.
The change was incomplete though. While it was possible to disable
the _qt_internal_setup_qt_host_path call at user project time, it was
not possible to disable the lookup of the required Qt6HostInfo
package in _qt_internal_find_host_info_package.
Change the code to consider the value of QT_REQUIRE_HOST_PATH_CHECK
also when looking up the Qt6HostInfo package in Qt6Dependencies.cmake
in user projects.
When building additional Qt repos, as opposed to user projects,
where we call _qt_internal_find_host_info_package in
qt_internal_setup_find_host_info_package via the BuildInternals
package, users will still need to pass both QT_REQUIRE_HOST_PATH_CHECK
and QT_NO_REQUIRE_HOST_PATH_CHECK to disable the host path check.
This case is less likely to happen, so no adjustment is made to unify
that behavior.
Additionally make it also possible to use an environment variable
as an opt-out with the same QT_REQUIRE_HOST_PATH_CHECK name.
Amends 0f8017efb6d037c4f33f947eb3c56aeafa28313c
Pick-to: 6.8
Change-Id: I3b1f35d1540493680323330bddc28c65e88b966f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Backstory.
The main reason why we keep getting "unable to promote 3rd party 'X'
target to global scope" errors when building Qt repositories, is
because we try to promote 3rd party imported targets in a different
scope than where the imported targets were created.
What were the main motivations for promoting 3rd party targets to
global?
1) imported targets are by default local to the directory scope they
were created in
2) we want 3rd party targets to be accessible across subdirectory
scopes, but looked up once, e.g. qt_find_package(JPEG) looked up in
src/gui/CMakeLists.txt, but the target should also be usable in the
sibling scope
src/plugins/imageformats/CMakeLists.txt
Having the package lookup close to the consuming qt module is easier
to maintain, because all the other 3rd party dependency lookups are
in the same file. This goes against the conventional CMake advice
where each subdirectory should look for its own dependencies, or the
dependency should be available directly in the root project scope.
3) to make the 3rd party targets available in the root project scope
as part of the following flow:
QtPostProcess.cmake ->
qt_internal_create_module_depends_file() ->
qt_collect_third_party_deps() ->
get_property(INTERFACE_QT_PACKAGE_NAME) ->
write 3rd party Dependencies.cmake file for each qt module.
Properties can only be queried from an imported target if it's in
the same scope or was promoted to global, otherwise you get
'non-existent target' errors.
4) for prl and pri file generation, where we need the targets to be
available during generator expression evaluation within the
relevant qt module directory scope
Here is a list of approaches I came up with on how to improve the
situation.
1) Make all imported targets global during the Qt build, by iterating
over the directory property IMPORTED_TARGETS and making each one
global.
Requires CMake 3.21.
Status: Already implemented for a long time, but is opt-in.
Pros: Relatively robust
Cons: Minimum CMake version for building Qt is 3.16.
2) Make all imported targets global during the Qt build using the
CMAKE_FIND_PACKAGE_TARGETS_GLOBAL variable.
Requires CMake 3.24.
Status: Not implemented, but can be set by Qt builders directly on
the command line.
Pros: Should be robust
Cons: Minimum CMake version for building Qt is 3.16.
3) Abandon the desire to have a single qt_find_package in a single
directory scope, and embrace the CMake-way of repeating the
dependency in each subdirectory that requires it.
Status: Not implemented.
Pros: Should be robust
Cons: A lot of qt_find_package duplication, will require rewriting
various code paths, QtPostProcess would have to be done at
directory scope, unclear if dependency tracking will still work
work reliably when there might be multiple same-named
directory-scoped targets, other unknown unknowns
4) Move all qt_find_package calls into a $repo_name/dependencies.cmake
file which would be read at project root scope. This would
potentially avoid all scoping issues, because all dependencies will
have to be specified at root scope.
Status: Not implemented.
Pros: No duplication
Cons: Dependencies are not scoped anymore to module directories,
won't be able to conditionally look for dependencies based on
module feature evaluation, not clear yet how this will tie into
standalone tests which are in tests/ subdir, other unknown unknowns
5) Try to promote as many 3rd party libraries at project root scope
as possible.
Currently we have 2 general locations where we look up
dependencies.
One is each qt_find_package call. The other is
Qt6FooDependencies.cmake ->
_qt_internal_find_third_party_dependencies().
Many 3rd party targets are created by
_qt_internal_find_third_party_dependencies() in the root scope, but
not promoted, and then we try to promote them in child scopes using
qt_find_package, which causes the promotion errors.
Starting with 58eefbd0b6169d0749b312268c1ae1e594e04362 and
37a5e001277db9e1392a242171ab2b88cb6c3049 we now record the provided
targets of previous qt_find_package calls.
So instead of waiting to try and promote targets later during the
configuration process, we can make sure we promote the targets at
_qt_internal_find_third_party_dependencies() call time, right
when we lookup the Qt dependencies of the qt repo, in the root
scope.
Status: Implemented in this change
Notably, we only promote 3rd party targets to global for qt builds,
and not user projects, to not accidentally break user project
behaviors.
Also, we only promote 3rd party targets, and not Qt internal
targets like Qt6::Core, Qt6::Platform, Qt6::PlatformCommonInternal,
Qt6::GlobalConfig, etc, for a few reasons:
- the code that requires targets to be global only cares about
3rd party targets
- promoting the internal targets is more prone to breaking, because
there is more than one place where find_package(Qt6Foo) might be
called, and if that ends up being in a different directory scope,
we encounter the same global promotion errors.
Some notable cases where this happens:
- tests/CMakeLists.txt brings in extra Qt packages via
StandaloneTestsConfig.cmake files
- qtbase standalone tests qt_internal_qtbase_pre_project_setup()
calls find_package(Qt6 COMPONENTS BuildInternals) which ends
up creating the Platform target in the root scope instead of
the tests/ scope
- Qt6::BundledLibpng links against Core, which ends up trying to
promote Core's internal dependencies Platform and GlobalConfig
To only promote 3rd party targets, we walk the dependencies of
an initial target recursively, and skip promoting targets that have
the _qt_is_internal_target or
_qt_should_skip_global_promotion_always properties set.
Pros: Improves the situation compared to the status quo
Cons: Still not ideal due to the various filtering of internal
targets and having to mark them as such.
6) Avoid promoting targets to global if we can detect that the target
was created in a different scope than where we are trying to
promote it.
We can do that by comparing the target's BINARY_DIR to the
CMAKE_CURRENT_BINARY_DIR and skip promotion if they are not equal.
Status: Not implemented, but we can consider it because it's
quick to do.
Pros: More robust than newly implemented approach (5)
Cons: Requires CMake 3.18, because trying to read the BINARY_DIR
property on an INTERFACE_LIBRARY would error out.
Also, if we implement it and make it the default when using 3.18+,
we might 'collect' a lot more hidden promotion errors that will
only be revealed later once someone uses CMake 3.16 or 3.17,
because most will probably use newer CMake versions.
Perhaps the trade-off is worth it?
Pick-to: 6.8
Fixes: QTBUG-89204
Fixes: QTBUG-94356
Fixes: QTBUG-95052
Fixes: QTBUG-98807
Fixes: QTBUG-125371
Change-Id: I088a17a98ef35aa69537a3ad208c61de40def581
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This change adds a new -sbom configure option to allow generating and
installing an SPDX v2.3 SBOM file when building a qt repo.
The -sbom-dir option can be used to configure the location where
each repo sbom file will be installed.
By default it is installed into
$prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx
which is basically ~/Qt/sbom/qtbase-6.8.0.spdx
The file is installed as part of the default installation rules, but
it can also be installed manually using the "sbom" installation
component, or "sbom_$lower_project_name" in a top-level build. For
example: cmake install . --component sbom_qtbase
CMake 3.19+ is needed to read the qt_attribution.json files for
copyrights, license info, etc. When using an older cmake version,
configuration will error out. It is possible to opt into using an
older cmake version, but the generated sbom will lack all the
attribution file information.
Using an older cmake version is untested and not officially supported.
Implementation notes.
The bulk of the implementation is split into 4 new files:
- QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing
and dispatching the generation of various pieces of the SBOM document
e.g. a SDPX package associated with a target like Core, a SDPX
file entry for each target binary file (per-config shared library,
archive, executable, etc)
- QtPublicSbomGenerationHelpers.cmake - for non-Qt specific
implementation of SPDX generation. This also has some code that was
taken from the cmake-sbom 3rd party project, so it is dual licensed
under the usual Qt build system BSD license, as well as the MIT
license of the 3rd party project
- QtPublicGitHelpers.cmake - for git related features, mainly to embed
queried hashes or tags into version strings, is dual-licensed for
the same reasons as QtPublicSbomGenerationHelpers.cmake
- QtSbomHelpers.cmake - Qt-specific functions that just forward
arguments to the public functions. These are meant to be used in our
Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones
for naming consistency. These function would mostly be used to
annotate 3rd party libraries with sbom info and to add sbom info
for unusual target setups (like the Bootstrap library), because most
of the handling is already done automatically via
qt_internal_add_module/plugin/etc.
The files are put into Public cmake files, with the future hope of
making this available to user projects in some capacity.
The distinction of Qt-specific and non-Qt specific code might blur a
bit, and thus the separation across files might not always be
consistent, but it was best effort.
The main purpose of the code is to collect various information about
targets and their relationships and generate equivalent SPDX info.
Collection is currently done for the following targets: Qt modules,
plugins, apps, tools, system libraries, bundled 3rd party libraries
and partial 3rd party sources compiled directly as part of Qt targets.
Each target has an equivalent SPDX package generated with information
like version, license, copyright, CPE (common vulnerability
identifier), files that belong to the package, and relationships on
other SPDX packages (associated cmake targets), mostly gathered from
direct linking dependencies.
Each package might also contain files, e.g. libQt6Core.so for the Core
target. Each file also has info like license id, copyrights, but also
the list of source files that were used to generate the file and a
sha1 checksum.
SPDX documents can also refer to packages in other SPDX documents, and
those are referred to via external document references. This is the
case when building qtdeclarative and we refer to Core.
For qt provided targets, we have complete information regarding
licenses, and copyrights.
For bundled 3rd party libraries, we should also have most information,
which is usually parsed from the
src/3rdparty/libfoo/qt_attribution.json files.
If there are multiple attribution files, or if the files have multiple
entries, we create a separate SBOM package for each of those entries,
because each might have a separate copyright or version, and an sbom
package can have only one version (although many copyrights).
For system libraries we usually lack the information because we don't
have attribution files for Find scripts. So the info needs to be
manually annotated via arguments to the sbom function calls, or the
FindFoo.cmake scripts expose that information in some form and we
can query it.
There are also corner cases like 3rdparty sources being directly
included in a Qt library, like the m4dc files for Gui, or PCRE2 for
Bootstrap.
Or QtWebEngine libraries (either Qt bundled or Chromium bundled or
system libraries) which get linked in by GN instead of CMake, so there
are no direct targets for them.
The information for these need to be annotated manually as well.
There is also a distinction to be made for static Qt builds (or any
static Qt library in a shared build), where the system libraries found
during the Qt build might not be the same that are linked into the
final user application or library.
The actual generation of the SBOM is done by file(GENERATE)-ing one
.cmake file for each target, file, external ref, etc, which will be
included in a top-level cmake script.
The top-level cmake script will run through each included file, to
append to a "staging" spdx file, which will then be used in a
configure_file() call to replace some final
variables, like embedding a file checksum.
There are install rules to generate a complete SBOM during
installation, and an optional 'sbom' custom target that allows
building an incomplete SBOM during the build step.
The build target is just for convenience and faster development
iteration time. It is incomplete because it is missing the installed
file SHA1 checksums and the document verification code (the sha1 of
all sha1s). We can't compute those during the build before the files
are actually installed.
A complete SBOM can only be achieved at installation time. The install
script will include all the generated helper files, but also set some
additional variables to ensure checksumming happens, and also handle
multi-config installation, among other small things.
For multi-config builds, CMake doesn't offer a way to run code after
all configs are installed, because they might not always be installed,
someone might choose to install just Release.
To handle that, we rely on ninja installing each config sequentially
(because ninja places the install rules into the 'console' pool which
runs one task at a time).
For each installed config we create a config-specific marker file.
Once all marker files are present, whichever config ends up being
installed as the last one, we run the sbom generation once, and then
delete all marker files.
There are a few internal variables that can be set during
configuration to enable various checks (and other features) on the
generated spdx files:
- QT_INTERNAL_SBOM_VERIFY
- QT_INTERNAL_SBOM_AUDIT
- QT_INTERNAL_SBOM_AUDIT_NO_ERROR
- QT_INTERNAL_SBOM_GENERATE_JSON
- QT_INTERNAL_SBOM_SHOW_TABLE
- QT_INTERNAL_SBOM_DEFAULT_CHECKS
These use 3rd party python tools, so they are not enabled by default.
If enabled, they run at installation time after the sbom is installed.
We will hopefully enable them in CI.
Overall, the code is still a bit messy in a few places, due to time
constraints, but can be improved later.
Some possible TODOs for the future:
- Do we need to handle 3rd party libs linked into a Qt static library
in a Qt shared build, where the Qt static lib is not installed, but
linked into a Qt shared library, somehow specially?
We can record a package for it, but we can't
create a spdx file record for it (and associated source
relationships) because we don't install the file, and spdx requires
the file to be installed and checksummed. Perhaps we can consider
adding some free-form text snippet to the package itself?
- Do we want to add parsing of .cpp source files for Copyrights, to
embed them into the packages? This will likely slow down
configuration quite a bit.
- Currently sbom info attached to WrapFoo packages in one repo is
not exported / available in other repos. E.g. If we annotate
WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be
available when looking up WrapZLIB in qtimageformats.
This is because they are IMPORTED libraries, and are not
exported. We might want to record this info in the future.
[ChangeLog][Build System] A new -sbom configure option can be used
to generate and install a SPDX SBOM (Software Bill of Materials) file
for each built Qt repository.
Pick-to: 6.8
Task-number: QTBUG-122899
Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
If we configure module that is already installed it's expected that
tests use the build directory to resolve all the depdencies, but not
the install directory. This is especially sensetive if the module cmake
scripts were changed.
This changes the order of find_<package|dependency> PATHS that are
used to locate Qt package. QT_EXAMPLES_CMAKE_PREFIX_PATH now is used at
first, so we guarantee that we look into the build directory at
first place. This trick only works if build directory is added to
CMAKE_FIND_ROOT_PATH. The reason for that is the internal CMake logic
that tries to relocate the search PATHs and put the paths that are
subdirs of or exact CMAKE_FIND_ROOT_PATH higher in search list.
Fixes: QTBUG-115730
Change-Id: Icab721f0a6eac7301c626350ab214cc4545b368b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...to QT_BUILD_CMAKE_PREFIX_PATH, because the variable is now used for
examples and tests.
Change-Id: Ie6d32a0c99f46407f2771e12638456078c59fb18
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Consider a cross build of Qt with qtbase, qtshadertools and
qtdeclarative. If a user projects only links against QtQml without
creating an actual QtQuick module, no host tools from qtdeclarative are
needed.
Normally, find_package(Qt6Qml) pulls in Qt6QmlTools and errors out if
it's not found. By setting QT_ALLOW_MISSING_TOOLS_PACKAGES when
configuring Qt, one can disable the error and build a user project such
as the one outlined above.
Pick-to: 6.4 6.5
Fixes: QTBUG-109547
Change-Id: I45e727713912d19e6007a7fbf3d61533f82b71d9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jaeyoon Jung <jaeyoon.jung@lge.com>
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 425ff34aa10a02524f2d52f544dc00b539ef9a26
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 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>
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>
