summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Create macOS framework basic structure at configure timeJoerg Bornemann47 hours1-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 <alexandru.croitor@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Remove unused FEATURE_DEPENDENCIES optionAlexandru Croitor3 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 <joerg.bornemann@qt.io>
* CMake: Skip creating feature header files if NO_HEADERS is specifiedAlexandru Croitor3 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 <joerg.bornemann@qt.io>
* CMake: Clean up cmake_parse_arguments use in qt_feature_module_beginAlexandru Croitor3 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 <joerg.bornemann@qt.io>
* CMake: Allow opting out of installing the cmake/Find*.cmake scriptsAlexandru Croitor3 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 <joerg.bornemann@qt.io>
* CMake: Add options to skip generation of some module filesAlexandru Croitor3 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 <joerg.bornemann@qt.io>
* CMake: fix correct jar paths for in-tree builds for JavaDocElias Toivola6 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 <assam.boudjelthia@qt.io>
* CMake: Fix rcc big resource feature in in-tree example buildsAlexandru Croitor6 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 <joerg.bornemann@qt.io>
* cmake: remove Clang 14 -Wno-error flagsMarc Mutz8 days1-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 <volker.hilsheimer@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: remove the C++20 enum-related -Wno-error flagsMarc Mutz9 days1-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 <volker.hilsheimer@qt.io>
* configure: Simplify handling of the -make and -nomake optionsJoerg Bornemann10 days1-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 <alexandru.croitor@qt.io>
* Add qtbase Qt6Android.jar to class-pathElias Toivola11 days1-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 <nicholas.bennett@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* cmake: remove GCC-9 -Wno-error flags added d/t "Qt not ready"Marc Mutz12 days1-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 <thiago.macieira@intel.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* SBOM: Do not use generic QT CPE for third party modulesKai Köhne12 days1-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 <alexandru.croitor@qt.io>
* cmake: remove -Wno-error=implicit-fallthroughMarc Mutz13 days1-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 <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <alexandru.croitor@qt.io>
* 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 <alexandru.croitor@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <alexey.edelev@qt.io>
* 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 <joerg.bornemann@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* 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 <alexey.edelev@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <alexandru.croitor@qt.io>
* 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 <samuli.piippo@qt.io> Reviewed-by: Janne Roine <janne.roine@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <alexandru.croitor@qt.io>
* 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 <alexandru.croitor@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <morten.sorvig@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* 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 <alexandru.croitor@qt.io>
* 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ø <tor.arne.vestbo@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <alexey.edelev@qt.io>
* 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 <joerg.bornemann@qt.io>
* 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 <joerg.bornemann@qt.io>
* CMake: Fix sbom project end target finalization to be a loopAlexandru Croitor2025-09-173-8/+36
| | | | | | | | | | | | | | | | | | Finalizing an SBOM for a target inside _qt_internal_sbom_end_project can cause another target's SBOM to be deferred. It would never be added to the SBOM, because by that time we already call _qt_internal_sbom_end_project_generate(). Make sure to process the sbom finalization in a loop, until no new targets need to be finalized. Remove IMMEDIATE_FINALIZATION from qtbase's Platform targets, because they will now be properly finalized including attribution dependencies. Pick-to: 6.8 6.9 6.10 Task-number: QTBUG-134894 Change-Id: Id10a7131eed146cdc2c7074b36762f796b927a71 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix wrong elseif usage in sbom deterministic build setupAlexandru Croitor2025-09-171-1/+1
| | | | | | | | | Should just be an else. Task-number: QTBUG-134894 Pick-to: 6.8 6.9 6.10 Change-Id: Iea39dd98fd94d5bec9df85f8299ce6820db81f1d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Set QDOC_PROJECT_ROOT for doc targetsPaul Wicking2025-09-171-0/+1
| | | | | | | | | | | | | | | | QDoc warning logs use absolute file paths that make logs non-portable across build environments. This limits usefulness in CI systems where paths vary between machines. This change sets the `QDOC_PROJECT_ROOT` environment variable to the module source directory when invoking QDoc. This enables QDoc to generate relative paths in warning logs, making them portable across different build environments. Task-number: QTBUG-138846 Change-Id: Ib7a2a9bc11b4499e9174ee67efd71c965d75a4fc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* macOS: Create framework headers symlink manually instead of via CMakeTor Arne Vestbø2025-09-161-15/+10
| | | | | | | | | | | As the latter requires us to awkwardly create a fake dummy header in the frameworks we ship. The symlink points to the `Current` version symlink, just like for the library itself and Resources -- both of which CMake generates still. Change-Id: I2db3f218a3c01cb1be73a0d7a514241b6c472ba3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Don't create framework header directories unless we have headersTor Arne Vestbø2025-09-121-1/+1
| | | | | | | | | | | qt_copy_framework_headers was unconditionally creating all the private, qpa, rhi, and ssg header subdirectories, even if we didn't have any headers to put in them, which doesn't match how we structure the normal include directories. Pick-to: 6.10 6.9 6.8 Change-Id: I9efe2fd9c4f6d10f57e30ffcba2b912dae35a2c4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* wasm: Switch to the new jspi browserEven Oscar Andersen2025-09-121-14/+27
| | | | | Change-Id: I10d1950f6532a01b7803944aa4383df4f974d996 Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
* AndroidTestRunner: don't print crashes by defaultAssam Boudjelthia2025-09-111-0/+4
| | | | | | | | | | | | | | In most cases after a crash, logs will be too long and will flood the test output, making it not ideal and mainly unexpected. Instead of printing the crash logs and logcat by default, have it done only when it's explicitly requested via --show-logcat. For CI though, add the --show-logcat by default so we don't lose that verbosity. Pick-to: 6.10 Change-Id: I2306b97378b6218ed22ba98aa50deefa9c9cd968 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-11-23 21:51:31 +0000