summaryrefslogtreecommitdiffstats
path: root/cmake/QtPostProcessHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Allow adding tools dependencies on INTERFACE librariesAlexandru Croitor3 days1-6/+4
| | | | | | | | | | | | | | | | 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 Croitor3 days1-5/+29
| | | | | | | | | | | | | | | | | 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: Look for packages in Standalone Tests Config files individuallyAlexandru Croitor4 days1-7/+4
| | | | | | | | | | | 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: Simplify the installation of .prl filesJoerg Bornemann2025-09-111-16/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Since the commit that introduced .prl file generation, bfcf36d459c7a36a92dd6f9127e6513f7a08277e, we jumped through some hoops to collect the build directories containing .prl files and then installing these directories with the FILES_MATCHING argument. This resulted in the installation of empty directories, because install(DIRECTORY ... FILES_MATCHING ...) preserves the input directory structure. This complex installation procedure is unnecessary. We know how to construct the final .prl file path with generator expressions. install(FILES) supports generator expressions since CMake 3.0, which the original author of bfcf36d459c7a36a92dd6f9127e6513f7a08277e missed. Remove the qt_internal_install_prl_files function that called install(DIRECTORY ... FILES_MATCHING ...) in a post-process step, and call install(FILES ...) instead for every generated .prl file. This solves the issue that we would install empty directories in lib/cmake. Pick-to: 6.10 Task-number: QTBUG-138580 Change-Id: I4af3e808dc420d08a0e1a1fe3059a0a432949586 Reviewed-by: Alexandru Croitor <[email protected]>
* CMake: Don't install incomplete Qt6BundledFoo packagesJoerg Bornemann2025-08-131-5/+8
| | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
* Generate features in AndroidManifest.xmlAlexey Edelev2025-07-071-0/+1
| | | | | | | | Use the transitive INTERFACE_QT_ANDROID_FEATURES property to generate user feature declarations in AndroidManifest.xml. Change-Id: I6d49da12dc708abe125546241a268bb4ed6937d1 Reviewed-by: Alexandru Croitor <[email protected]>
* Rework android permission handlingAlexey Edelev2025-07-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current QT_ANDROID_PERMISSIONS property format is inconvenient for use in the CMake generator expressions and mixes attribute syntax with CMake list syntax. This suggests the new format for the QT_ANDROID_PERMISSIONS property. Each element is encoded the following way: <android:name>\;<permission>\\\;<extra1>\;<value>\\\;<extra2>\;<value> Elements are separated using standard CMake semicolons. QT_ANDROID_PERMISSIONS is now transitive LINK property. This feature deprecates the '<permission' records in the Qt6<Module>-android-dependencies.xml files. If application links Qt Module that requires specific permissions, these permissions will be written to the application deployment-settings.json file. The 'permissions' record in the application deployment-settings.json file is changed too, the new format is following: "permissions": [{ "name": "permission", "extra1": "value", "extra2": "value" }] Comparing to the previous format each extra attribute is stored under a separate key in permission object. IMPORTANT: androiddeployqt has no backward compatibility with the old format. With QT_USE_ANDROID_MODERN_BUNDLE enabled permissions are written directly to the AndroidManifest.xml without androiddeployqt involved. Supply tests for the Android permissions, that reads the manifest-declared permissions in test using the Android PackageManager API. Change-Id: I691df33c70acc6c7139302b119edc791fef8d5ef Reviewed-by: Assam Boudjelthia <[email protected]>
* Install `user_facing_tool_links.txt` automaticallyCristian Le2025-06-251-0/+13
| | | | | | | | | | The installation is already gated by the user having to specify `INSTALL_PUBLICBINDIR`, at which point we know that they want symlinks created and installed. This automates the installation for that user. Fixes: QTBUG-132761 Change-Id: Ie1242f21ec39db8fc0f31d7f2b93a43a23533485 Reviewed-by: Alexandru Croitor <[email protected]>
* Make HostInfo versionedAlexey Edelev2025-03-241-1/+9
| | | | | | | | | | Generate and install the HostInfoConfigVersion file for the HostInfo package. The package had no strict version compatibility as Qt modules before, so we avoid adding them here too. Pick-to: 6.5 6.8 6.9 Change-Id: Iaee43639dd87d911946c8ce72c4849f43599d08e Reviewed-by: Alexandru Croitor <[email protected]>
* Avoid using the PROJECT_VERSION when accessing the HostInfo package variablesAlexey Edelev2025-03-211-1/+1
| | | | | | | | | | | | | The related functionality meant to be enabled by BuildInternals, which makes the lookup of the pre-defined HostInfo version based on either calculated or pre-defined INSTALL_CMAKE_NAMESPACE. The PROJECT_VESION(_MAJOR) meanwhile is hardcoded by the current Qt repo, which is not necessary aligned with BuildInternals/HostInfo. Pick-to: 6.5 6.8 6.9 Change-Id: I61052c93ce2d6ee3c6d8025da2e078edcde48d0d Reviewed-by: Alexandru Croitor <[email protected]>
* CMake: Move qml plugin auto inclusion code into a separate macroAlexandru Croitor2025-01-271-61/+2
| | | | | | | | | | | | | | | The code is moved into a macro without any modifications aside from removing the escaping of variable evaluation and escaping of quotes. It's kept as a macro similar to __qt_internal_include_plugin_packages, because there might be calls to find_package() that set variables in the current scope. The reason for moving is easier maintenance (no more escaping). Pick-to: 6.8 6.9 Change-Id: Ie6ddc26fe4ff8db0134f3542c2886f8b5d68dc51 Reviewed-by: Joerg Bornemann <[email protected]>
* Make user tools symlinks relativeCristian Le2025-01-231-0/+2
| | | | | | | Fixes: QTBUG-132724 Pick-to: 6.8 6.9 Change-Id: I0f1d95ef6b66c81e2d12730eae3d5c0452a3a7a1 Reviewed-by: Alexandru Croitor <[email protected]>
* Export `INSTALL_PUBLICBINDIR` to `QtBuildInternalsExtra.cmake`Cristian Le2025-01-231-0/+5
| | | | | | | | | | | `INSTALL_PUBLICBINDIR` is only exported if it was defined by the user when building QtBase. The conditional check aligns with the one used in `qt_internal_generate_user_facing_tools_info` Fixes: QTBUG-107016 Pick-to: 6.8 6.9 Change-Id: Id5c38555e1d22cb3c16d85261cb052c695b4de03 Reviewed-by: Alexandru Croitor <[email protected]>
* Replace qt_record_extra_qt_package_dependency with ↵Alexey Edelev2025-01-201-0/+3
| | | | | | | | | | | | | | | | | 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 <[email protected]>
* CMake: Simplify Qt6FooPrivate -> Qt6Foo package dependency setupJoerg Bornemann2025-01-081-9/+2
| | | | | | | | | | | | | 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 <[email protected]>
* CMake: Don't export 3rdparty dependency find_package callsJoerg Bornemann2025-01-081-11/+1
| | | | | | | | | | | | | | ...of private modules in public modules. This isn't necessary anymore since the Qt6FooPrivateDependencies.cmake files contain these 3rdparty dependencies proper. This reverts commit dae078e521c3932c66436cbdbfaf5294a1842901. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I2c425d49fe7beb790abf9a94f089d43fde8b047e Reviewed-by: Alexandru Croitor <[email protected]>
* CMake: Split off private module config packagesJoerg Bornemann2024-12-191-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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 <[email protected]>
* CMake: Export 3rd party dep info also for the Qt6 packageAlexandru Croitor2024-07-111-0/+12
| | | | | | | | | | | | It usually looks up the Threads target, so we want it to be recorded as a provided target. Amends 58eefbd0b6169d0749b312268c1ae1e594e04362 Pick-to: 6.8 Change-Id: I0f06aaae98fd99da8fb6436d232a147e163580a2 Reviewed-by: Joerg Bornemann <[email protected]> Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Fix escaping in recording of provided targetsAlexandru Croitor2024-06-251-3/+0
| | | | | | | | | | | | | | | In diff of below change, patch set 4 to 5, the list(APPEND) was replaced with a string(APPEND), but the escaping of semicolons was not removed. This caused an issue with packages that provide multiple targets when configuring qtsvg in a static qt build. Remove the unnecessary escaping. Amends 58eefbd0b6169d0749b312268c1ae1e594e04362 Pick-to: 6.8 Change-Id: I1755f31b333e7cf76722cff490349bcc159d7e93 Reviewed-by: Joerg Bornemann <[email protected]>
* CMake: Generate an SPDX v2.3 SBOM file for each built repositoryAlexandru Croitor2024-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Record package provided targets in Dependencies.cmake filesAlexandru Croitor2024-05-291-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Each qt_find_package can specify a PROVIDED_TARGETS option, to inform which targets will be created by that package. The call then saves the package name, version, etc on each of the provided targets. Currently the provided targets info is not persisted anywhere after configuration ends. We will need this for SBOM creation, so that we can collect information about such dependencies when configuring leaf repos, where find_dependency calls are implicit, and don't contain the PROVIDED_TARGETS option, and we need to go from package name to target name (and any recorded info it the target has). This is especially relevant for static library builds, where private dependencies become public dependencies. Collect the provided targets information at post process time and persist it for each 'package name + components requested' combination into the Dependencies.cmake file. This information will be used in a later change for SBOM generation. Change-Id: I1693f81b1ad3beaf9b02e44b09a5e977923f0d85 Reviewed-by: Alexey Edelev <[email protected]>
* Change the -qpa configure argument logicAlexey Edelev2024-05-141-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Parse the -qpa configure argument as list and translate it to the QT_QPA_PLATFORMS cmake variable. This variable is new to the Qt build procedure. The QT_QPA_DEFAULT_PLATFORM variable supposed to get multiple values, but this didn't work at all, since the variable value then was used in the compile definition that is expected to be a single value QPA platfrom definition. This inconsistency forced to introduce a new variable. The QT_QPA_DEFAULT_PLATFORM variable now controls the first-choice QPA plugin for the GUI applications. The new configure argument -default-qpa is now translated to the QT_QPA_DEFAULT_PLATFORM variable instead the of -qpa one. The -qpa configure argument is now translated to the QT_QPA_PLATFORMS variable, which is new one as well. The variable contains the list of QPA plugins that are "default" for this Qt configuration. The meaning of the "default" plugins is related to the DEFAULT_IF argument of qt_internal_add_plugin command. Plugins that are listed in the QT_QPA_PLATFORMS variable will be treated as default by the build system and will be deployed within user applications when using deployment API or linked statically when using static Qt. The QT_QPA_DEFAULT_PLATFORM falls back to the QT_QPA_PLATFORMS first value in the list if it's not set explicitly and either '-DQT_QPA_PLATFORMS' or '-qpa' arguments are specified. [ChangeLog][CMake] Added QT_QPA_PLATFORMS variable which controls the list of QPA plugins that will be deployed within the applications by default. [ChangeLog][CMake] The '-qpa' configure argument now is mapped to the QT_QPA_PLATFORMS variable and has different functionality. It doesn't control the platform plugin that the GUI application is using by default, but controls the list of QPA plugins that will be deployed within the applications by default. [ChangeLog][CMake] Added '-default-qpa' argument which replaces the '-qpa' one. The argument is translated to the QT_DEFAULT_QPA_PLATFORM CMake variable and selects the default platform that should be used by GUI application if QT_QPA_PLATFORM environment variable is not set. Task-number: QTBUG-124265 Task-number: QTBUG-87805 Task-number: QTBUG-124449 Change-Id: Ibcebaccc535aaed6374f15ccfeddb3e6128f5ce0 Reviewed-by: Alexandru Croitor <[email protected]>
* cmake: Rename QT_UIKIT_SDK to QT_APPLE_SDKTor Arne Vestbø2024-03-181-2/+2
| | | | | | | | | | | | | | The SDK is relevant for all Apple systems, including macOS, iOS, tvOS, watchOS, and visionOS. We still pick up -DQT_UIKIT_SDK for iOS for compatibility. [ChangeLog][CMake] The -sdk configure argument now maps to the QT_APPLE_SDK CMake variable. QT_UIKIT_SDK is still supported for iOS builds for compatibility. Change-Id: I983a2f23c2414eb73cd35bb83738088defb45cbd Reviewed-by: Alexandru Croitor <[email protected]>
* CMake: Allow building all examples as standalone just like testsAlexandru Croitor2024-03-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new libexec/qt-internal-configure-examples script that allows to configure and build "standalone examples" just like "standalone tests". This is a prerequisite for using deployment api in examples for prefix builds, otherwise deployment api gets confused not finding various information that it expects from an installed qt. Because the various conditions in the build system for standalone examples are similar to standalone tests, introduce a new QT_BUILD_STANDALONE_PARTS variable and use that in the conditions. The variable should not be set by the user, and is instead set by the build system whenever QT_BUILD_STANDALONE_TESTS/EXAMPLES is set. Unfortunately due to no common file being available before the first project() call, in qtbase builds, per-repo builds and top-level builds, we need to duplicate the code for setting QT_BUILD_STANDALONE_PARTS for all three cases. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: Ia40d03a0e8f5142abe5c7cd4ff3000df4a5f7a8a Reviewed-by: Alexey Edelev <[email protected]> Reviewed-by: Qt CI Bot <[email protected]>
* CMake: Allow specifying additional glob paths for QmlPlugins.cmakeAlexandru Croitor2024-03-111-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we hard-code to look for qml plugin Config.cmake files in the current list dir, whether the Qt6Qml directory is. This is not sufficient for finding qml plugins in a prefix build of a repo that has not been installed yet. For example qtquick3d plugins will be in qtquick3d_build_dir/lib/cmake/Qt6Qml/QmlPlugins, which won't be picked up by the Qt6Qml Config file in the installed Qt location. Allow specifying extra qml plugin glob prefixes via a new QT_ADDITIONAL_QML_PLUGIN_GLOB_PREFIXES variable. This is similar to QT_ADDITIONAL_PACKAGES_PREFIX_PATH. Any path specified via QT_ADDITIONAL_QML_PLUGIN_GLOB_PREFIXES will have the QmlPlugins/${INSTALL_CMAKE_NAMESPACE}*Config.cmake glob appended to it, and then used for globbing files in that location, after processing the main location wherever Qt6Qml is. This will be used by ExternalProject example machinery. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I469863c965b8b13cf007c611976a64fbff6e9111 Reviewed-by: Joerg Bornemann <[email protected]>
* Remove year from generic Qt copyright informationKai Köhne2024-02-141-1/+0
| | | | | | | | | | | | | While at it, also add the missing dot in Ltd. (as it's an abbreviation). Also, prefer https:// over http://. Fixes: QTBUG-121906 Task-number: QTBUG-121928 Pick-to: 6.7 6.6 Change-Id: I4e1f1563376ae36b3c260359d830f00969ab9351 Reviewed-by: Joerg Bornemann <[email protected]> Reviewed-by: Thiago Macieira <[email protected]>
* CMake: Fix configuring a standalone test on Apple platformsAlexandru Croitor2024-02-021-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | Configuring a test as standalone would fail with the following error: Invalid max SDK version: It should be a major version number, without minor This happened because _qt_internal_check_apple_sdk_and_xcode_versions expects QT_SUPPORTED_MAX_MACOS_SDK_VERSION to be available, but it is not yet set due to Qt6 package not being found yet. Avoid the issue by exporting the version requirements into both Qt6ConfigExtras.cmake and Qt6BuildInternalsConfigExtra.cmake. Make sure to assign the variables only once. Amends a29bff3d80219f54d0837b0e6e0577192011dea1 Amends a0bdd2195f24d8a7d880ba506afc16b41337218e Pick-to: 6.6 6.7 Task-number: QTBUG-119490 Change-Id: Ic297eeaabf22c8c42ded1a766906f88fdb91fd3d Reviewed-by: Alexey Edelev <[email protected]> Reviewed-by: Tor Arne Vestbø <[email protected]>
* Change the way we detect the need of adding Qt<Module>Plugins.cmakeAlexey Edelev2024-01-311-2/+2
| | | | | | | | | | | | | | | | | Currently we assume that only modules that have plugins built in the current build tree need to generate and install the Qt<Module>Plugins.cmake file. This approach is weak since other Qt modules might still want to provide the plugins of the certain types, even if the module that the plugin type belongs too didn't have plugins initially. The fix unblocks the formally 3rd-party plugin installation and loading chain. Pick-to: 6.2 6.5 6.6 6.7 Fixes: QAA-2266 Change-Id: Ifc616e26a00674371c8e2fe2ca12237d153e5707 Reviewed-by: Alexandru Croitor <[email protected]>
* CMake: Simplify default CMAKE_BUILD_TYPE logicAlexandru Croitor2024-01-261-13/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we had four-ish locations where the CMAKE_BUILD_TYPE was force set. Twice in QtBuildInternalsExtra.cmake via qt_internal_force_set_cmake_build_type_conditionally(), depending on some conditions. This was executed right at find_package(Qt6 COMPONENTS BuildInternals) time. And twice in qt_internal_set_default_build_type() via qt_build_repo_begin() / qt_prepare_standalone_project() that goes through QtSetup.cmake. This was executed only if the relevant functions were called, rather than directly at find_package() time. The exact logic of which build type ended up being set was very confusing. Refactor the code to decide the build type in one single location when qt_build_repo_begin() / qt_prepare_standalone_project() are called, rather than directly at find_package() time. The actual logic when we override the build type depends on many factors: - when an explicit CMAKE_BUILD_TYPE is given, honor it, unless it's a multi-config build - when it's a multi-config build, don't set any CMAKE_BUILD_TYPE, use the value of CMAKE_CONFIGURATION_TYPES - when it's a qtbase build, compute a default unless an explicit value was given - the default is Debug if FEATURE_developer_build is ON - otherwise the default is Release - when it's a top-level build, only choose a build type for qtbase - when it's another repo build, use the original build type unless another was given explicitly (including in a top-level build) - when it's a standalone tests build - if qt is multi-config, the tests will be single config, due to various CI failure reasons, this hasn't changed - if qt is single config, use the original unless an explicit value was given - when it's a single standalone test build, use the original unless an explicit value was given To determine when an explicit CMAKE_BUILD_TYPE was given in contrast to when it was default initialized, we now have one single function that uses a few heuristics. The heuristics are needed because we can't reliably determine an explicitly given 'Debug' build on Windows, because CMake default initializes to that. The heuristics include: - checking whether CMAKE_BUILD_TYPE_INIT is different from CMAKE_BUILD_TYPE - checking what the CMAKE_BUILD_TYPE was before the first project() call when CMake default initializes - we save the previous value in the qt.toolchain.cmake file - also in QtAutoDetect during qtbase configuration - also when building the sqldrivers project - honoring the value of QT_NO_FORCE_SET_CMAKE_BUILD_TYPE As a result of the above changes, the build type will be set exactly zero or one times, for a particular build directory. Note that the configure script also has some logic on which CMAKE_BUILD_TYPE / CMAKE_CONFIGURATION_TYPES to pass to CMake depending on whether -debug / -release / -debug-and-release / -force-debug-info were passed. But once the values are passed, CMake will honor them. Amends 48841c34d2e86a741ec9992b9704c0fa5973503c Amends 8c912cddebe544010e7da3f87af5b21f3328d7ec Pick-to: 6.7 Task-number: QTBUG-114958 Task-number: QTBUG-120436 Change-Id: I30db14d1e8e9ff9bd2d7ea1d2256cdeb9493ca0d Reviewed-by: Alexey Edelev <[email protected]> Reviewed-by: Qt CI Bot <[email protected]>
* CMake: Fix user_facing_tool_links.txt for Apple platformsJoerg Bornemann2024-01-101-1/+8
| | | | | | | | | | | | | User-facing apps that are app bundles on macOS weren't linked correctly. For example, for Qt Designer we're creating now an entry like the following: .../Designer.app/Contents/MacOS/Designer /usr/bin/designer6 Pick-to: 6.6 6.7 Fixes: QTBUG-120487 Change-Id: I3eada15c4c5bf31b9b08829333d3c87f76ede7a2 Reviewed-by: Alexey Edelev <[email protected]> Reviewed-by: Kai Köhne <[email protected]>
* CMake: Move qt_internal_read_repo_dependencies into QtBuildRepoHelpersAlexandru Croitor2023-11-271-11/+0
| | | | | | | | | | | | | | | | | | | | Previously qt_internal_read_repo_dependencies had to be defined before QtBuildInternalsExtra.cmake was included because the file called the function. Instead of calling the function in QtBuildInternalsExtra.cmake, just call it later after the Helpers have been loaded. We can do this because the function is always called unconditionally, so no point in doing it in the generated file. This lets us move the function into the QtBuildRepoHelpers. Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25 Amends a804ac3d881fb036619f323f64e778a9e00b181d Task-number: QTBUG-86035 Change-Id: Idffed8f2eb9d728c779b77b31eba0d24d85752ea Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Alexey Edelev <[email protected]>
* Remove noisy and non-informative messageLisandro Damián Nicanor Pérez Meyer2023-11-221-4/+0
| | | | | | | | | | This has the flaw of providing very little information and happens too many times during the configure process. My bad, apologies for the noise. Change-Id: I57368f514be968e7144f364f627c110ceed20dae Reviewed-by: Alexandru Croitor <[email protected]>
* Be verbose on plugin inclusion, easy patch point for distrosLisandro Damián Nicanor Pérez Meyer2023-11-021-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TL;DR: This creates two changes: 1. Makes the plugin inclusion status more visible for builders for both Qt itself and applications. 2. Allows a simple patch-point for distros to change the default (perhaps not ideal, but good enough). 3. Does not changes the current behavior. As discussed both in the mailing list and privately with Alexandru Croitor and Joerg Bornemann this makes a lot os sense for Qt on static builds and when trying to find where the plugins are so they can be easily packaged up in order to distribute a build with all the dependencies on it. But at the same time it makes no sense for distributions building the libraries in dynamic mode as it forces unnecesary build time dependencies for for both Qt and applications like QML modules or even PostgreSQL! [0]. [0] <https://sources.debian.org/src/martchus-qtutilities/6.10.0-1/cmake/modules/QtConfig.cmake/?hl=35#L35> Other approaches have been considered like not shipping specific CMake files, but this depends on the packager finding the right ones at the right time, and does not allows end users to change the behavior if they happen to need it. Change-Id: Id32fbc0cf0f289edd4426fb703cf1195288aacb4 Reviewed-by: Alexandru Croitor <[email protected]>
* Centralize copyright information for QtKai Köhne2023-03-201-0/+6
| | | | | | | | | Maintain one central place - .cmake.conf - for information about Qt's copyright. Pick-to: 6.2 6.5 Change-Id: Ibcbce4313eba9660d459061b0ad00307e267b8f7 Reviewed-by: Alexandru Croitor <[email protected]>
* FEATURE_pkg_config Should be BOOLAmir Masoud Abdol2022-10-281-1/+1
| | | | | | | | It might not matter as far as I understand, but having it saved as BOOL is better if it's a boolean. Change-Id: If35485425257ca5518f0f8a49ca5353b9ac875a8 Reviewed-by: Alexandru Croitor <[email protected]>
* Replace the syncqt.pl script with syncqt toolAlexey Edelev2022-09-271-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | syncqt.pl adds an extra dependency on perl when building Qt. Modern C++ provides the convenient cross-platform way to access a filesystem and to use regular expressions, so we may replace the perl script with C++ application. The syncqt executable is built at configure time and installed as QtCore tool. It's running at configure time to deliver the required header files for IDE to build a consistent code model and at the build time to keep tracking changes in header files and generate the missing aliases without reconfiguring. 'syncqt' only parses header files from a CMake build tree, so the resulting Qt installation only contains interfacing headers that belong to the platform that Qt is built for. 'sync.profile' files are not used as the 'source of truth' for sync qt procedure anymore, all the necessary information is taken from either CMake files at configure time or from the module header files while parsing them. syncqt.pl is still in place since it's required as fallback solution for a smooth transition to the new syncqt implementation for all qt repositories. This patchset only enables the C++ based syncqt for 'qtbase' repository. From the performance perspective C++ version works faster then perl script, also the configure time is reduced significally on subsequent reconfigurations - up x2 times faster when re-configuring repository, but it also takes time to compile the tool itself the first time. Numbers for qtbase: syncqt.pl syncqt.cpp initial: 0m16,035s 0m20,413s reconfig: 0m6,819s 0m3,725s The syncing procedure can be run separately for each module using <ModuleName>_sync_headers targets. The 'sync_headers' target can be used to sync all the modules at once. Task-number: QTBUG-87480 Task-number: QTBUG-103196 Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523 Reviewed-by: Alexandru Croitor <[email protected]>
* Change the license of all CMakeLists.txt and *.cmake files to BSDLucie Gérard2022-08-231-1/+1
| | | | | | | Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Jörg Bornemann <[email protected]>
* Add -disable-deprecated-up-to parameter to configure scriptIvan Solovev2022-08-191-0/+5
| | | | | | | | | | | | | | | | | | And also teach CMake to treat it properly instead of hardcoding the version number. [ChangeLog][Build System] The configure script now accepts a new parameter -disable-deprecated-up-to which is used to remove all deprecated code from API and ABI while building the libraries. The version number must be specified in a hex format. For example, it can be used like this: /path/to/qt/configure -disable-deprecated-up-to 0x060500 to remove all code deprecated in Qt 6.5.0 or earlier releases. Task-number: QTBUG-101510 Change-Id: I557cf83e29b867fa1052bb097985e144b5eaf34d Reviewed-by: Edward Welbourne <[email protected]> Reviewed-by: Alexandru Croitor <[email protected]>
* Rename arg_HEADER_MODULE variable to 'is_interface_lib'Alexey Edelev2022-08-121-6/+5
| | | | | | | | | Variables starting with 'arg_' usually are the result of the cmake_parse_arguments call. It's better to not use them for the regular variables for readability. Change-Id: I4054c63d3e48b2a27d8a632cd8908a59302afa47 Reviewed-by: Alexandru Croitor <[email protected]>
* Add license headers to cmake filesLucie Gérard2022-08-031-0/+3
| | | | | | | | | | | | CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <[email protected]>
* CMake: Don't unset Qt6Qml_FOUND when including Qml pluginsAlexandru Croitor2022-07-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | Removing the variable would cause nested find_dependency calls of FooQmlPluginDependencies.cmake files to look for the Qml package again and again. If we got to the point of including QmlPlugins.cmake, we already know that the Qml package was found. Set it to TRUE after every inclusion to avoid repeated Qml package loading. The second inclusion pass will ensure to set the found variable to FALSE in case if some dependency is actually missing. Amends aad4158959890b72afdd062614c1142c100c65b5 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I562a1c2ea0abac61453a743ab2e7d2f228de7ff0 Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Record the precise package name where Private modules liveAlexandru Croitor2022-07-251-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously if a target depended on CorePrivate, we would write a _qt_internal_find_qt_dependencies(... Qt6CorePrivate) call into a FooDependencies.cmake file. That find_qt_deps call would remove the 'Private' suffix and would run find_dependency with NAMES set to both the altered and non-altered names. This would find the relevant package but it would set the wrong _FOUND variable name, e.g it would set Qt6CorePrivate_FOUND instead of Qt6Core_FOUND. This in turn could cause multiple lookups of the Qt6Core package during dependency handling because the correct _FOUND var would not be set. Instead of always looking for the Qt6CorePrivate package, make sure we look for an appropriately named package for all Privates modules, because we have the necessary info to determine the correct name. Note that INTERNAL modules will still be looked up via a Private suffixed package name because that's how the package name is chosen for them. Remove the code that accounted for Private modules in qt_internal_remove_qt_dependency_duplicates because it's not needed anymore. Warn when a package name can't be queried from a target's property because the target might not exist yet. Add a TODO comment for the code that searches with two NAMES. We can't remove it right now, because it might break user projects that use stale Dependencies.cmake files. The dbus subdirectory is added before the tools subdirectory to ensure that the new package name extraction does not error out, due to trying to access a target that does not yet exist. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Ib34ae5ed92f68b4265518c2b8802daeb1a3a04d6 Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Move QT_HOST_PATH check and computation into Qt6 packageAlexandru Croitor2022-07-251-0/+8
| | | | | | | | | | | | | | | | Instead of trying to compute and validate the QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR variables in the generated toolchain file, do it in the Qt6 package. This provides better error messages when a project is configured without using the Qt generated toolchain file. Because it's not done in the toolchain anymore, remove the various host variables from __qt_toolchain_used_variables. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I1ca239ff83b8f783897e171fee352fc43e8ad7a8 Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Improve Qt6HostInfo package lookup conditionAlexandru Croitor2022-07-251-1/+3
| | | | | | | | | | | | | | | | | | | Instead of checking if QT_HOST_PATH is set during user project configuration to find out if Qt6HostInfo should be looked up, record if QT_HOST_PATH was provided during Qt configuration into Qt6Dependencies.cmake and look up the package in a user project based on that information. This improves handling of the case where cmake is directly used to configure a Qt project (instead of qt-cmake), which means no QT_HOST_PATH might be set by the user, and then cmake would error out saying that e.g. Qt6CoreTools is not found, instead of saying that Qt6HostInfo is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I0377d5440e4b5b295af73cfd4b5188f61d48e440 Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Process extra dependencies for plugin targets as wellAlexandru Croitor2022-07-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We started recording extra dependencies for the QtNetwork TLS plugin, but we never actually processed them to write out the necessary find_package calls. This broke static builds of qtopcua, because the OpenSSL::SSL target was no longer created in the root scope, but only in some child ones like src/opcua, whereas the target was referenced in generator expressions in a different sibling scope src/declarative_opcua, leading to errors like CMake Error at lib/cmake/Qt6/QtPrlHelpers.cmake:116 (file): Error evaluating generator expression: $<TARGET_LINKER_FILE:OpenSSL::SSL> No target "OpenSSL::SSL" Call Stack (most recent call first): lib/cmake/Qt6/QtModuleHelpers.cmake:837 (qt_generate_prl_file) lib/cmake/Qt6/QtScopeFinalizerHelpers.cmake:21:EVAL:1 (qt_finalize_module) src/declarative_opcua/CMakeLists.txt:DEFERRED Make sure to process the extra deps for plugins as well. Amends d754e43721e4f40a8dffa8b69ef883ca383a4a61 Amends 3c233175523a61e734dd5cd9bdcbb2994566f7f0 Pick-to: 6.4 Task-number: QTBUG-96283 Change-Id: I11876e0844198b3a794bc06b6691ee694fd3b1c2 Reviewed-by: Alexey Edelev <[email protected]>
* CMake: Don't create duplicate plugin targets in shared buildsAlexandru Croitor2022-07-081-8/+6
| | | | | | | | | | | | | | | | | | | | when building Qt repositories. When building for example qtquick3d, the Qt6QmlPlugins.cmake file should not load the qtquick3d specific plugin config files because the targets will be created as part of the build and cause duplicate errors. We already did it for static builds, but now we also do it for shared builds. Amends 7d6f1ee5a75cae9d122a3f0c7b3a6d03f380535e Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25 Pick-to: 6.4 Task-number: QTBUG-94066 Change-Id: I66ca71dfa6485eded94c1ecb5eb3b23daf908b39 Reviewed-by: Jörg Bornemann <[email protected]>
* CMake: Create and include plugin packages in shared buildsAlexandru Croitor2022-07-051-8/+5
| | | | | | | | | | | | | | | | | | | | | | Previously QtModulePlugins.cmake files were only created and included in static library Qt builds. Having the targets available in shared library builds would be useful for custom project deployment purposes. One could query the location of the plugins or use various generator expressions referencing their location. Ensure we always generate and include the QtModulePlugins.cmake files regardless of the build type. Allow opting out of including the files by setting QT_SKIP_AUTO_PLUGIN_INCLUSION to ON, just like we allow for Qml plugins with QT_SKIP_AUTO_QML_PLUGIN_INCLUSION. Pick-to: 6.4 Fixes: QTBUG-94066 Change-Id: I69a5dc17762a8e43265578fc33b82b5c4b7a1f5c Reviewed-by: Jörg Bornemann <[email protected]>
* CMake: Improve 'Generating Plugins' messageAlexandru Croitor2022-07-051-1/+6
| | | | | | | | | | | | | | Use message(STATUS) for the 'Generating Plugins' message. This way it will go to stdout instead of stderr, which follows the convention we have for most of our other messages. Also list only the modules that actually have plugins, rather than all known modules. Pick-to: 6.2 6.3 6.4 Change-Id: I1ea0ed71418ede54790cabd32e03e82fc69f2858 Reviewed-by: Jörg Bornemann <[email protected]>
* CMake: Record used package version for each target dependencyAlexandru Croitor2022-07-011-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <[email protected]> Reviewed-by: Alexey Edelev <[email protected]> Reviewed-by: Jörg Bornemann <[email protected]>
* CMake: Fix typosKai Köhne2022-06-131-2/+2
| | | | | | | | Found by codespell Pick-to: 6.4 Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e Reviewed-by: Jörg Bornemann <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2025-11-30 19:52:46 +0000