1berry/qtbase
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
qtbase/cmake/QtPublicDependencyHelpers.cmake

344 lines
16 KiB
CMake
Raw Permalink Normal View History

Add license headers to cmake files 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>
2022-07-05 13:26:52 +02:00
# Copyright (C) 2022 The Qt Company Ltd.
Change the license of all CMakeLists.txt and *.cmake files to BSD Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-19 15:21:34 +02:00
# SPDX-License-Identifier: BSD-3-Clause
Add license headers to cmake files 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>
2022-07-05 13:26:52 +02:00
CMake: Extract package dependency finding into functions 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>
2022-07-13 15:11:40 +02:00
# Note that target_dep_list does not accept a list of values, but a var name that contains the
# list of dependencies. See foreach block for reference.
macro(_qt_internal_find_third_party_dependencies target target_dep_list)
foreach(__qt_${target}_target_dep IN LISTS ${target_dep_list})
list(GET __qt_${target}_target_dep 0 __qt_${target}_pkg)
list(GET __qt_${target}_target_dep 1 __qt_${target}_is_optional)
list(GET __qt_${target}_target_dep 2 __qt_${target}_version)
list(GET __qt_${target}_target_dep 3 __qt_${target}_components)
list(GET __qt_${target}_target_dep 4 __qt_${target}_optional_components)
set(__qt_${target}_find_package_args "${__qt_${target}_pkg}")
if(__qt_${target}_version)
list(APPEND __qt_${target}_find_package_args "${__qt_${target}_version}")
endif()
if(__qt_${target}_components)
string(REPLACE " " ";" __qt_${target}_components "${__qt_${target}_components}")
list(APPEND __qt_${target}_find_package_args COMPONENTS ${__qt_${target}_components})
endif()
if(__qt_${target}_optional_components)
string(REPLACE " " ";"
__qt_${target}_optional_components "${__qt_${target}_optional_components}")
list(APPEND __qt_${target}_find_package_args
OPTIONAL_COMPONENTS ${__qt_${target}_optional_components})
endif()
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting 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>
2022-07-14 17:00:56 +02:00
_qt_internal_save_find_package_context_for_debugging(${target})
CMake: Extract package dependency finding into functions 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>
2022-07-13 15:11:40 +02:00
if(__qt_${target}_is_optional)
if(${CMAKE_FIND_PACKAGE_NAME}_FIND_QUIETLY)
list(APPEND __qt_${target}_find_package_args QUIET)
endif()
find_package(${__qt_${target}_find_package_args})
else()
find_dependency(${__qt_${target}_find_package_args})
Avoid creating Plugin targets if the dependencies are missing 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>
2024-12-17 18:41:32 +01:00
if(NOT ${__qt_${target}_pkg}_FOUND)
list(APPEND __qt_${target}_missing_deps "${__qt_${target}_pkg}")
endif()
CMake: Extract package dependency finding into functions 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>
2022-07-13 15:11:40 +02:00
endif()
CMake: Generate an SPDX v2.3 SBOM file for each built repository 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>
2024-03-07 18:02:56 +01:00
_qt_internal_get_package_components_id(
PACKAGE_NAME "${__qt_${target}_pkg}"
COMPONENTS ${__qt_${target}_components}
OPTIONAL_COMPONENTS ${__qt_${target}_optional_components}
OUT_VAR_KEY __qt_${target}_package_components_id
)
if(${__qt_${target}_pkg}_FOUND
AND __qt_${target}_third_party_package_${__qt_${target}_package_components_id}_provided_targets)
set(__qt_${target}_sbom_args "")
if(${__qt_${target}_pkg}_VERSION)
list(APPEND __qt_${target}_sbom_args
PACKAGE_VERSION "${${__qt_${target}_pkg}_VERSION}"
)
endif()
CMake: Prevent most global promotion errors when building Qt 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>
2024-07-01 19:10:26 +02:00
foreach(__qt_${target}_provided_target
IN LISTS
__qt_${target}_third_party_package_${__qt_${target}_package_components_id}_provided_targets)
_qt_internal_promote_3rd_party_provided_target_and_3rd_party_deps_to_global(
"${__qt_${target}_provided_target}")
_qt_internal_sbom_record_system_library_usage(
"${__qt_${target}_provided_target}"
TYPE SYSTEM_LIBRARY
FRIENDLY_PACKAGE_NAME "${__qt_${target}_pkg}"
${__qt_${target}_sbom_args}
)
endforeach()
CMake: Generate an SPDX v2.3 SBOM file for each built repository 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>
2024-03-07 18:02:56 +01:00
endif()
CMake: Extract package dependency finding into functions 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>
2022-07-13 15:11:40 +02:00
endforeach()
endmacro()
# Note that target_dep_list does not accept a list of values, but a var name that contains the
# list of dependencies. See foreach block for reference.
macro(_qt_internal_find_tool_dependencies target target_dep_list)
if(NOT "${${target_dep_list}}" STREQUAL "" AND NOT "${QT_HOST_PATH}" STREQUAL "")
# 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})
list(PREPEND CMAKE_PREFIX_PATH "${QT_HOST_PATH_CMAKE_DIR}"
"${_qt_additional_host_packages_prefix_paths}")
list(PREPEND CMAKE_FIND_ROOT_PATH "${QT_HOST_PATH}"
"${_qt_additional_host_packages_root_paths}")
endif()
Small _qt_internal_find_tool_dependencies optimization bit 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>
2025-01-06 18:25:38 +01:00
unset(__qt_${target}_find_package_args)
if(${CMAKE_FIND_PACKAGE_NAME}_FIND_QUIETLY)
list(APPEND __qt_${target}_find_package_args QUIET)
endif()
CMake: Extract package dependency finding into functions 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>
2022-07-13 15:11:40 +02:00
foreach(__qt_${target}_target_dep IN LISTS ${target_dep_list})
list(GET __qt_${target}_target_dep 0 __qt_${target}_pkg)
list(GET __qt_${target}_target_dep 1 __qt_${target}_version)
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting 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>
2022-07-14 17:00:56 +02:00
_qt_internal_save_find_package_context_for_debugging(${target})
CMake: Extract package dependency finding into functions 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>
2022-07-13 15:11:40 +02:00
find_package(${__qt_${target}_pkg}
${__qt_${target}_version}
${__qt_${target}_find_package_args}
PATHS
CMake: Allow setting Qt6_DIR to find packages when not cross-compiling 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>
2022-07-13 19:09:32 +02:00
"${CMAKE_CURRENT_LIST_DIR}/.."
"${_qt_cmake_dir}"
CMake: Extract package dependency finding into functions 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>
2022-07-13 15:11:40 +02:00
${_qt_additional_packages_prefix_paths}
)
CMake: Add switch for allowing missing Qt6*Tools packages 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>
2023-01-06 16:12:34 +01:00
if (NOT ${__qt_${target}_pkg}_FOUND AND NOT QT_ALLOW_MISSING_TOOLS_PACKAGES)
CMake: Display reason when a Qt*Tools package is not found 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>
2022-07-13 19:05:34 +02:00
set(${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
"${CMAKE_FIND_PACKAGE_NAME} could not be found because dependency \
${__qt_${target}_pkg} could not be found.")
CMake: Extract package dependency finding into functions 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>
2022-07-13 15:11:40 +02:00
if(NOT "${QT_HOST_PATH}" STREQUAL "")
set(CMAKE_PREFIX_PATH ${BACKUP_${target}_CMAKE_PREFIX_PATH})
set(CMAKE_FIND_ROOT_PATH ${BACKUP_${target}_CMAKE_FIND_ROOT_PATH})
endif()
return()
endif()
endforeach()
if(NOT "${${target_dep_list}}" STREQUAL "" AND NOT "${QT_HOST_PATH}" STREQUAL "")
set(CMAKE_PREFIX_PATH ${BACKUP_${target}_CMAKE_PREFIX_PATH})
set(CMAKE_FIND_ROOT_PATH ${BACKUP_${target}_CMAKE_FIND_ROOT_PATH})
endif()
endmacro()
Move dependency lookup functionality to the common macro 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>
2021-06-17 16:18:59 +02:00
# Please note the target_dep_list accepts not the actual list values but the list names that
# contain preformed dependencies. See foreach block for reference.
# The same applies for find_dependency_path_list.
CMake: Suggest hints on how to debug missing packages 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>
2022-07-14 15:28:12 +02:00
macro(_qt_internal_find_qt_dependencies target target_dep_list find_dependency_path_list)
CMake: Fix backup/restore of QT_NO_PRIVATE_MODULE_WARNING ...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>
2025-05-21 15:30:47 +02:00
list(APPEND __qt_${target}_find_qt_dependencies_save_QT_NO_PRIVATE_MODULE_WARNING
CMake: Silence the private module warning for dependencies 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>
2025-01-29 08:50:17 +01:00
${QT_NO_PRIVATE_MODULE_WARNING}
)
set(QT_NO_PRIVATE_MODULE_WARNING ON)
CMake: Suggest hints on how to debug missing packages 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>
2022-07-14 15:28:12 +02:00
foreach(__qt_${target}_target_dep IN LISTS ${target_dep_list})
list(GET __qt_${target}_target_dep 0 __qt_${target}_pkg)
list(GET __qt_${target}_target_dep 1 __qt_${target}_version)
Move dependency lookup functionality to the common macro 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>
2021-06-17 16:18:59 +02:00
CMake: Suggest hints on how to debug missing packages 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>
2022-07-14 15:28:12 +02:00
if (NOT ${__qt_${target}_pkg}_FOUND)
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting 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>
2022-07-14 17:00:56 +02:00
_qt_internal_save_find_package_context_for_debugging(${target})
CMake: Suggest hints on how to debug missing packages 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>
2022-07-14 15:28:12 +02:00
find_dependency(${__qt_${target}_pkg} ${__qt_${target}_version}
Move dependency lookup functionality to the common macro 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>
2021-06-17 16:18:59 +02:00
PATHS
Make sure that tests use the module build directory but not install path 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>
2023-08-22 19:11:30 +02:00
${QT_BUILD_CMAKE_PREFIX_PATH}
Move dependency lookup functionality to the common macro 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>
2021-06-17 16:18:59 +02:00
${${find_dependency_path_list}}
CMake: Fix QT_ADDITIONAL_PACKAGES_PREFIX_PATH for cross-builds The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to allow specifying extra locations to find Qt packages. The reason it was introduced instead of just using CMAKE_PREFIX_PATH is because the Qt6 component find_package call uses NO_DEFAULT_PATH which means CMAKE_PREFIX_PATH is ignored. We use NO_DEFAULT_PATH to ensure we don't accidentally pick up system / distro Qt packages. The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the find_package PATHS option in the Qt6 package, each ModuleDependencies.cmake file and some other places. Unfortunately that's not enough to make it work for cross-builds. Imagine the following scenario. host qtbase, qtdeclarative installed in /host_qt target qtbase installed in /target_qtbase target qtdeclarative installed in /target_qtdeclarative We want to cross-build qtlottie. We configure qtlottie as follows /target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative We expect the target QtQuick package to be found, but it won't be. The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH. Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH, which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to /target_qtbase. There is no QtQuick package there. To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH to CMAKE_FIND_ROOT_PATH. The location where we currently do CMAKE_FIND_ROOT_PATH manipulations is in the qt.toolchain.cmake file, so to be consistent, we prepend the new prefixes there as well. We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH, due the path re-rooting bug in CMake. See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as the existing comment in qt.toolchain.cmake marked with REROOT_PATH_ISSUE_MARKER. We also need to do a few more things to make the setup work Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH adjustments we do in the toolchain file are not enough, so we still need to add the same prefixes to the Qt6Config find_package PATHS option. One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then. It's for find_package(Qt6Foo) calls to work which don't go through the Qt6Config umbrella package. To make the CMake re-rooting behavior happy, we need to ensure the provided paths are absolute. So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH, to make them absolute. We do the same for the environment variable. We need to append lib/cmake to the prefixes which are added to CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit. We need to specify the Qt6 package location (${_qt_cmake_dir}) to the PATHS option in the various Dependencies.cmake.in files, to ensure that dependency resolution can jump around between the Qt6 dir and the additional prefixes. Previously the dependency lookup code assumed that all dependencies would be within the same prefix. The same is needed for qt and qml plugin dependency lookup. Amends 7bb91398f25cb2016c0558fd397b376f413e3e96 Amends 60c87c68016c6f02b0eddd4002f75a49ab51d4a8 Amends 5bbd700124d13a292ff8bae6045316112500e230 Pick-to: 6.2 Fixes: QTBUG-95854 Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 17:03:02 +02:00
${_qt_additional_packages_prefix_paths}
Move dependency lookup functionality to the common macro 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>
2021-06-17 16:18:59 +02:00
${__qt_use_no_default_path_for_qt_packages}
)
Avoid creating Plugin targets if the dependencies are missing 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>
2024-12-17 18:41:32 +01:00
if(NOT ${__qt_${target}_pkg}_FOUND)
list(APPEND __qt_${target}_missing_deps "${__qt_${target}_pkg}")
endif()
Move dependency lookup functionality to the common macro 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>
2021-06-17 16:18:59 +02:00
endif()
endforeach()
CMake: Silence the private module warning for dependencies 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>
2025-01-29 08:50:17 +01:00
CMake: Fix backup/restore of QT_NO_PRIVATE_MODULE_WARNING ...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>
2025-05-21 15:30:47 +02:00
list(POP_BACK __qt_${target}_find_qt_dependencies_save_QT_NO_PRIVATE_MODULE_WARNING
QT_NO_PRIVATE_MODULE_WARNING
CMake: Silence the private module warning for dependencies 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>
2025-01-29 08:50:17 +01:00
)
Move dependency lookup functionality to the common macro 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>
2021-06-17 16:18:59 +02:00
endmacro()
CMake: Rename _qt_internal_find_dependencies to something less generic Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I99b69865f711ff57511f32df2f345cebb7445d44 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-13 19:22:37 +02:00
CMake: Suggest hints on how to debug missing packages 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>
2022-07-14 15:28:12 +02:00
# If a dependency package was not found, provide some hints in the error message on how to debug
# the issue.
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting 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>
2022-07-14 17:00:56 +02:00
#
CMake: Suggest hints on how to debug missing packages 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>
2022-07-14 15:28:12 +02:00
# pkg_name_var should be the variable name that contains the package that was not found.
# e.g. __qt_Core_pkg
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting 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>
2022-07-14 17:00:56 +02:00
#
CMake: Suggest hints on how to debug missing packages 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>
2022-07-14 15:28:12 +02:00
# message_out_var should contain the variable name of the original "not found" message, and it
# will have the hints appended to it as a string. e.g. ${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
#
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting 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>
2022-07-14 17:00:56 +02:00
# infix is used as a unique prefix to retrieve the find_package paths context for the last package
# that was not found, for debugging purposes.
#
CMake: Suggest hints on how to debug missing packages 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>
2022-07-14 15:28:12 +02:00
# The function should not be called in Dependencies.cmake files directly, because find_dependency
# returns out of the included file.
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting 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>
2022-07-14 17:00:56 +02:00
macro(_qt_internal_suggest_dependency_debugging infix pkg_name_var message_out_var)
CMake: Suggest hints on how to debug missing packages 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>
2022-07-14 15:28:12 +02:00
if(${pkg_name_var}
AND NOT ${CMAKE_FIND_PACKAGE_NAME}_FOUND
AND ${message_out_var})
if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.23")
string(APPEND ${message_out_var}
"\nConfiguring with --debug-find-pkg=${${pkg_name_var}} might reveal \
details why the package was not found.")
elseif(CMAKE_VERSION VERSION_GREATER_EQUAL "3.17")
string(APPEND ${message_out_var}
"\nConfiguring with -DCMAKE_FIND_DEBUG_MODE=TRUE might reveal \
details why the package was not found.")
endif()
CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshooting 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>
2022-07-14 17:00:56 +02:00
if(NOT QT_DEBUG_FIND_PACKAGE)
string(APPEND ${message_out_var}
"\nConfiguring with -DQT_DEBUG_FIND_PACKAGE=ON will print the values of some of \
the path variables that find_package uses to try and find the package.")
else()
string(APPEND ${message_out_var}
"\n find_package search path values and other context for the last package that was not found:"
"\n CMAKE_MODULE_PATH: ${_qt_${infix}_CMAKE_MODULE_PATH}"
"\n CMAKE_PREFIX_PATH: ${_qt_${infix}_CMAKE_PREFIX_PATH}"
"\n \$ENV{CMAKE_PREFIX_PATH}: $ENV{CMAKE_PREFIX_PATH}"
"\n CMAKE_FIND_ROOT_PATH: ${_qt_${infix}_CMAKE_FIND_ROOT_PATH}"
"\n _qt_additional_packages_prefix_paths: ${_qt_${infix}_qt_additional_packages_prefix_paths}"
"\n _qt_additional_host_packages_prefix_paths: ${_qt_${infix}_qt_additional_host_packages_prefix_paths}"
"\n _qt_cmake_dir: ${_qt_${infix}_qt_cmake_dir}"
"\n QT_HOST_PATH: ${QT_HOST_PATH}"
"\n Qt6HostInfo_DIR: ${Qt6HostInfo_DIR}"
"\n Qt6_DIR: ${Qt6_DIR}"
"\n CMAKE_TOOLCHAIN_FILE: ${CMAKE_TOOLCHAIN_FILE}"
"\n CMAKE_FIND_ROOT_PATH_MODE_PACKAGE: ${CMAKE_FIND_ROOT_PATH_MODE_PACKAGE}"
"\n CMAKE_SYSROOT: ${CMAKE_SYSROOT}"
"\n \$ENV{PATH}: $ENV{PATH}"
)
endif()
endif()
endmacro()
# Save find_package search paths context just before a find_package call, to be shown with a
# package not found message.
macro(_qt_internal_save_find_package_context_for_debugging infix)
if(QT_DEBUG_FIND_PACKAGE)
set(_qt_${infix}_CMAKE_MODULE_PATH "${CMAKE_MODULE_PATH}")
set(_qt_${infix}_CMAKE_PREFIX_PATH "${CMAKE_PREFIX_PATH}")
set(_qt_${infix}_CMAKE_FIND_ROOT_PATH "${CMAKE_FIND_ROOT_PATH}")
set(_qt_${infix}_qt_additional_packages_prefix_paths
"${_qt_additional_packages_prefix_paths}")
set(_qt_${infix}_qt_additional_host_packages_prefix_paths
"${_qt_additional_host_packages_prefix_paths}")
set(_qt_${infix}_qt_cmake_dir "${_qt_cmake_dir}")
CMake: Suggest hints on how to debug missing packages 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>
2022-07-14 15:28:12 +02:00
endif()
CMake: Rename _qt_internal_find_dependencies to something less generic Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I99b69865f711ff57511f32df2f345cebb7445d44 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-13 19:22:37 +02:00
endmacro()
CMake: Move Qt6HostInfo lookup into a function 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>
2022-07-15 18:14:20 +02:00
CMake: Improve Qt6HostInfo package lookup condition 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>
2022-07-18 14:14:41 +02:00
function(_qt_internal_determine_if_host_info_package_needed out_var)
set(needed FALSE)
CMake: Move QT_HOST_PATH check and computation into Qt6 package 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>
2022-07-18 16:09:30 +02:00
# If a QT_HOST_PATH is provided when configuring qtbase, we assume it's a cross build
# and thus we require the QT_HOST_PATH to be provided also when using the cross-built Qt.
# This tells the QtConfigDependencies file to do appropriate requirement checks.
if(NOT "${QT_HOST_PATH}" STREQUAL "" AND NOT QT_NO_REQUIRE_HOST_PATH_CHECK)
CMake: Improve Qt6HostInfo package lookup condition 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>
2022-07-18 14:14:41 +02:00
set(needed TRUE)
endif()
set(${out_var} "${needed}" PARENT_SCOPE)
endfunction()
Make the HostInfo package lookup properly versioned 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>
2025-03-17 17:31:00 +01:00
macro(_qt_internal_find_host_info_package platform_requires_host_info install_namespace)
CMake: Improve Qt6HostInfo package lookup condition 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>
2022-07-18 14:14:41 +02:00
if(${platform_requires_host_info})
Make the HostInfo package lookup properly versioned 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>
2025-03-17 17:31:00 +01:00
find_package(${install_namespace}HostInfo
CMake: Move Qt6HostInfo lookup into a function 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>
2022-07-15 18:14:20 +02:00
CONFIG
REQUIRED
PATHS "${QT_HOST_PATH}"
"${QT_HOST_PATH_CMAKE_DIR}"
NO_CMAKE_FIND_ROOT_PATH
NO_DEFAULT_PATH)
endif()
endmacro()
CMake: Move QT_HOST_PATH check and computation into Qt6 package 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>
2022-07-18 16:09:30 +02:00
macro(_qt_internal_setup_qt_host_path
host_path_required
initial_qt_host_path
initial_qt_host_path_cmake_dir
)
# Set up QT_HOST_PATH and do sanity checks.
# A host path is required when cross-compiling but optional when doing a native build.
# Requiredness can be overridden via variable.
if(DEFINED QT_REQUIRE_HOST_PATH_CHECK)
set(_qt_platform_host_path_required "${QT_REQUIRE_HOST_PATH_CHECK}")
CMake: Allow opting out of Qt6HostInfo package lookup in user projects 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>
2024-08-21 17:30:01 +02:00
elseif(DEFINED ENV{QT_REQUIRE_HOST_PATH_CHECK})
set(_qt_platform_host_path_required "$ENV{QT_REQUIRE_HOST_PATH_CHECK}")
CMake: Move QT_HOST_PATH check and computation into Qt6 package 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>
2022-07-18 16:09:30 +02:00
else()
set(_qt_platform_host_path_required "${host_path_required}")
endif()
if(_qt_platform_host_path_required)
# QT_HOST_PATH precedence:
# - cache variable / command line option
# - environment variable
# - initial QT_HOST_PATH when qtbase was configured (and the directory exists)
if(NOT DEFINED QT_HOST_PATH)
if(DEFINED ENV{QT_HOST_PATH})
set(QT_HOST_PATH "$ENV{QT_HOST_PATH}" CACHE PATH "")
elseif(NOT "${initial_qt_host_path}" STREQUAL "" AND EXISTS "${initial_qt_host_path}")
set(QT_HOST_PATH "${initial_qt_host_path}" CACHE PATH "")
endif()
endif()
if(NOT QT_HOST_PATH STREQUAL "")
get_filename_component(_qt_platform_host_path_absolute "${QT_HOST_PATH}" ABSOLUTE)
endif()
if("${QT_HOST_PATH}" STREQUAL "" OR NOT EXISTS "${_qt_platform_host_path_absolute}")
message(FATAL_ERROR
"To use a cross-compiled Qt, please set the QT_HOST_PATH cache variable to the "
"location of your host Qt installation.")
endif()
# QT_HOST_PATH_CMAKE_DIR is needed to work around the rerooting issue when looking for host
# tools. See REROOT_PATH_ISSUE_MARKER.
# Prefer initially configured path if none was explicitly set.
if(NOT DEFINED QT_HOST_PATH_CMAKE_DIR)
if(NOT "${initial_qt_host_path_cmake_dir}" STREQUAL ""
AND EXISTS "${initial_qt_host_path_cmake_dir}")
set(QT_HOST_PATH_CMAKE_DIR "${initial_qt_host_path_cmake_dir}" CACHE PATH "")
else()
# First try to auto-compute the location instead of requiring to set
# QT_HOST_PATH_CMAKE_DIR explicitly.
set(__qt_candidate_host_path_cmake_dir "${QT_HOST_PATH}/lib/cmake")
if(__qt_candidate_host_path_cmake_dir
AND EXISTS "${__qt_candidate_host_path_cmake_dir}")
set(QT_HOST_PATH_CMAKE_DIR
"${__qt_candidate_host_path_cmake_dir}" CACHE PATH "")
endif()
endif()
endif()
if(NOT QT_HOST_PATH_CMAKE_DIR STREQUAL "")
get_filename_component(_qt_platform_host_path_cmake_dir_absolute
"${QT_HOST_PATH_CMAKE_DIR}" ABSOLUTE)
endif()
if("${QT_HOST_PATH_CMAKE_DIR}" STREQUAL ""
OR NOT EXISTS "${_qt_platform_host_path_cmake_dir_absolute}")
message(FATAL_ERROR
"To use a cross-compiled Qt, please set the QT_HOST_PATH_CMAKE_DIR cache variable "
"to the location of your host Qt installation lib/cmake directory.")
endif()
endif()
endmacro()
CMake: Silence the private module warning for dependencies 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>
2025-01-29 08:50:17 +01:00
function(_qt_internal_show_private_module_warning module)
Suppress the Private module warning if QT_FIND_PRIVATE_MODULES is ON 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>
2025-03-07 13:40:17 +01:00
if(DEFINED QT_REPO_MODULE_VERSION OR QT_NO_PRIVATE_MODULE_WARNING OR QT_FIND_PRIVATE_MODULES)
CMake: Silence the private module warning for dependencies 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>
2025-01-29 08:50:17 +01:00
return()
endif()
get_cmake_property(warning_shown __qt_private_module_${module}_warning_shown)
if(warning_shown)
return()
endif()
message(WARNING
"This project is using headers of the ${module} module and will therefore be tied "
"to this specific Qt module build version. "
"Running this project against other versions of the Qt modules may crash at any arbitrary "
"point. This is not a bug, but a result of using Qt internals. You have been warned! "
"\nYou can disable this warning by setting QT_NO_PRIVATE_MODULE_WARNING to ON."
)
set_property(GLOBAL PROPERTY __qt_private_module_${module}_warning_shown TRUE)
endfunction()
Reference in New Issue Copy Permalink