summaryrefslogtreecommitdiffstats
path: root/cmake/QtModuleHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Remove unused FEATURE_DEPENDENCIES optionAlexandru Croitor2025-11-201-3/+0
| | | | | | | | | | | | | | | | Remove the unused PUBLIC_DEPENDENCIES / PRIVATE_DEPENDENCIES options from qt_feature_module_begin. They don't have any effect. They were used a long time ago in the past before b7b4af575f119ddabe0f7f3e8c075306b347dda3 landed. Remove the FEATURE_DEPENDENCIES option from qt_internal_add_module / add_plugin / extend_target which forwarded to qt_feature_module_begin. Remove the only usage of FEATURE_DEPENDENCIES from the Gui module. Pick-to: 6.8 6.10 Change-Id: I46f12ac859b5cf19433b2de4a6f09a22d18a7f4e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Add options to skip generation of some module filesAlexandru Croitor2025-11-201-5/+31
| | | | | | | | | | | | | | | Some qt_internal_add_module calls create INTERFACE libraries just to carry information like recorded feature values. These libraries should not have additional files like pkg-config files, qmake .pri and .prl files, or module json files. Add a few new options to qt_internal_add_module to allow disabling the generation of these files on a per-module basis. Pick-to: 6.8 6.10 Change-Id: I471a8a71fe5a94235dcb0ec9efc69ef14658a1ac Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Rename TYPE to SBOM_ENTITY_TYPE in SBOM APIAlexandru Croitor2025-09-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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: fix the reduce_relocations testThiago Macieira2025-08-131-11/+15
| | | | | | | | | | | | | | | This test was apparently never properly ported from qmake, because it forgot to check that the linker supports the flag that it meant to use. Fix it by checking for both flags that we need to support the feature, -Bsymbolic-functions and --dynamic-list. This also fixes the incorrect GCC checks, since this is not a compiler feature, but a linker one. Pick-to: 6.10 Change-Id: I92f6bb1e213e335b5c94fffd3ea509c53b847ee6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Tim Blechmann <tim.blechmann@qt.io>
* CMake: support reduced relocations for namespaced QtTim Blechmann2025-08-141-0/+2
| | | | | | | | | | | | The dynlist files passed to the linker have hardcoded function names that do not take namespacing into account. We therefore generate the dynlist files at configure time from the qt namespace. Task-number: QTBUG-138543 Pick-to: 6.10 Change-Id: Ib3521b83942548cb09c11687e1701c2308f9d148 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't install incomplete Qt6BundledFoo packagesJoerg Bornemann2025-08-131-0/+6
| | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Warn about public modules linking to private modules publiclyAlexandru Croitor2025-07-311-0/+21
| | | | | | | | | | | | | | | | | | | Public modules should not link publicly to private modules. Doing that creates a public dependency on the private module CMake packages. That forces user projects to automatically find the private packages and make Private module targets and headers available to the user project, without them explicitly opting in. When building a developer-build Qt, show a warning when such a case is detected, so that each repository can be fixed to not do this. Add an opt out QT_WARN_PUBLIC_MODULE_LINKS_PRIVATE_MODULES_PUBLICLY variable which can be set to OFF in the repo '.cmake.conf' file. Pick-to: 6.10 Task-number: QTBUG-138712 Change-Id: I4cc5fba1a18f60c94b5e4c3f17432eba397029c6 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake:Android: add ANDROID_PLATFORM to Core.jsonSheree Morphett2025-07-031-2/+3
| | | | | | | | | Add ANDROID_PLATFORM to Core.json so that Qt Creator can pick it up. Task-number: QTCREATORBUG-32932 Pick-to: 6.10 6.9 6.8 Change-Id: I4a84ba74f43d68e2aef6c31f93c8c94a46bd406a Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Replace `QT_NO_CREATE_TARGETS` with an automated and scoped logicCristian Le2025-06-271-0/+21
| | | | | | | | | | 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>
* Add the Json schema for the modules.jsonCristian Le2025-06-261-0/+1
| | | | | Change-Id: Id2c821a9e0abd067a8eb66348baff0f2f657bd75 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: remove variables that doesn't existZhao Yuhang2025-06-251-1/+0
| | | | | | | | | | | | This "deprecation_define" variable existed before, but after some commit the logic that set this variable has all been removed, so it's always empty and become useless now. I've searched for this variable globally in whole qtbase repo and can't find anywhere set or use this variable, so I think it's safe to remove these leftovers. Change-Id: If89c40570f24f5b845d17966da8a83746473152f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Drop CMAKE_SYSTEM_VERSION from modules json if LinuxCristian Le2025-06-231-1/+5
| | | | | | | | | | | | | | In order to make the project build reproducible it should not record transient information of the build host. The linux kernel is not encoded in the source, and the value from the modules.json does not seem to be used anywhere, so we can drop it for now. Fixes: QTBUG-136060 Change-Id: Ic157d66d47040b080e9121fd065a8d60d489f586 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Introduce _qt_internal_append_cmake_configure_dependsAlexey Edelev2025-06-121-1/+1
| | | | | | | | | | | | The function append the unique entries to the CMAKE_CONFIGURE_DEPENDS property. This suppress the ninja recompat issue, which complains about the duplicated entries in that come from the CMAKE_CONFIGURE_DEPENDS property. It's likely the CMake issue, but we may work around it. Pick-to: 6.8 6.9 6.10 Change-Id: I2f10834b0dca3d2aa08fe13fba69849e97fa77d0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Introduce qt_internal_set_module_transitive_propertiesAlexey Edelev2025-05-311-0/+97
| | | | | | | | | | | | | The function sets properties on target that then are propagated transitively. This only works with Qt modules, but can be extended for other Qt targets later. These transitive properties not necessarly require Qt be built using CMake versions supporting transitive properties(>= 3.30). Properties are stored and exported within the Qt module unconditionally and can be used in user projects, if CMake version allows this. Change-Id: I1ff6f1099753784c721dc1e3cd972dcd9dafedc4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Introduce Qt<Module>TransitiveExtras.cmake for Qt modulesAlexey Edelev2025-05-311-0/+26
| | | | | | | | | | | | | | This file sets the transitive module properties provided by Qt Module that is built using CMake versions < 3.30. The idea is to not limit user projects capabilities and allow using transitive Qt Module properties if user CMake version allows it. If Qt Modules are built using CMake versions >= 3.30 this code is noop, since values are stored directly in the respective INTERFACE_properties. Change-Id: I5a0bc0aa4f79a04c81dfa0fee1d37cfee5935b0f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix dbus and vk headers to be excluded from doc generationAlexandru Croitor2025-03-201-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, if someone called ninja Gui_generate_docs, it would implicitly depend on sync_all_public_headers -> Gui_sync_headers which would generate dbus headers. This caused trouble with the new 'build doc tools from qttools/dev/HEAD' approach, because an older pre-built dbus tool might be passed a newer option when integrating a qtbase change that passes the new option. To avoid that, we now filter out the dbus headers from the list of headers that should be processed by syncqt when building a documentation target. We do the same for the qvkgen generated headers. This also removes the dependency on the ${target}_sync_headers target, which means there is a potential issue when someone manually calls `ninja sync_all_public_headers Gui_sync_headers` or something like it, which would spawn two syncqt processes that access the same files concurrently. This is an edge case that should not happen, but if it ends up happening, we will have to implement some kind of lock file mechanism. Pick-to: 6.8 6.9 Fixes: QTBUG-134672 Task-number: QTBUG-128730 Change-Id: I9061f9495e2faa77744f5f5c0de8fedd362ba228 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix generation of precompiled headers in per-repo Qt buildsJoerg Bornemann2025-03-201-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | When a Qt module Foo links against a Qt module Bar then we add the ${QT_BUILD_DIR}/include/QtBar/QtBar header to the list of precompiled header files. However, this only works if Foo and Bar are in the same build system, e.g. in the same repository or in a top-level build. For example, the QtCore header was never precompiled when in a per-repo build of QtSvg. Now, we determine whether Foo and Bar are in the same build system. If they are, we proceed as before. Otherwise, we calculate the QtBar header's location from the following data: - the location of Qt6BarConfig.cmake - the relative path to Bar's include directory The Q*Application tests' project files had to be adjusted to use NO_PCH_SOURCES now, because they use the source file apphelper_plugin.cpp that specifically checks that pre-compiled headers are not used for its compilation. Fixes: QTBUG-134424 Change-Id: I04ede51e4d853e8b813f660f29be8cfeb684c0b2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Remove unused variable from qt_internal_add_moduleJoerg Bornemann2025-03-171-5/+0
| | | | | | | | | The targets_to_export variable is unused. Remove it. Amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Change-Id: I67f171738532c274e2b4fe8943fffd0c03cce55a Reviewed-by: Alexey Edelev <alexey.edelev@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: Warn on creation of private modules without private headersJoerg Bornemann2025-03-131-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | Private modules without private headers don't make much sense and needlessly create CMake packages and QMake module pri files. In qt_finalize_module we check whether the module has any private headers. But the private module was already created before in qt_internal_add_module. Moving the creation of the private module or the CMake package files to the finalization phase would be a bigger refactoring that's probably not worth the hassle. An easier way to avoid the package creation issue is to mandate that a Qt module must be created with NO_PRIVATE_MODULE if it doesn't have any private headers. Add a warning if a Qt module without private headers is created without NO_PRIVATE_MODULE. Also warn if a Qt module with private headers is created with NO_PRIVATE_MODULE. This allows us to easily spot the places where NO_PRIVATE_MODULE is missing. Task-number: QTBUG-132526 Change-Id: I897f25790a99eaa320c39cd8c2728f26bceb824e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix -no-prefix build with CMake < 3.26 on macOSJoerg Bornemann2025-03-071-6/+9
| | | | | | | | | | | | | | | | | | On macOS, Core has plugins that link against CorePrivate. In a non-prefix build, user projects failed on find_package(Qt6 REQUIRED COMPONENTS Core), because CorePrivate is required for these plugins in a non-prefix build, but it's not automatically pulled in. This is only an issue for CMake < 3.26, because these older CMake versions lack the BUILD_LOCAL_INTERFACE generator expression. Fix this by pulling in the private modules for non-prefix builds when using CMake < 3.26. Also, issue a warning in this situation. Fixes: QTBUG-134407 Change-Id: I7f182c9518686390e657663b452cad8101d870a2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Make `AdditionalTargetInfo.cmake` optionalCristian Le2025-02-251-1/+0
| | | | | | | | Pick-to: 6.8 6.9 Change-Id: I8b8d6383b6c50e9403bc90e76d4da8eb6c314854 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add interface to install `EXTRA_CMAKE_FILES` in other pathsCristian Le2025-02-251-3/+11
| | | | | | | | | | If the source file sets `QT_INSTALL_PATH` property, it will install the CMake files in the relative path starting from the config-dir in both the build and install paths. Pick-to: 6.8 6.9 Change-Id: I86197d62bfac96f9c142d8abfe85c9b6f6f1a527 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Revert "CMake: Stop-gap fix for Qml user projects"Joerg Bornemann2025-02-231-4/+0
| | | | | | | | | | The issue was fixed by commit 3b0dab39d047cfc676a75915ce606cbd4d43a83d in qtdeclarative. This reverts commit 4d95b6dccdd7772594bdb5f0c404585f16a4dc9c. Change-Id: Ic7d78e740d1789a4ebd1d4c8c91d18846e005dfe Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Change the `GENERATED` property of module export headerCristian Le2025-02-171-4/+6
| | | | | | | Use a more specific property Change-Id: I68702fd66902273b108f7f207f583f73693087ed Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Use `_qt_internal_path_is_prefix`Cristian Le2025-02-171-10/+5
| | | | | | Change-Id: I3eeb514c33340956328eff33409dfa2899023eb5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Use `_qt_internal_set_source_file_generated`Cristian Le2025-02-171-5/+9
| | | | | | | | | Migrate implementations that set `GENERATED` source property Task-number: QTBUG-125077 Pick-to: 6.9 Change-Id: Ia77ecf8422bf3983f7746c26e5a9994d1f6415f2 Reviewed-by: Alexey Edelev <alexey.edelev@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: Stop-gap fix for Qml user projectsJoerg Bornemann2025-01-311-0/+4
| | | | | | | | | | | | | | | | | We temporarily enable automatic find_package of Qt6FooPrivate whenever Qt6Foo is find_package'ed, because 1. Currently, Qml user projects are broken unless they set QT_FIND_PRIVATE_MODULES=ON. 2. The fix for qtdeclarative depends on the submodule update. 3. The submodule update is blocked by QTBUG-133352. This fixes Qml user projects for people who use latest dev in all repos. Change-Id: I2c2907e531e908515b51eae1ea90df555e40871e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add a way to mark modules as "load the private module too"Joerg Bornemann2025-01-281-0/+17
| | | | | | | | | | | | | Add FIND_PRIVATE_MODULE argument to qt_internal_add_module. If this argument is set for Qt6Foo, then find_package(Qt6Foo) will also find_package(Qt6FooPrivate). This should only be necessary in exceptional cases like Qt6Qml where Qt6QmlPrivate is used unconditionally. Task-number: QTBUG-87776 Change-Id: I8d6fbd0624c0008fc42294ff2d2ed36848963508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Provide a way to find all available Qt module packagesAlexandru Croitor2025-01-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | A project might want to find_package all available (installed) Qt CMake packages that contain qt modules. A use case might be a qml app that needs to link to all of Qt, and support showing qml files that can load any Qt qml module. Add a new Qt6 COMPONENT called ALL_QT_MODULES. It can be used like this: find_package(Qt6 COMPONENTS ALL_QT_MODULES). The implementation will find all installed Qt modules by globbing over all json files installed in $qt/modules dir, and treat the file names as package names. It will then tell Qt6 to find_package each of those packages. Pick-to: 6.8 6.9 Change-Id: I89242307438576a0cbb3cdca80a9cb72818b6035 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Only load Qt6FooPrivate automatically when building QtJoerg Bornemann2025-01-241-6/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Replace qt_record_extra_qt_package_dependency with ↵Alexey Edelev2025-01-201-1/+1
| | | | | | | | | | | | | | | | | qt_register_target_dependencies qt_register_target_dependencies does the same thing as qt_record_extra_qt_package_dependency but in more convenient way. Update the qt_register_target_dependencies signature and adjust naming, it now accepts PUBLIC and PRIVATE multi-value arguments and called qt_internal_register_target_dependencies. Use it and deprecate qt_record_extra_qt_package_dependency. Pick-to: 6.5 6.8 6.9 Change-Id: I0594cf699ec1e3af7210dd7450fa3f81c1f565ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Simplify Qt6FooPrivate -> Qt6Foo package dependency setupJoerg Bornemann2025-01-081-0/+3
| | | | | | | | | | | | | This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Remove the EXTRA_PACKAGE_DEPENDENCIES argument that was added in mentioned commit, and use the qt_register_target_dependencies function instead to add the package dependency Qt6FooPrivate -> Qt6Foo. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I08a48954576dc3c0b6fde809f90d2022201d7eb0 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Split off private module config packagesJoerg Bornemann2024-12-191-48/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Add QPA information to modules/Gui.jsonJoerg Bornemann2024-11-141-0/+8
| | | | | | | | The list of available QPA platforms and the default QPA platform is now available in modules/Gui.json. Change-Id: I059286d80c8507080d5ec3d790cf8ea22c5daddd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Rework the module JSON filesJoerg Bornemann2024-11-141-18/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The linked issue reports a lack of information about multi-arch builds of Qt on Apple platforms. In order to add the information we take the chance to rework the structure of the module JSON files and make the format future-proof for when we'll create multi-platform bundles (xcframeworks). The new module JSON files differ from the old ones in the following points: - The 'schema_version' key denotes the version of the module JSON file schema. It's set to 2. - The 'built_with' key was removed. The relevant information was moved to 'platforms' entries. - The 'cross_compiled' key was removed. It was only used to determine whether a Qt build contained host tools. Since one needs the actual path to host tools anyway, it's more useful to query qtpaths for that information. - A 'platforms' key was added that holds a list of target platforms. Currently, only an iOS simulator-and-device build has more than one platform: "name": "iOS", "variant": "iphoneos", and "name": "iOS", "variant": "iphonesimulator", - A 'targets' key was added under each 'platforms' entry. This contains information about the target architecture(s) and other relevant properties. - The 'android' key was flattened and moved to the 'targets' entries. [ChangeLog][CMake] The structure of the module JSON files, e.g. modules/Core.json has been reworked. Consumers of these files need to be updated. A 'schema_version' key was added and set to 2 to ease reading different versions of these files. Fixes: QTBUG-129996 Change-Id: I5a6ac9746aa19ad0ee9f2d020bf7486bdac28226 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add the QT_PLUGIN_TARGETS transitive compile propertyAlexey Edelev2024-11-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | Use the freshly introduced TRANSITIVE_COMPILE_PROPERTIES functionality to handle plugin targets across Qt modules. This will allow accessing all Qt plugins that are required for targets at once, without the need of iterating over the Qt targets at configure time. This mechanism duplicates the already existing plugin collecting routines, since we still need to support the older CMake version. This commit only introduces the helper functions and plugins collecting, but doesn't use the QT_PLUGIN_TARGETS anywhere. We don't use the direct export of properties by CMake but still rely on plugin collecting mechanism we use before to cover the situation when Qt is built using CMake versions < 3.30 and then is used to build user applications with CMake versions >= 3.30. Task-number: QTBUG-129302 Change-Id: Id3b516b92e8e16552d46b2c702b76c571366f2b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix CMP0177 warningsJoerg Bornemann2024-11-081-0/+3
| | | | | | | | | | CMake 3.31 introduced CMP0177 that warns if an install destination is a not-normalized path. Fix this by normalizing the offending paths before using them. Pick-to: 6.8 Change-Id: I1586bf192a4fd26108aa0448431f19e69df8aacd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix CMP0174 warningsJoerg Bornemann2024-11-081-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Increase static library link multiplicity for VxWorks to 3Alexandru Croitor2024-10-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It appears that the VxWorks linker behaves similarly to GNU ld, where the order of link libraries on the command line matters. Our plugin linking system is not ideal (due cycles like Gui -> plugin -> Gui, or Qml -> qml plugin -> Qml), and can change the order of the linked libraries on the command line. Due to that, some of the qtdeclarative tests fail to link with undefined symbols in Qml. Apply the same workaround we did for Linux, which is to increase the LINK_INTERFACE_MULTIPLICITY of Qt modules to 3, effectively ensuring that each qt module static library appears at least 3 times on the link line, given the linker more chances to find relevant symbols. Amends 58a7e4f0bc5e9290cc205762d51adc5806b034fd More in detail reasoning explained in commit message of 69b27e09f55e63a713ca8b14f162d4f449c8dfff in qtquick3d Pick-to: 6.8 Fixes: QTBUG-129113 Task-number: QTBUG-83498 Change-Id: I7ac5665d4dd2865584ba1c96d51fd311ef224d10 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: fix value api_version in Core.jsonAssam Boudjelthia2024-10-171-1/+1
| | | | | | | | | | | Amends 8d2d5563b5a02c6c3dee23c35cda4efcfb87a33f. Core.json was using the older name variable name QT_ANDROID_API_VERSION instead of the new name QT_ANDROID_API_USED_FOR_JAVA. Change-Id: I1c995818331f45eedb07114276b6aba0f6577c15 Reviewed-by: Shyamnath Premnadh <Shyamnath.Premnadh@qt.io>
* Make per-repos WARNINGS_ARE_ERRORS workAlexey Edelev2024-09-121-1/+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-1/+7
| | | | | | | | | | 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-6/+14
| | | | | | | | | | | | | | | | | | | | | | 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/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix the arg_HEADER_MODULE conditionAlexey Edelev2024-06-121-1/+1
| | | | | | | | Use the variable name but not the unwrapped value. Pick-to: 6.5 6.7 6.8 Change-Id: Ie392a4875fe412b8eb273a457a83cd08cd9f5e15 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove GENERATE_CPP_EXPORTS argumentAlexey Edelev2024-06-121-3/+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>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-16 14:46:03 +0000