summaryrefslogtreecommitdiffstats
path: root/cmake/Qt3rdPartyLibraryHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Rename TYPE to SBOM_ENTITY_TYPE in SBOM APIAlexandru Croitor2025-09-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Introduce two new options for SBOM entity type specification: - SBOM_ENTITY_TYPE: has the highest priority - DEFAULT_SBOM_ENTITY_TYPE: Used as a fallback when no explicit type is given. Deprecate the old pre-existing TYPE option in favor of either SBOM_ENTITY_TYPE or DEFAULT_SBOM_ENTITY_TYPE. The reason is to allow forwarding these option names directly via functions like qt_internal_add_sbom, or the Creator equivalents, without having a potential clash with a very generic name like TYPE. Adjust the code to use the new options inside the various implementation functions, but keep the old TYPE option for compatibility in the public facing APIs, to not break existing callers. Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-134894 Change-Id: I36cd6c4a5dab19221efacbe32688eab7db4f142f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Don't install incomplete Qt6BundledFoo packagesJoerg Bornemann2025-08-131-0/+1
| | | | | | | | | | | | | | | | | | | | | Assume a prefix build and a qt_internal_add_3rdparty_library(BundledFoo) call without passing INSTALL. Then we installed a Qt6BundledFooDependencies.cmake even though installation for this package was not requested. This happened, because we create the dependencies file in the post-processing step which didn't have knowledge whether INSTALL was passed or not. The code solely relied on the QT_WILL_INSTALL variable. We now let qt_internal_add_3rdparty_library and qt_internal_add_module set a target property _qt_will_install on created targets. This property specifies whether installation is requested for that target. In the post-processing step we read that target property. Pick-to: 6.10 Fixes: QTBUG-138580 Change-Id: I7f0df6242e0ab7b433cab4e4e2850e99e67c85a7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Replace `QT_NO_CREATE_TARGETS` with an automated and scoped logicCristian Le2025-06-271-0/+12
| | | | | | | | | | Effectively check if we are importing while still building the current project Task-number: QTBUG-135233 Change-Id: If172617463157e84e1b16fc2354147fabae41084 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Add NO_PCH_SOURCES argument to qt_internal_add_cmake_libraryJoerg Bornemann2025-03-201-19/+22
| | | | | | | | Forward NO_PCH_SOURCES to qt_internal_extend_target and port to _qt_internal_forward_function_args while we're at it. Change-Id: I0c62e84c5a22f937904c1949ff34d0171a1a937f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix the condition that enables/defaults exceptionsAlexey Edelev2025-03-171-1/+1
| | | | | | | | | | | | | Not sure why it worked at implementation time. But now it definitely doesn't. We may check the EXCEPTIONS flag value, since it's the equivalent of its presence/non-presence in the argument list. Amends f98fd705290ac7bd9434552a07e38b775e6a6dbf Task-number: QTBUG-118901 Pick-to: 6.9 Change-Id: I9769b4921a2f72d31aea2b0bffd2511edd89f88f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Decouple Qt specific handling from SBOM implementationAlexandru Croitor2025-02-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The SBOM functions so far had a lot of Qt-specific logic inside them. Decouple this logic into separate Qt-specific functions or explicitly guard the code with Qt-specific handling options, to prepare for a cleaner SBOM public API. The generic functions then call the Qt-specific ones if various internal options are set. This approach is used, rather than directly passing values to the generic functions because: - we have cases where we need to recursively pass the values all the way down to all recursively created attribution targets - some of the logic needs to know about values before and after qt processing, and this could be achieved with something like lambdas but it's not worth the complexity Pick-to: 6.8 6.9 Task-number: QTBUG-122899 Change-Id: I4399c41f4d976f20b16a0bb0c674d4f07ee1ccd4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix CMP0174 warningsJoerg Bornemann2024-11-081-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | CMake 3.31 introduced the policy CMP0174 that triggers a warning if a single-value argument is passed to a function without a value. We did this doing this when forwarding arguments in code that doesn't use _qt_internal_forward_function_args yet, e.g. in qt_internal_add_app: qt_internal_add_executable(... TARGET_PRODUCT ${arg_TARGET_PRODUCT} ...) Forward the warning-triggering arguments with _qt_internal_forward_function_args now, because that only forwards used arguments. In the future, we can offload more forwarding work to the _qt_internal_forward_function_args command and simplify the forwarding code in qt_internal_add_app and qt_internal_add_tool. This patch only fixes the worst offenders for now. Pick-to: 6.8 Change-Id: Ie786691e4b236decf4c62f4dd0751ed76b721177 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Make per-repos WARNINGS_ARE_ERRORS workAlexey Edelev2024-09-121-2/+2
| | | | | | | | | | | | | | | | | | | | Add the WARNINGS_ARE_ERRORS flags unconditionally, so developers may control skipping per-target or per-repo. This allows setting the WARNINGS_ARE_ERRORS cmake option for each repo independently when configuring them. So qtbase might be built without the flag enabled and setting the WARNINGS_ARE_ERRORS to TRUE for the depending repo enables it for the internal Qt targets. Add the new internal function that controls the related internal flag. Keep qt_skip_warnings_are_errors for compatibility since it's used in qtwebengine. Combine qt_internal_set_skip_warnings_are_errors and qt_skip_warnings_are_errors_when_repo_unclean functionality in the new qt_internal_default_warnings_are_errors function. Change-Id: I1330c75cd67a24e6386f5e94a089e43fa2012bc4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Detect 3rd party header modules during SBOM generationAlexandru Croitor2024-08-171-0/+1
| | | | | | | | | | They should inherit the version of the 3rd party library they are part of, and not be treated as Qt modules. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: Ibf99f4481fbc1acca488fc96cca048298b080d35 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Switch to non-strict C++ builds so QT_SUPPORTS_INT128 is trueMarc Mutz2024-08-161-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | A previous commit disabled QT_SUPPORTS_INT128 if the Standard Library doesn't properly specialize <type_traits> and <limits> for the 128-bit types, like libstdc++ in strict mode. As a consequence, we now need to compile Qt in non-strict mode so QT_SUPPORTS_INT128 is true when building Qt, at least if the compiler supports 128-bit integers in principle. Statically assert that QT_SUPPORTS_INT128 is defined if the compiler in principle supports it, to catch other problematic platforms early. We have a few out-of-line implementations that should be built if the compiler supports int128 in principle, so that Qt users are free to use the types if their compiler supports them and not run into missing support in the Qt library. This patch ensures this. Compiling in non-strict mode removes the early warning we were getting from it, but a) headersclean still uses strict mode, so at least our headers are regularly checked and b) this is a cross-platform project; if we were to use platform-specific extensions unprotected, other platform's compilers will still complain. Fixes: QTBUG-119901 Pick-to: 6.8 Change-Id: I974f95ca0f26085dd0fe5ceb8bbef4f62467979a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add the 'exceptions' featureAlexey Edelev2024-08-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The feature allows enabling/disabling exceptions for the Qt builds. The feature is disabled by default. This commit reworks the way the exception flags are set for Qt targets. Instead of setting them per-target, flags now are set for the QtPlatformCommonInternal target, which transitively propagates the flag to other Qt targets. To disable/enable exception flags the newly introduced property _qt_internal_use_exceptions can be used. The flags enabling/disabling now can happen any time, but not only at target creation time. The property has 3 states: TRUE, FALSE, DEFAULT(or empty). If the property is not set or is set to DEFAULT, the exceptions feature value is used to set the required exceptions flags. Otherwise the flags are set according to the property value. The logic of EXCEPTION argument of the various qt_internal_add_ functions was also updated. If the argument is not provided, the _qt_internal_use_exceptions property value is set to DEFAULT, which gives the control on the exception flags to the feature. If the argument is provided, the exceptions are enabled by setting the _qt_internal_use_exceptions property to TRUE. Task-number: QTBUG-118901 Change-Id: I83e3bf52d48a3d16977cce849c9b0765c34f1f21 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow specifying most SBOM options to qt_internal_add_fooAlexandru Croitor2024-06-181-28/+8
| | | | | | | | | | | | | | | | | | | | | | Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Generate an SPDX v2.3 SBOM file for each built repositoryAlexandru Croitor2024-06-131-0/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Remove GENERATE_CPP_EXPORTS argumentAlexey Edelev2024-06-121-0/+1
| | | | | | | | | The behavior that argument was enabling is the default one now. Pick-to: 6.8 Task-number: QTBUG-90492 Change-Id: I11711d4c794f0b22169abb595b8ffad2eeb1300d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* "Simplify" versionless targetsAlexey Edelev2024-03-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Versionless targets in Qt6 are interface libraries that link the versioned libraries using the INTERFACE link type. This makes the linking chain more complicated than it can be. Also we miss some significant interface properties in the versionless targets comparing to the versioned targets. The new approach manually generates the versionless targets, instead of using CMake exports. For CMake versions < 3.18 we now create a copy of the versioned targets. The copy includes all the relevant INTERFACE properties from the versioned targets and imported locations for all configs. For CMake versions >= 3.18 we now create the versionless target ALIASes which should behave give the transparent access to the versioned targets. Using the QT_USE_OLD_VERSION_LESS_TARGETS flag you may force the behavor of the CMake versions <= 3.18 The change is partial workaround for QTBUG-86533. Task-number: QTBUG-114706 Change-Id: Iafadf6154eb4912df0697648c031fcc1cbde04e0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Improve the internal handling of unity buildAmir Masoud Abdol2023-03-141-14/+3
| | | | | | | | | | | | | | | | | | | - Removed the NO_UNITY_BUILD argument from commands that disable it by default. - Add a warning in case NO_UNITY_BUILD or NO_UNITY_BUILD_SOURCES is being used where it is already disabled, e.g., qt_internal_add_test - Exclude all sources of a target from unity build if NO_UNITY_BUILD is set on the target. This sounds a bit harsh, but I have noticed that sometimes the same source file can be included somewhere else, and some unexpected collision may occur. - qt_examples_build_end excludes all its examples from the unity build. - qt_build_test now sets the CMAKE_UNITY_BUILD to OFF before configuring the tests, and restore its value when done. Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ia42e7dd5a5bfb151db241deb639325720fd91eec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add some utilities for UNITY_BUILDAmir Masoud Abdol2023-02-081-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | - The following commands accepts NO_UNITY_BUILD, and NO_UNITY_BUILD_SOURCES arguments to opt out of the unity build, and to exclude some source files from unity build, respectively. - qt_internal_add_executable - qt_internal_add_module - qt_internal_add_plugin - qt_internal_add_tool - qt_internal_extend_target - qt_internal_add_common_qt_library_helper - qt_internal_add_cmake_library - qt_internal_add_simd_part - Unity build is disabled by default in these: - qt_internal_add_test - qt_internal_add_test_helper - qt_internal_add_benchmark - qt_internal_add_3rdparty_library - qt_update_ignore_pch_source also excludes the files from unity_build Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I5d0e7df633738310a015142a6c73fbb78b6c3467 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Retire the qt_parse_all_argumentsAmir Masoud Abdol2023-01-181-8/+9
| | | | | | | | | | | This replaces the qt_parse_all_arguments macro with the built-in `cmake_parse_arguments(PARSE_ARGV`. In addition, a new function, _qt_internal_validate_all_args_are_parsed, can be used to check whether any _UNPARSED_ARGUMENTS have been passed to the function. Fixes: QTBUG-99238 Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* MSVC: Improve the LTCG buildYuhang Zhao2022-12-031-0/+6
| | | | | | | | | | | | | | | | | | | When we use MSVC to build static libraries, enabling LTCG will generate very large output, for example, Qt's bundled 3rd party libraries can be greater than 100MB per file (some of them even >200MB!). This is not good if we are building a shared version of Qt and enabling LTCG at the same time. On Windows Qt's bundled 3rd party dependencies will be built as static libraries and they will make the final Qt package way too large. From my side, if I only build a release version, the package size is usually around 500MB but when LTCG is enabled, it become over 2GB. The exe and dlls' size don't vary much, but there are many large static libraries. Fixes: QTBUG-108719 Change-Id: Ic521f500b9c24389524e96a8cdc2e7b3427b51a9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
* CMake: add SYSTEM_INCLUDE_DIRECTORIES to qt_internal_extend_targetThiago Macieira2022-11-281-0/+2
| | | | | | | | | | | | This allows one to add an extra set of directories to the build, but let the compiler know that they are system paths (that is, the compiler should refrain from emitting warnings in code found there). This extends INCLUDE_DIRECTORIES and is by necessity a private include set. Will be used by qtquick3dphysics, due to its PhysX dependency. Change-Id: I76216ced393445a4ae2dfffd1729c556db0cce3d Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Export package name and 3rdparty flag for 3rd party librariesAlexandru Croitor2022-07-281-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | Needed to get rid of warnings like CMake Warning at cmake/QtFindPackageHelpers.cmake:406 (message): Could not find target Qt6::BundledLibYaml to query its package name. Defaulting to package name Qt6BundledLibYaml. Consider re-arranging the project structure to ensure the target exists by this point. which were introduced with the integration of dffcc2370e43722afb25d7aec7cd9d6a36f61e03 in qtbase. This happened because we never set and exported the package names for 3rd party bundled libs. So export the package name as well as "is 3rd party lib" value. Amends 6235f7fa62aab5c0e002fa2f93f46508f38b5472 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I25fc1ffef766198974025e0097bced1cca4dd28d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Record used package version for each target dependencyAlexandru Croitor2022-07-011-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: set correct COMPILE_PDB_NAME for static librariesLi Xinwei2022-05-201-4/+4
| | | | | | | | | | | | | | | Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Fix exclusion of QtFoo in QtBarDepends for 3rd party libsAlexandru Croitor2022-02-231-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When configuring a static Qt with the -qt-zlib option and the build system creates a 3rd party header module QtZlib, syncqt does not generate a QtZlib header file that would include all its public headers. Then when the QtSvgDepends header is generated, it would add an #include <QtZlib> which would break compilation of the QtSvg PCH file (which compiles QtSvgDepends). We have logic to exclude addition of headers from regular 3rd party static libraries, but not header only 3rd party libraries. Adjust the code to handle header-only 3rd party libraries, as well as make sure it works across repos by exporting the relevant properties. As a drive-by, also rename and export some other informational properties. Amends af00402d6446c0f8f085a2a482fc83c4318aa457 Amends 6fdeaea24f9035ad53ba2548a9467b3264cf01ad Amends be2745e4788cecb0d3122081e3328e4b66923609 Pick-to: 6.2 6.3 Change-Id: I087f50b193dd845e4a5ec906e8851d63122faf80 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Install 3rdparty headers for static buildsMichal Klocek2022-02-191-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | For static builds we need 3rdparty headers to be installed. Leaf modules like qtwebengine needs 3rdparty libs and header for zlib, freetype, harfbuzz, png, jpeg. Without those the Chromium bundled versions are used, however it might end up badly if qt has already bundled one. Introduce new header only modules with additional arguments for qt_internal_add_module: * EXTERNAL_HEADERS to pick exactly which headers are public * EXTERNAL_HEADERS_DIR to include whole directory preserving the files directory structure Fix qtsync so it keep directory structure for all non-qt modules when syncing headers and do not generate warnings for headers files. Task-number: QTBUG-87154 Task-number: QTBUG-88614 Change-Id: If1c27bf8608791cd4e0a21839d6316a445a96e9f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Allow disabling package version checkAlexandru Croitor2021-10-271-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building Qt repos, all find_package(Qt6) calls request a PROJECT_VERSION version which is set in .cmake.conf via QT_REPO_MODULE_VERSION. This means trying to configure qtsvg from a 6.3 branch using a 6.2 qtbase won't work, because qtsvg will call find_package(Qt6 6.3) and no such Qt6 package version exists. There are certain scenarios where it might be useful to try to do that though. One of them is doing Qt development while locally mixing branches. Another is building a 6.4 QtWebEngine against a 6.2 Qt. Allow to opt out of the version check by configuring each Qt repo with -DQT_NO_PACKAGE_VERSION_CHECK=TRUE. This setting is not recorded and will have to be set again when configuring another repo. The version check will also be disabled by default when configuring with the -developer-build feature. This will be recorded and embedded into each ConfigVersion file. If the version check is disabled, a warning will be shown mentioning the incompatible version of a package that was found but that package will still be accepted. The warning will show both when building Qt or using Qt in a user project. The warnings can be disabled by passing -DQT_NO_PACKAGE_VERSION_INCOMPATIBLE_WARNING=TRUE Furthermore when building a Qt repo, another warning will show when an incompatible package version is detected, to suggest to the Qt builder whether they want to use the incompatible version by disabling the version check. Note that there are no compatibility promises when using mixed non-matching versions. Things might not work. These options are only provided for convenience and their users know what they are doing. Pick-to: 6.2 Fixes: QTBUG-96458 Change-Id: I1a42e0b2a00b73513d776d89a76102ffd9136422 Reviewed-by: Craig Scott <craig.scott@qt.io>
* CMake: Don't propagate -fapplication-extension to user projectsAlexandru Croitor2021-07-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Both the compiler and linker -fapplication-extension flag should only be applied when building Qt's libraries (not executables). It's up to the user project whether their code will be restricted with application-extension-only APIs. In qmake that can be achieved by adding to the qmake project CONFIG += app_extension_api_only In CMake it can be achieved by either adding the compiler and link flags in the project directly (using target_X_options) or by setting the appropriate setting in the Xcode project when using the Xcode generator. Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b Pick-to: 6.2 Task-number: QTBUG-95199 Change-Id: Ie7a764d460a89c7650391abff0fcc5abfcabef64 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Hide QT_USE_BUNDLED_ CACHE variables from GUIAlexey Edelev2021-07-081-2/+2
| | | | | | | | | Make QT_USE_BUNDLED_ INTERNAL to hide them from GUI like QtCreator's CMake configurator. Pick-to: 6.1 6.2 Change-Id: Id9dcee31c69b579bbe38611cabb98e46550b0e89 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Remove some dead installation codeAlexandru Croitor2021-05-251-17/+0
| | | | | | | | It was copy-pasted (presumably from plugin handling code) when initially introduced but was never used. Change-Id: I571738b9f5269ca038f5931a773aa5c2c66aafbc Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Introduce a public qt_add_library functionAlexandru Croitor2021-05-251-74/+115
| | | | | | | | | | | | | | | | | | | | | | Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add _qt_module_interface_name for 3rdparty librariesAlexey Edelev2021-05-231-0/+3
| | | | | | | | | | | Since we add 3rdparty libraries to the set of the Qt modules, they are treated as the Qt modules by the depenedcy helper as well. So give them _qt_module_interface_name to fix dependency helper. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Change-Id: I5898c1c90156de1878aeeef5a0924349b44c50fa Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Build plugin initializers as object libsAlexandru Croitor2021-05-181-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of compiling the plugin initializers as part of a user project, pre-compile them as object libraries while building Qt. The installed object libraries can then be used with target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) so that they are linked into the final executable or shared library via qt module usage requirement propagation. This reduces the build times of user projects. The link line placement of the object files should be correct for all linux-y linkers because the only dependency for the object files is Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that from empirical observations. As a consequence of the recent change not to link plugin initialization object files into static libraries, as well not having to compile the files in user projects, we can get rid of the _qt_internal_disable_static_default_plugins calls in various places. A side note. Consider a user static library (L) that links to a Qt static library (Gui) which provides plugins (platform plugins). If there is an executable (E) that links to (L), with no direct dependency to any other Qt module and the intention is that the executable will automatically get the platform plugin linked, then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage requirements are propagated successfully. This is a limitation of using target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which will propagate object files across static libraries only if qt_module is linked publicly. One could try to use target_link_libraries(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which preserves the linker arguments across static libs even if qt_module is linked privately, but unfortunately CMake will lose dependency information on Core, which means the object files might be placed in the wrong place on the link line. As far as I know this is a limitation of CMake that can't be worked around at the moment. Note this behavior was present before this change as well. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Refactor qt_internal_add_plugin() and qt6_add_plugin()Craig Scott2021-03-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add plugins to Qt tools and executables for static buildsCraig Scott2021-03-231-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In static builds, we cannot allow any part of the main build to make a call to find_package(Qt6...) where such a call may load a Qt6*Plugins.cmake file. That would add additional dependencies to the main module targets, setting up a circular dependency in the set of *Config.cmake files which cannot be resolved. This scenario would be triggered by per-repo builds or user projects. But Qt's tools and other executables still need to load some plugins in static builds. Sometimes a platform plugin may be enough, other times we may want all supportable plugins (e.g. Qt Designer). Therefore, add all plugins we can identify as relevant for an executable that is part of the Qt build, but add them directly to the executable without affecting the linking relationships between the main module libraries. Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in top level builds because there should be no difference between per-repo and top level builds any more (as far as linking static plugins is concerned). Examples that build as part of the main build will still build successfully after this change, but they will not run if they require a platform plugin. Examples need to be moved out to a separate build where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS set to TRUE to be runnable (see QTBUG-90820). Fixes: QTBUG-91915 Pick-to: 6.1 Change-Id: I8088baddb54e394ca111b103313596d6743570ba Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Clear non-relevant CMake compiler flagsAlexey Edelev2021-01-271-1/+3
| | | | | | | | | | | | | | | | Add internal function to cleanup compiler flags out of the CMAKE_xxx_FLAGS_xxx variables. Use introduced interface to clear the '/EHsc' flag for the MSVC compiler family. This adjusts the CMake behavior to the qmake one. Change the 'EXCEPTIONS' option handling in helper functions. Add ability to add enabling and disabling exception flags. Previously it was only possible to add disabling exception flags. Fixes: QTBUG-89952 Change-Id: I60d47660a97ae9b5a1d1f4107d352c9e97890144 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Disable static plugin imports for non-executable targetsAlexandru Croitor2020-12-081-0/+22
| | | | | | | | | | | | | | There is no point in generating cpp files containing Q_IMPORT_PLUGIN() macro calls for non-executable targets like modules, plugins and object libraries in a static Qt build. It causes unnecessary compiling of 10+ files for each of those targets. In a static Qt build, plugin imports should only be done for executables, tools and applications. Pick-to: 6.0 Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Enable NEW policies by CMake version with a global defaultCraig Scott2020-12-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't install pri and debug info for bundled harfbuzz and pcre2Li Xinwei2020-11-201-11/+11
| | | | | | | | | | | For shared build, Qt6BundledHarfbuzz.lib and Qt6BundledPcre2.lib are not installed. But their pri files(qt_ext_harfbuzz.pri, qt_ext_pcre2.pri) and debug info files(Qt6BundledHarfbuzz.pdb, Qt6BundledPcre2.pdb) are still installed. These files should not be installed too. Pick-to: 6.0.0 6.0 Change-Id: I3e54bec01d94ee3897b485a982d01b24edc602aa Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake Build: Enable separate debug info for all target typesCristian Adam2020-11-041-0/+6
| | | | | | | | | | | | | Now all shared libraries and executables will get .debug files on the platforms that support FEATURE_separate_debug_info With the directory property _qt_skip_separate_debug_info certain targets can retain the debug symbols in the binary e.g. lupdate with MinGW 8.1.0 will cause objcopy / strip to fail. Fixes: QTBUG-87015 Change-Id: I03b106e68ef0a42011d1ba641e6f686b2e7b7fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Don't limit qt_internal_add_cmake_library to testsTor Arne Vestbø2020-10-281-1/+1
| | | | | Change-Id: I2dbe8075de6704a7a6557b877dc279a4b4cddd54 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Install PDB debug info for MSVC buildsAlexandru Croitor2020-10-061-0/+1
| | | | | | | | | | | | | | | Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix build of Release user projects against RelWithDebInfo QtJoerg Bornemann2020-09-251-0/+6
| | | | | | | | | | | | | | | | | | | | | Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Rename internal functions to contain qt_internalAlexandru Croitor2020-09-231-4/+4
| | | | | | | | | | Offer compatibility wrapper functions until we update all of the Qt repos to use the new names. Task-number: QTBUG-86815 Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Split QtBuild.cmake into smaller filesAlexandru Croitor2020-08-141-0/+263
QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-11-23 22:28:29 +0000