summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Automatically generate a vcpkg manifestJoerg Bornemann3 days6-10/+701
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ChangeLog][configure] Added a -generate-vcpkg-manifest configure option. This generates a vcpkg.json file in the build directory. To just generate the manifest without configuring Qt, run configure with -generate-vcpkg-manifest -dry-run. [ChangeLog][configure] When configuring with -vcpkg, generate a vcpkg manifest file in the build directory, and set VCPKG_MANIFEST_DIR to the build directory to use that manifest file. You can turn off the manifest generation with -no-generate-vcpkg-manifest. You can turn off setting the manifest directory by passing -- -UVCPKG_MANIFEST_DIR to configure. Configuring with pure CMake won't generate a vcpkg.json. This patch adds a low-level CMake API for creating vcpkg manifests in QtVcpkgManifestHelpers.cmake. The functions qt_find_package and qt_feature gained arguments for creating dependencies in the manifest and add them to features. This adds a package dependency (not guarded by any feature): qt_find_package(WrapSystemFreetype 2.2.0 MODULE ... VCPKG_PORT freetype VCPKG_VERSION 2.3.4 ) This adds a package dependency `freetype` to the feature `freetype`: qt_find_package(WrapSystemFreetype 2.2.0 MODULE ... VCPKG_PORT freetype VCPKG_ADD_TO_FEATURE freetype ) This adds a feature `freetype` with `gui` as its "parent dependency": qt_vcpkg_scope(gui) ... qt_feature("freetype" PUBLIC PRIVATE SECTION "Fonts" LABEL "FreeType" PURPOSE "Supports the FreeType 2 font engine (and its supported font formats)." ) If features are turned on/off via configure arguments, we set the CMake variables VCPKG_MANIFEST_NO_DEFAULT to ON and VCPKG_MANIFEST_FEATURES to the list of corresponding vcpkg features to only install libraries that are needed for the build. For a per-repo build, we create a vcpkg.json with dependencies only for that repository. For a top-level build, we create a vcpkg.json with all dependencies of all repositories, excluding those that have been skipped (with configure's -skip argument). Task-number: QTBUG-73760 Change-Id: I6cc449d712f32d9e564acecaede5a7b31f309a8c Reviewed-by: Alexandru Croitor <[email protected]>
* configure: Add -dry-run optionJoerg Bornemann3 days1-0/+19
| | | | | | | | | This option prints the effective CMake command but doesn't execute it. This is useful for debugging or for triggering configure side effects without actually calling CMake. Change-Id: I2f2831f4a41bbcf6cd3117bd4a3e773577447975 Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Allow adding tools dependencies on INTERFACE librariesAlexandru Croitor4 days2-8/+6
| | | | | | | | | | | | | | | | Rename the QT_EXTRA_TOOLS_PACKAGE_DEPENDENCIES property to _qt_extra_tools_package_dependencies so we can set it also on INTERFACE libraries with older CMake versions. Remove the check for is_interface_lib in qt_internal_create_module_depends_file so we can add tool package dependencies with qt_record_extra_qt_main_tools_package_dependency on INTERFACE libraries as well. Use the new feature in the StandaloneToolsPackage RunCMake test. Change-Id: Ia36acf785f5f8512580dfcd3e599a5e704f9422e Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Allow creating a standalone Tools package without a moduleAlexandru Croitor4 days8-65/+406
| | | | | | | | | | | | | | | | | Add a new qt_internal_add_tools_package function to allow creating a standalone Tools cmake package. It can be useful for a repo which might build e.g. an arch-independent java tool exposed by an IMPORTED executable, but has no associated C++ Qt module. Also add a qt_internal_record_tools_package_extra_third_party_dependency function to allow looking up additional third party cmake packages when finding the tool package. Change-Id: I46f5fb9f7a361ecf4018f0fc1ed0a1f8ecf12df3 Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Pass WORKING_DIRECTORY to add_test only if it's non emptyMorten Sørvig4 days1-5/+20
| | | | | | | | | Otherwise when targeting WASM cmake shows a lot of Policy CMP0174 is not set warnings. Pick-to: 6.8 6.10 Change-Id: I8ba99e9a87b42c17ea4c1afce50cbfb156ac5b1c Reviewed-by: Alexandru Croitor <[email protected]>
* CMake: Look for packages in Standalone Tests Config files individuallyAlexandru Croitor5 days3-12/+44
| | | | | | | | | | | So that cmake has the opportunity to show a warning for each missing component, not just the first one. Amends dd1030a4501ca067e96f50085c8cfda19d85afd4 Pick-to: 6.8 6.10 Change-Id: I850d5c216437486aa5eb83543ac9a2e024b4be9f Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Fix exporting INTERFACE_ feature values in multi-config buildsAlexandru Croitor5 days2-55/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The build system used qt_internal_add_genex_properties_export to export properties containing feature values like QT_ENABLED_PUBLIC_FEATURES for interface library targets. This worked fine for single config builds, but fails when configuring standalone tests with a multi-config build. The problem is that in multi-config builds, the exported values are wrapped with genexes, which breaks feature checks of the form if(QT_FEATURE_foo). Rename the qt_internal_add_genex_properties_export function to qt_internal_add_custom_properties_to_export and extend it to support two kinds of properties: - Properties that may contain genexes and need special handling in multi-config builds (e.g. paths) - Properties that will never contain genexes (e.g. feature values) Use the latter kind for exporting the feature properties. Amends e6984bc55b84278c1eb8813a9bfb5e59fe3781be Amends d51d7d4d5c87c37ac0b35e15857761e5e5815cc7 Amends 461020a86aa5822325edba9ec565db39e5df8092 Amends b56dc55c3a5c4164ad84fd61c44638a3cb196978 Pick-to: 6.8 6.10 Task-number: QTBUG-139986 Change-Id: I5017f9775268e939cf06f05a957a91883e2a5919 Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Create macOS framework basic structure at configure timeJoerg Bornemann9 days1-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | CMake creates the directory structure of frameworks at generation time. It also creates a QtFoo.framework/Headers symlink if at least one header file is marked as PUBLIC_HEADER. Due to Qt's special layout of the include directory (e.g. private headers in .../6.7.8/QtFoo/private) we don't use the PUBLIC_HEADER property. In the past we had a hack that added a fake header that was marked as PUBLIC_HEADER. That hack was reverted by commit a966d7be48d9b419195a8916e307f84487140839. Since then we created the Headers symlink at build time. Creating the link at build time however means that you have to build all targets of a Qt repo to properly use it. For example, building just Core (and necessary tools) of qtbase and then configuring qtdeclarative did not work anymore, because QtGui.framework/Headers was inexistent but referenced in QtGui's imported target. This patch creates the Headers link and necessary directory structure already at configure time. Fixes: QTBUG-142119 Change-Id: I1da17604bcfd1a593cca5f2f396229937f131011 Reviewed-by: Alexandru Croitor <[email protected]> Reviewed-by: Tor Arne Vestbø <[email protected]>
* CMake: Remove unused FEATURE_DEPENDENCIES optionAlexandru Croitor11 days4-9/+1
| | | | | | | | | | | | | | | | 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 <[email protected]>
* CMake: Skip creating feature header files if NO_HEADERS is specifiedAlexandru Croitor11 days1-7/+18
| | | | | | | | | | | | | | | | | If NO_HEADERS option is specified to qt_feature_module_begin(), skip generating the public and private qfoo_config.h and qfoo_config_p.h files. We can't tie this behavior to the NO_MODULE option, because in the qtbase GlobalConfig case, we specify NO_MODULE but still expect the headers to be created. Also allow not specifying the PUBLIC_FILE and PRIVATE_FILE arguments when NO_HEADERS is specified. Pick-to: 6.8 6.10 Change-Id: I006f35d269910d13899827d4149d4c060c3d006a Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Clean up cmake_parse_arguments use in qt_feature_module_beginAlexandru Croitor11 days1-8/+23
| | | | | | | | | | | And qt_feature_module_begin. Break the options into variables. Use the PARSE_ARGV form. Pick-to: 6.8 6.10 Change-Id: I227d382c797e4570f6e3b644ad10801d6d97440b Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Allow opting out of installing the cmake/Find*.cmake scriptsAlexandru Croitor11 days1-1/+2
| | | | | | | | | | | By setting the QT_NO_INSTALL_CMAKE_DIR_FIND_SCRIPTS variable to TRUE in a place like the repo .cmake.conf file. A repo can then decide itself which files should be installed. Pick-to: 6.8 6.10 Change-Id: I4146232f3d95f7ad0ee36f7f6d643b87b185eb6d Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Add options to skip generation of some module filesAlexandru Croitor11 days1-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 <[email protected]>
* CMake: fix correct jar paths for in-tree builds for JavaDocElias Toivola13 days1-14/+18
| | | | | | | | | | | | | | Using only 'if(PROJECT_NAME STREQUAL "QtBase")' condition fails in-tree builds to not getting a correct path to Qt6Android.jar. Add QT_BUILDING_QT to the condition to fix it. Also remove the use of QtBase_VERSION_MAJOR variable and instead use QT_CMAKE_EXPORT_NAMESPACE to get the Qt major version in in-tree builds. This amends f594f4735b76fde0d3e8fa201ee9ba5c720ac781 Change-Id: I411bb9526f762e84516ae5fbcf565ae82740818e Reviewed-by: Assam Boudjelthia <[email protected]>
* CMake: Fix rcc big resource feature in in-tree example buildsAlexandru Croitor14 days1-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | qt6_add_big_resources creates a helper object library using _qt_internal_add_rcc_pass2 and disables AUTOMOC and AUTOUIC for it. qt_examples_build_end collects all targets created in the examples subdirectory, an enables AUTOMOC and AUTOUIC for them, to avoid some top-level build issues. If an example uses qt6_add_big_resources, then during an in-tree example build, AUTOMOC is re-enabled for the helper object library. That causes build errors due to $<TARGET_OBJECTS:obj_lib> usage in _qt_internal_add_rcc_pass2 expanding also to a mocs_compilation.cpp file and passing a semicolon separated list to rcc --temp option. Set a _qt_internal_is_rcc_pass2_obj_lib property on the object library, and skip re-enabling AUTOMOC and AUTOUIC for it when querying for in qt_examples_build_end. This allows using qt6_add_big_resources in examples without causing build errors. Pick-to: 6.8 6.10 Change-Id: Ib22f77b683757f0981b3ab788edb63bb9e74f67a Reviewed-by: Joerg Bornemann <[email protected]>
* cmake: remove Clang 14 -Wno-error flagsMarc Mutz2025-11-151-6/+0
| | | | | | | | | | | It should be ample time to get these fixed, and I don't remember seeing them anymore recently, so remove them again. Pick-to: 6.10 Change-Id: Icefe080b3106b7facd5a3b270ee338e971731065 Reviewed-by: Volker Hilsheimer <[email protected]> Reviewed-by: Thiago Macieira <[email protected]> Reviewed-by: Alexandru Croitor <[email protected]>
* cmake: remove the C++20 enum-related -Wno-error flagsMarc Mutz2025-11-151-7/+0
| | | | | | | | | | | | I haven't seen these warnings in a long time, and we added mitigation macros¹ to re-enable mixed-mode enum operations for selected Qt APIs, so there's no reason to keep these -Werror's suppressed. ¹ 78073f8ab688f1dc2ede939984ec347c0867de18 Pick-to: 6.10 Change-Id: Ie12047a3f4bcb24390f722b4c4d96a41ef55bccf Reviewed-by: Volker Hilsheimer <[email protected]>
* configure: Simplify handling of the -make and -nomake optionsJoerg Bornemann2025-11-141-13/+3
| | | | | | | | | | | | | | | | | | | | | | | Remove the options '-make libs'. This was doing nothing. We don't have a QT_BUILD_LIBS variable. Remove the option '-make tools'. This was doing nothing. We could map this to QT_FORCE_BUILD_TOOLS=ON, but this would be confusing for desktop builds, because QT_FORCE_BUILD_TOOLS=ON yields an error if QT_HOST_TOOLS is not set. Remove the option '-nomake tools'. This was printing a "not yet implemented warning" without any further effect. This could be mapped to QT_FORCE_BUILD_TOOLS=OFF but people expect different behavior from this option (e.g. disabling all apps). The list of allowed values for -make and -nomake is now in one location: qt_cmdline.cmake, and the superfluous handling of unknown input has been removed from QtProcessConfigureArgs.cmake. Every value of -make / -nomake now maps simply to QT_BUILD_<part>=ON/OFF. Change-Id: I251dd6185d6ae1f22c90b2b8443ba008a6da01f1 Reviewed-by: Alexandru Croitor <[email protected]>
* Add qtbase Qt6Android.jar to class-pathElias Toivola2025-11-131-10/+92
| | | | | | | | | | | | This way qtdeclarative can detect class objects from qtbase when generating Java docs. Fixes: QTBUG-140073 Change-Id: I5294f56634db63dfd9c8526e206c00534da130cb Reviewed-by: Nicholas Bennett <[email protected]> Reviewed-by: Joerg Bornemann <[email protected]> Reviewed-by: Alexandru Croitor <[email protected]> Reviewed-by: Assam Boudjelthia <[email protected]>
* cmake: remove GCC-9 -Wno-error flags added d/t "Qt not ready"Marc Mutz2025-11-121-4/+0
| | | | | | | | | | | | | | | | | | We recently integrated 12313f3ebe00808e9b1c27ddcb49cedf3e09582b containing a bug that would have been caught by the CI if it weren't for a -Wno-error=implicit-fallthrough. Like for fallthroughs, I haven't seen these warnings in a long time in Qt, so turn them back into errors. This episode should show that the -Wno-error approach is wrong, unless we have a clear time limit for lifting it again. If these flags are allowed to linger, mistakes are caught later. Pick-to: 6.10 Change-Id: I97ebc9d17ee97eb5d1d35506b11f0daea7e50c9d Reviewed-by: Thiago Macieira <[email protected]> Reviewed-by: Alexandru Croitor <[email protected]> Reviewed-by: Volker Hilsheimer <[email protected]>
* SBOM: Do not use generic QT CPE for third party modulesKai Köhne2025-11-111-3/+2
| | | | | | | | | Do not claim that third party modules that do not have their own CPE are covered by Qt. This confuses tools like FOSSA. Pick-to: 6.8 6.10 Change-Id: I9a1d0b705caa9be81a43053e1858a8b29e2523aa Reviewed-by: Alexandru Croitor <[email protected]>
* cmake: remove -Wno-error=implicit-fallthroughMarc Mutz2025-11-111-5/+0
| | | | | | | | | | | | | This would have caught at least some of the missing break/returns in 12313f3ebe00808e9b1c27ddcb49cedf3e09582b, and I haven't seen one of these warnings in a long time, so re-enable it. Pick-to: 6.10 Change-Id: I8d6f37e3e5b1e8678225cb018bdd728c512b98cc Reviewed-by: Joerg Bornemann <[email protected]> Reviewed-by: Alexandru Croitor <[email protected]> Reviewed-by: Thiago Macieira <[email protected]> Reviewed-by: Volker Hilsheimer <[email protected]>
* CMake: Only try to find packages dependencies if there are valuesAlexandru Croitor2025-11-064-10/+26
| | | | | | | | | | | | | | | | | | Wrap all _qt_internal_find_third_party_dependencies, _qt_internal_find_qt_dependencies, _qt_internal_find_tool_dependencies calls in if statements that check that the variable holding the dependencies is not empty. Makes it easier for Qt for MCU project to find the Qt6ToolsTools package to make the qdoc target available, without having to copy the cmake files that define e.g. _qt_internal_find_tool_dependencies. It should also speed up configuration a tiny bit. Pick-to: 6.8 6.10 Change-Id: I342f6060e875001d108389170ac05e66e54f0416 Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: pass QT_EXTRA_EXAMPLE_TARGET_DEFINES to examplesTim Blechmann2025-11-061-0/+16
| | | | | | | | | | We want to build examples without any code smell, so we want to have a way to disable legacy APIs. This patch adds handling of QT_EXTRA_EXAMPLE_TARGET_DEFINES, which could potentially be set by the .cmake.conf files Change-Id: I205f87a77f3ff275ed81f93fb967575a83094540 Reviewed-by: Alexandru Croitor <[email protected]>
* cmake: lint examples on developer buildsSami Shalayel2025-11-061-2/+13
| | | | | | | | | Set QT_LINT_EXAMPLES in developer builds to lint examples. This allows to run qmllint in qml examples. Task-number: COIN-571 Change-Id: If998b0b92bf215bd6b0f106049ee0cfa07777129 Reviewed-by: Alexandru Croitor <[email protected]>
* CMake: Add initial Cyclone DX v1.6 SBOM generation supportAlexandru Croitor2025-11-0517-485/+2666
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds initial Cyclone DX v1.6 SBOM generation support for CMake-based Qt projects. Cyclone DX generation is enabled by default for all Qt repos, as long as the required Python dependencies are found. If needed, it can be explicitly enabled by configuring the qt repo project with: -sbom -sbom-cyclonedx-v1_6 or a generic CMake project with -DQT_GENERATE_SBOM=ON -DQT_SBOM_GENERATE_CYDX_V1_6=ON. Disabling can be done with -no-sbom-cyclonedx-v1_6 or -DQT_SBOM_GENERATE_CYDX_V1_6=OFF respectively. Note that if the required python dependencies are not found, the generation will be silently skipped. To ensure cmake configuration fails if SBOM dependencies are missing, pass: -sbom-cyclonedx-v1_6-required or -DQT_SBOM_REQUIRE_GENERATE_CYDX_V1_6=ON To ensure the generated document is valid according to the Cyclone DX schema, pass: -sbom-cyclonedx-v1_6-verify-required or -DQT_SBOM_REQUIRE_VERIFY_CYDX_V1_6=ON Cyclone DX generation requires a Python 3.9 interpreter in PATH and the `cyclonedx-python-lib` and 'tomli' Python packages to be installed. The packages can be installed via pip: pip install 'cyclonedx-python-lib[json-validation]' tomli ideally in a Python virtual environment. If using Python 3.11, tomli is not required. If using Python 3.9 or 3.10, and pip is available, the code will try to use the toml library bundled with pip, in which case `tomli` is not required to be installed separately. Generated Cyclone DX documents are installed in the same `sbom` directory under the prefix. For example when building and installing qtbase, the generated Cyclone DX document will be installed to: $qt_prefix/sbom/qtbase-$version.cdx.json The commit title mentions "minimal" Cyclone DX support. Minimal support means that not all features of the equivalent SPDX generation are implemented. List of implemented features: - CMake target information included as Cyclone DX components with information like name, version, supplier, download location, CPE and PURL - attribution information - license information (ids and texts, without OR/AND structure) - dependencies between components in the same document - dependencies between components in different documents List of missing features: - partial license information (pending v1.7 spec support, currently any license expression with a LicenseRef- has its structure lost, so OR and AND gets removed, and the result is just a flat list of license ids and texts) - binary file, source file, and custom file information (unclear if there's a good way to represent these in the spec) - checksums for components, files and sbom documents (also unclear how to represent, because the spec has a 'hashes' key, but it doesn't say what does it apply to) - relationship information (the Cyclone DX spec doesn't support relationships like DEPENDS_ON or CONTAINS, only dependencies) - detailed component types (only application and library are supported currently) - custom added relationship / dependency info - qtwebengine / Chromium enablers - probably other things Implementation details. Cyclone DX doesn't have a tag:value format like SPDX v2.3, so there isn't an easy way to generate Cyclone DX directly in CMake. Instead, an intermediate TOML file is generated in CMake, which is then fed to a custom Python script that generates the final Cyclone DX document in JSON format. TOML is a much easier format to generate in CMake compared to JSON, and is easy to read for humans and to parse in Python. Note that some of the TOML fields are wrapped in literal multi-line strings aka ''' foo ''' rather than non-literal ones, aka """ foo """. That's to avoid the need for escaping backslashes for content like configure arguments in the description field (Windows is notorious for trailing backslashes in paths). The python script is located in util/sbom/cyclonedx/qt_cyclonedx_generator. It is installed into $qt_prefix/libexec so it can be used for other qt repos and projects. Development of the script is done using the `uv` tool and a pyproject.toml project, but `uv` is not required for installation and usage of the script itself. The script parses the TOML file and serializes the Cyclone DX document into the JSON format, while also syntactically validating it. Cyclone DX and SPDX differences. Cyclone DX has the concept of `bom-ref` which is similar to SPDX IDs and SPDX references. We reuse the SPDX ids like SPDXRef-Package-Foo as bom-refs to allow cross-referencing between repo BOM documents, but it also allows easier comparison with the SPDX documents. SPDX mostly operates on the concept of packages and files, whereas Cyclone DX uses components. We map CMake targets to Cyclone DX components. CycloneDX has one notable difference to SPDX. External dependencies whose full BOM is located in a different document, must still be represented as components in the current document, but with an external BOM link, which is why we need to track such components. This is achieved by exporting the spdx id, bom serial number, etc as CMake target properties, to then partially recreate the components in the currently processed document. Note that the QT_GENERATE_SBOM option is now a main toggle for SBOM generation, instead of being specific to SPDX generation. Various other variables that were SPDX v2.3 specific but had generic names have been deprecated, and new ones introduced to make it clearer that they are SPDX specific, and to allow further evolution for SPDX v3 and Cyclone DX 1.7 while being backwards compatible. Adjusted tests to generate SPDX and Cyclone DX SBOMs together, separately, or not at all. And to check for the existence of the installed sbom files. As well as the computed generation options in case dependencies are missing. [ChangeLog][Build System] A new -sbom-cyclonedx-v1_6 configure option can be used to generate and install a CycloneDX v1.6 SBOM (Software Bill of Materials) file for each built Qt repository. Task-number: QTBUG-129598 Change-Id: If20a45083a70b01668f52023053b75f520129381 Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Add system libs to SBOM after finalizing all targetsAlexandru Croitor2025-11-051-4/+4
| | | | | | | | | | | | | | Previously the build system created SBOM packages for system libraries before trying to finalize any pending targets. That was incorrect, because those targets might consume some system libraries that haven't been processed yet. Move the creation of SBOM packages for system libraries to after finalizing all targets. Pick-to: 6.8 6.10 Change-Id: Ie81ce4c7e9817b892122d065adf6acf1ef0bc3ca Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Fix order of Qt6*AdditionalTargetInfo.cmake file installationAlexandru Croitor2025-10-311-15/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Qt6*AdditionalTargetInfo.cmake files are defer installed using a finalizer at the end of the directory scope where qt_internal_export_additional_targets_file is called. For tools packages, there are usually installed at the end of the root directory scope. qt_internal_export_additional_targets_file keeps track of which files to install (based on an export id) in a global property. Some tests might create a Mock Qt module which also calls the above function and adds its own export id to the global property. Because the mock module finalizer is called before the Tools one, the mock finalizer will process the ids of both of the module and the Tools package, ending up creating installation rules for the Tools in the test directory scope. When Qt is configured with -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF test installation rules are skipped, which means the Tools files would never be installed, causing configuration errors when looking up that package later. To avoid this situation, instead of collecting the export ids in a global property to process all of them later, just let each finalizer process a single id in the directory scope where the finalizer is called. Uncovered by d66cfa93eefa185aa15d42e9dc38cbcdbd0578cb in qtdeclarative. Pick-to: 6.8 6.10 Fixes: QTBUG-141466 Change-Id: Icf839835ea028df2e0079995e301693b9c3cd342 Reviewed-by: Joerg Bornemann <[email protected]>
* Don't claim that PCRE2 is optionalJoerg Bornemann2025-10-301-1/+0
| | | | | | | | | | | | | Using PCRE2 isn't optional anymore since Qt6. Fix QtUsage text in PCRE2's attribution file. Don't mention the options to turn off the pcre2 feature in configure's help text nor configure-cmake-mapping.md. [ChangeLog][Third-Party Code] Don't claim that using PCRE2 is optional. Pick-to: 6.8 6.10 Change-Id: I53ea08a4cf7311fac9da2a514553f5e65a9bbc91 Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Set CMAKE_POLICY_VERSION_MINIMUM with older Android NDKsAlexandru Croitor2025-10-214-0/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using CMake 3.31+ with Android NDKs older than r28, CMake shows the following deprecation warning: CMake Deprecation Warning at ndk/27.2.12479018/build/cmake/android.toolchain.cmake:35 (cmake_minimum_required): Compatibility with CMake < 3.10 will be removed from a future version of CMake. This warning appears multiple times, when configuring Qt, user projects, try_compile calls, etc. That's because the Android NDK cmake toolchain file sets cmake_minimum_required(VERSION 3.6) unconditionally, which is less than 3.10. To avoid the warnings, we can set the CMAKE_POLICY_VERSION_MINIMUM variable or environment variable to 3.10. The variable can only be set in CMake 4.0+ though, so it won't help with CMake 3.31. The assignment has to be done in multiple places: - When detecting Android in QtAutoDetectHelpers.cmake - When generating the Qt toolchain file in QtToolchainHelpers.cmake - When doing try_compile calls in QtFeature.cmake - When doing test calls in QtRunCMakeTestWrappers.cmake To be on the safer side, the following opt-outs are provided: - QT_NO_SET_ANDROID_CMAKE_POLICY_VERSION_MINIMUM If set to true, the automatic setting of CMAKE_POLICY_VERSION_MINIMUM is disabled. - QT_ANDROID_CMAKE_POLICY_VERSION_MINIMUM A version to use instead of 3.10. - QT_NO_SET_RUN_CMAKE_TESTS_CMAKE_POLICY_VERSION_MINIMUM Disables the assignment for RunCMake tests. These are considered at various points in the code, rather than just once when configuring Qt. When using NDK r28 or newer, the toolchain file sets 3.10 itself, so no warning appears. Pick-to: 6.8 6.10 Change-Id: I47c6013f9cafed8836c32d2b726e75838c9d8779 Reviewed-by: Joerg Bornemann <[email protected]> Reviewed-by: Assam Boudjelthia <[email protected]>
* CMake: Add more compiler / linker identification infoAlexandru Croitor2025-10-211-0/+30
| | | | | | | | Useful when builders share logs. Pick-to: 6.8 6.10 Change-Id: I0091203f906aa5b43384c474f42fa555d1e86dba Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Relax handling of CMP0156 policyAlexandru Croitor2025-10-161-17/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't warn about CMP0156 policy values for platforms we don't require them for, which are Apple and Emscripten. This avoids scaring project developers unnecessarily and forcing them to set the policy to OLD / NEW explicitly. Effectively this means we don't force the policy anymore to OLD if cmake_minimum_required is 3.29 or higher on non-Apple and non-Emscripten platforms. CMake is smart enough to do de-duplication of libraries on platforms or linkers that don't support it. Amends c20d7bcb86361d0c9f8af3807dcad9db1a3a5ca0 Amends d6d832d0d28ac29807a04f6634a20e12649b440d [ChangeLog][Build Systems] CMake user projects will now use CMake's default value for the CMP0156 policy, except for Apple and Emscripten platforms which are forced to NEW (when the policy is available). Pick-to: 6.8 6.10 Fixes: QTBUG-141181 Task-number: QTBUG-135978 Task-number: QTBUG-140211 Change-Id: I44d65537a6ca38fdc16bf42088e18f2690f0adbf Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: fix CMP0177 warning under qt_internal_create_source_jar()Assam Boudjelthia2025-10-151-1/+2
| | | | | | | Pick-to: 6.10 Fixes: QTBUG-135304 Change-Id: Ic65ac82d541091920ae100267fb543640c838e2e Reviewed-by: Alexandru Croitor <[email protected]>
* Add syncqt headers to tracepointgen dependenciesAntti Määttä2025-10-031-1/+4
| | | | | | | | | | | Add the dependencies so that tracepointgen can resolve includes properly. Fixes: QTBUG-140443 Pick-to: 6.10 Change-Id: I57babc653d3d5c975dff3a07f7a6b1fc9323f988 Reviewed-by: Samuli Piippo <[email protected]> Reviewed-by: Janne Roine <[email protected]>
* CMake: Handle internal modules in qt_internal_wrap_private_modulesAlexandru Croitor2025-09-292-8/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a Qt module A linked against an internal module B privately, we accidentally find_package()'d B when a user project looks for A. Such a case happened with QtLocation which links to QuickShapesPrivate. This happens because qt_internal_wrap_private_modules only wraps dependencies with $<BUILD_INTERFACE> if the dependency has the _qt_is_private_module property set, which internal modules don't have. This means we passed the internal module to qt_internal_register_target_dependencies which then adds a find_dependency() call for it. Add code to check for the _qt_is_internal_module property and wrap such a target dependency in $<BUILD_INTERFACE>, but only if it the consuming target is not a STATIC library. In the STATIC case, adding the genex would break user builds, because the internal module would never be looked up, even though it needs to be further propagated to the final consuming executable or shared library. This also means that we will look up the Private module in that case, but we can't do much about that. Amends ad7b94e163ac5c3959a7e38d7f48536be288a187 Pick-to: 6.10 Change-Id: Id89ea5bf6de8cb343c2afc0a42fd758cf57aba54 Reviewed-by: Joerg Bornemann <[email protected]>
* cmake: adjust c++ standards for headers cleanLiang Qi2025-09-261-2/+10
| | | | | | | Task-number: QTQAINFRA-7340 Pick-to: 6.10 6.8 Change-Id: Ib21a5a2670a67c8be2ba2606372bcdcc1c427676 Reviewed-by: Alexandru Croitor <[email protected]>
* CMake: add inclusion guards for generated feature includesTim Blechmann2025-09-241-4/+13
| | | | | | | | | | | | Including qconfig.h multiple times seems to be perfectly possible, but the lack of inclusion guards meant that we could end up with #define / #undef / #define sequences. Task-number: QTBUG-140149 Fixes: QTBUG-140150 Pick-to: 6.10 Change-Id: I6b727deedf0c9ed10e2426d6bdc969b1acabd517 Reviewed-by: Alexandru Croitor <[email protected]>
* CMake: Opt in for NEW CMP0156 on WebAssemblyAlexandru Croitor2025-09-221-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise duplicate symbol errors occur when -sMAIN_MODULE is passed to the executable and a static library is linked multiple times into the executable, which is common in Qt builds, due to how qt plugin propagation causes link cycles. Note that having CMP0156 set to NEW relies on CMake having proper support for de-duplication of libraries when targeting Emscripten / WebAssembly, which is only being considered to be added in CMake 4.2+, which as of now is not released yet. For earlier CMake versions, for CMP0156 to apply properly, a project can workaround it by setting set(CMAKE_CXX_PLATFORM_LINKER_ID LLD) set(CMAKE_CXX_LINK_LIBRARIES_PROCESSING ORDER=REVERSE DEDUPLICATION=ALL) in the project manually, even though that is not supported by CMake itself, and relies on CMake internals that might change between versions. Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-140211 Change-Id: Iece0f6893bbd0528e83c5cdbeddd29a51ff35991 Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Handle TARGET_SUPPORTS_SHARED_LIBS for Emscripten betterAlexandru Croitor2025-09-224-5/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The upstream emsdk / emscripten cmake toolchain file sets the CMake global property TARGET_SUPPORTS_SHARED_LIBS to FALSE, claiming that creation of true shared libraries is not supported. See the following comment: https://github.com/emscripten-core/emscripten/pull/8362#issuecomment-3050586255 Despite that, Qt for a while now set the global property to TRUE both when building Qt and user projects, and things mostly worked. This was done in QtWasmHelpers.cmake for shared lib Qt builds. And in Qt6CoreConfigExtras.cmake.in for user projects in both shared or static qt builds (which actually affects repos other than qtbase as well). Starting with CMake 3.30, which introduced policy CMP0164, if it's set to NEW, and TARGET_SUPPORTS_SHARED_LIBS is FALSE, CMake will refuse to create shared library targets (even IMPORTED ones) with an error like: CMake Error at lib/cmake/Qt6Core/Qt6CoreTargets.cmake:50 (add_library): ADD_LIBRARY called with SHARED option but the target platform does not support dynamic linking. Call Stack (most recent call first): lib/cmake/Qt6Core/Qt6CoreConfig.cmake:57 (include) lib/cmake/Qt6/Qt6Config.cmake:240 (find_package) CMakeLists.txt:7 (find_package) This usually popped up when configuring a user project or a qt repo other than qtbase, when Qt is built with CMake 3.30. That's because the auto-generated *Targets.cmake always enables all policies up to the version of the used CMake version, with a command like cmake_policy(VERSION 2.8.3...3.31) The Qt6CoreConfigExtras.cmake file is included after the Targets file, so its setting of TARGET_SUPPORTS_SHARED_LIBS to TRUE is too late. To avoid this error, introduce a new _qt_internal_handle_target_supports_shared_libs helper function that sets TARGET_SUPPORTS_SHARED_LIBS to TRUE in Qt6ConfigExtras.cmake. This will be executed before any imported target creation in Qt*Targets.cmake files. Because Qt6ConfigExtras.cmake is not loaded during the initial configuration of the qtbase build, also replace the call in QtWasmHelpers.cmake. Make it consistent and call the function regardless of a shared or static Qt build. Allow opting out of the TARGET_SUPPORTS_SHARED_LIBS assignment by passing -DQT_NO_ENABLE_TARGET_SUPPORTS_SHARED_LIBS=ON. Incidentally, CMake 4.2 is introducing it's own support for Emscripten, and will set TARGET_SUPPORTS_SHARED_LIBS to TRUE if it detects that the emsdk toolchain file is not loaded. Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-140211 Change-Id: I9313476abd885bcbe60309e62fe1d6ae568769e8 Reviewed-by: Morten Johan Sørvig <[email protected]> Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Handle library names like libavformat.a in .prl filesJoerg Bornemann2025-09-182-1/+23
| | | | | | | | | | | | | | We generated faulty .prl files for Qt modules that link against library file names like "libavformat.a". The .prl file contained wrong LIBS entries like "-llibavformat.a". Now, we check whether a library entry looks like a library file name and don't prepend the -l in that case. Fixes: QTBUG-138596 Pick-to: 6.10 6.8 Change-Id: I44ce5de91e4575bb45d391db4f1d3d70efefcdfa Reviewed-by: Alexandru Croitor <[email protected]>
* Remove '_fake_header.h' from syncqt processingAlexey Edelev2025-09-181-4/+0
| | | | | | | | | | The leftover header is not generated anymore, so we may remove any related handling. Amends a966d7be48d9b419195a8916e307f84487140839 Change-Id: I59167989e64da3a56023ff82bad7f2831e39b5c0 Reviewed-by: Tor Arne Vestbø <[email protected]>
* CMake: Rework SBOM version handlingAlexandru Croitor2025-09-171-36/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | The SBOM project version handling had some issues. If USE_GIT_VERSION was used by a project, the spdx file name would never get a version suffix, even if the project also passed an explicit VERSION option. So either USE_GIT_VERSION or VERSION was used, but not both. Rework the code so that first the git version if is queried if USE_GIT_VERSION is passed, and then that gets overridden with the value of VERSION if that is passed. VERSION will be used as the version suffix for the spdx file name even when git info is available, by storing it in the QT_SBOM_EXPLICIT_VERSION global property and using it at the appropriate call site. Also add a new QT_SBOM_VERSION_OVERRIDE variable that can be used to override the explicit version, if needed. Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-134894 Change-Id: I999f731493ddffcc6974edeca0adacefcc85b9d9 Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Fix non_git_version checkAlexandru Croitor2025-09-171-2/+2
| | | | | | | | | | | There was a typo where the code checked for not_git_version instead. Amends ecf1e021de519df02b1e13fcc0472bd00f8603fd Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-134894 Change-Id: I299ffff0a2ddb628d87c9af2e75b3b3bc1af2a79 Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Add non-internal option names for the SBOM project opsAlexandru Croitor2025-09-171-5/+6
| | | | | | | | | | | They are not public API yet, but this would be a pre-requisite. The intent is to use them for the Qt Creator SBOM CI run. Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-134894 Change-Id: I65b596e2e4ab994a23bdcb9bf9473a8240a5f9c7 Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Add an SBOM LICENSE_DIR_PATHS project optionAlexandru Croitor2025-09-171-5/+15
| | | | | | | | | | | | | To allow specifying additional license directories via an option, rather than via setting a QT_SBOM_LICENSE_DIRS variable in the parent scope. The old variable approach is kept for compatibility. Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-134894 Change-Id: Idae96c719dbc168b3366a0206c19393e27c7f76d Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Add an SBOM DOCUMENT_CREATOR_TOOL project optionAlexandru Croitor2025-09-172-2/+19
| | | | | | | | | | | | | | The new option replaces the hardcoded "Creator: Tool: Qt Build System" line in the SPDX document. The option value should not include the "Creator: Tool: " prefix. If not set, the old hardcoded value is used. Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-134894 Change-Id: I1a8ca736b377839e5032a0c507ebeb03dfcee74d Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Fix double slash in SBOM install pathAlexandru Croitor2025-09-172-8/+10
| | | | | | | | | | Use _qt_internal_path_join to avoid concatenating paths with empty components. Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-134894 Change-Id: I62fe286dc56172af9a4293158a93e1699ad239ab Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Rename TYPE to SBOM_ENTITY_TYPE in SBOM APIAlexandru Croitor2025-09-1714-86/+155
| | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
* CMake: Fix handling of empty CMAKE_BUILD_TYPE during SBOM generationAlexandru Croitor2025-09-171-2/+6
| | | | | | | | | | | | | | If a project is configured with an empty CMAKE_BUILD_TYPE, the SBOM logic would skip adding any of the target files to the SBOM, because it tried to iterate on the list of available configs. Make sure to specify a custom "<EMPTY_CONFIG>" config in that case, so that the loop doesn't become a no-op. Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-134894 Change-Id: I789a2d4d00375722d5b7257fd02ecf5ab4f0129e Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Move SBOM deferred finalization to the extend functionAlexandru Croitor2025-09-173-18/+47
| | | | | | | | | | | | | | | | | | | | | | | This ensures that both _qt_internal_extend_sbom and _qt_internal_add_sbom will trigger sbom finalization for targets. Previously only _qt_internal_add_sbom would run the finalization, which is counter-intuitive. One caveat is that we need to ensure we don't run finalization for system libraries as a result of the change. Finalization of system libraries is handled in a different pre-existing code path. We also shouldn't call _qt_internal_extend_sbom for qt_internal_extend_target if there are no SBOM, otherwise we trigger SBOM creation for targets like FooModulePrivate, which will trigger an error later because they don't have a TYPE. This might be revisited later if it makes sense to generate SBOM entries for such targets. Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-134894 Change-Id: Ic14653f6baa920da46617061d8701ed9b94df093 Reviewed-by: Joerg Bornemann <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-01 08:46:18 +0000