1berry/qtbase
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
qtbase/cmake/QtModuleHelpers.cmake

1890 lines
79 KiB
CMake
Raw Normal View History

Add license headers to cmake files 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 <joerg.bornemann@qt.io>
2022-07-05 13:26:52 +02:00
# Copyright (C) 2022 The Qt Company Ltd.
Change the license of all CMakeLists.txt and *.cmake files to BSD Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-19 15:21:34 +02:00
# SPDX-License-Identifier: BSD-3-Clause
Add license headers to cmake files 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 <joerg.bornemann@qt.io>
2022-07-05 13:26:52 +02:00
CMake: Provide supported qt_internal_add_module() args via a function This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-18 17:00:01 +10:00
macro(qt_internal_get_internal_add_module_keywords option_args single_args multi_args)
set(${option_args}
STATIC
EXCEPTIONS
CMake: Add a way to mark modules as "load the private module too" Add FIND_PRIVATE_MODULE argument to qt_internal_add_module. If this argument is set for Qt6Foo, then find_package(Qt6Foo) will also find_package(Qt6FooPrivate). This should only be necessary in exceptional cases like Qt6Qml where Qt6QmlPrivate is used unconditionally. Task-number: QTBUG-87776 Change-Id: I8d6fbd0624c0008fc42294ff2d2ed36848963508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-27 10:02:23 +01:00
FIND_PRIVATE_MODULE
CMake: Provide supported qt_internal_add_module() args via a function This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-18 17:00:01 +10:00
INTERNAL_MODULE
HEADER_MODULE
DISABLE_TOOLS_EXPORT
SKIP_DEPENDS_INCLUDE
NO_MODULE_HEADERS
NO_SYNC_QT
NO_PRIVATE_MODULE
NO_CONFIG_HEADER_FILE
NO_ADDITIONAL_TARGET_INFO
NO_GENERATE_METATYPES
Add NO_HEADERSCLEAN_CHECK flag to qt_internal_add_module Some modules may have header files that do not pass headersclean check under some conditions. It's nice to have an option in the qt_internal_add_module function to disable the check for the modules of this kind. At the moment this flag is useful for the ActiveQt module, since it syncs and installs header files that don't belong to it. Amends b89d63515bb352cecfd87e709320a2db5b6a1906 Task-number: QTBUG-103196 Change-Id: I21a82d50d50bdac225ed483ab0cc50339c2a4873 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-24 18:35:12 +02:00
NO_HEADERSCLEAN_CHECK
Introduce NO_GENERATE_CPP_EXPORTS argument for qt_internal_add_module The argument is inverted GENERATE_CPP_EXPORTS argument. Use it explicitly for the modules that do not require the autogenerated cpp exports. Task-number: QTBUG-90492 Change-Id: Ic67772ba9ed5e40f132a97e7d6844102ad023ff3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-11-28 14:01:19 +01:00
NO_GENERATE_CPP_EXPORTS
Add some utilities for UNITY_BUILD - The following commands accepts NO_UNITY_BUILD, and NO_UNITY_BUILD_SOURCES arguments to opt out of the unity build, and to exclude some source files from unity build, respectively. - qt_internal_add_executable - qt_internal_add_module - qt_internal_add_plugin - qt_internal_add_tool - qt_internal_extend_target - qt_internal_add_common_qt_library_helper - qt_internal_add_cmake_library - qt_internal_add_simd_part - Unity build is disabled by default in these: - qt_internal_add_test - qt_internal_add_test_helper - qt_internal_add_benchmark - qt_internal_add_3rdparty_library - qt_update_ignore_pch_source also excludes the files from unity_build Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I5d0e7df633738310a015142a6c73fbb78b6c3467 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-31 14:05:16 +01:00
NO_UNITY_BUILD
CMake: Allow specifying most SBOM options to qt_internal_add_foo Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-06-14 19:07:16 +02:00
${__qt_internal_sbom_optional_args}
CMake: Provide supported qt_internal_add_module() args via a function This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-18 17:00:01 +10:00
)
set(${single_args}
MODULE_INCLUDE_NAME
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
MODULE_INTERFACE_NAME
CMake: Provide supported qt_internal_add_module() args via a function This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-18 17:00:01 +10:00
CONFIG_MODULE_NAME
PRECOMPILED_HEADER
CONFIGURE_FILE_PATH
Expose cpp export related arguments for qt_internal_add_module users Functions that use qt_internal_add_module under the hood might need to generate cpp exports, e.g. qt_internal_add_qml_module. Append cpp exports related arguments to the qt_internal_add_module arguments set. Task-number: QTBUG-90492 Change-Id: I4fd539bd1d8be4d3e57ed5b1b88dd2dbc2f5ca24 Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-09-10 17:24:43 +02:00
CPP_EXPORT_HEADER_BASE_NAME
Install 3rdparty headers for static builds For static builds we need 3rdparty headers to be installed. Leaf modules like qtwebengine needs 3rdparty libs and header for zlib, freetype, harfbuzz, png, jpeg. Without those the Chromium bundled versions are used, however it might end up badly if qt has already bundled one. Introduce new header only modules with additional arguments for qt_internal_add_module: * EXTERNAL_HEADERS to pick exactly which headers are public * EXTERNAL_HEADERS_DIR to include whole directory preserving the files directory structure Fix qtsync so it keep directory structure for all non-qt modules when syncing headers and do not generate warnings for headers files. Task-number: QTBUG-87154 Task-number: QTBUG-88614 Change-Id: If1c27bf8608791cd4e0a21839d6316a445a96e9f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-12-14 09:54:33 +01:00
EXTERNAL_HEADERS_DIR
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
PRIVATE_HEADER_FILTERS
QPA_HEADER_FILTERS
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
RHI_HEADER_FILTERS
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
SSG_HEADER_FILTERS
Replace the syncqt.pl script with syncqt tool 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 <alexandru.croitor@qt.io>
2022-08-15 18:29:41 +02:00
HEADER_SYNC_SOURCE_DIRECTORY
CMake: Provide supported qt_internal_add_module() args via a function This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-18 17:00:01 +10:00
${__default_target_info_args}
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 18:02:56 +01:00
${__qt_internal_sbom_single_args}
CMake: Provide supported qt_internal_add_module() args via a function This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-18 17:00:01 +10:00
)
set(${multi_args}
QMAKE_MODULE_CONFIG
EXTRA_CMAKE_FILES
EXTRA_CMAKE_INCLUDES
Install 3rdparty headers for static builds For static builds we need 3rdparty headers to be installed. Leaf modules like qtwebengine needs 3rdparty libs and header for zlib, freetype, harfbuzz, png, jpeg. Without those the Chromium bundled versions are used, however it might end up badly if qt has already bundled one. Introduce new header only modules with additional arguments for qt_internal_add_module: * EXTERNAL_HEADERS to pick exactly which headers are public * EXTERNAL_HEADERS_DIR to include whole directory preserving the files directory structure Fix qtsync so it keep directory structure for all non-qt modules when syncing headers and do not generate warnings for headers files. Task-number: QTBUG-87154 Task-number: QTBUG-88614 Change-Id: If1c27bf8608791cd4e0a21839d6316a445a96e9f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-12-14 09:54:33 +01:00
EXTERNAL_HEADERS
CMake: Add qt 'policy' support This mimics CMake's policy support. The policy state is stored in an internal __QT_INTERNAL_POLICY_<policy> variable; by using normal variables, we gain support for stacking for free. Policies can be explicitly en- or disable via qt6_policy; that command also has a GET mode to retrieve them again. Furthermore, one can now pass min and max version to qt6_standard_project_setup, to opt in to a certain set of defaults introduced in a given Qt version. We add support for policies in QtModuleHelpers, so that we can check for known policies while building Qt itself. No actual policies exist yet; but a follow up commit will introduce one for qt_add_qml_module. Change-Id: I57a0404c9193926dd499f94cc5f73e359355c0b3 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-12-06 21:07:38 +01:00
POLICIES
CMake: Provide supported qt_internal_add_module() args via a function This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-18 17:00:01 +10:00
${__default_private_args}
${__default_public_args}
${__default_private_module_args}
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 18:02:56 +01:00
${__qt_internal_sbom_multi_args}
CMake: Provide supported qt_internal_add_module() args via a function This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-18 17:00:01 +10:00
)
endmacro()
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
# The function helps to wrap module include paths with the header existence check.
function(qt_internal_append_include_directories_with_headers_check target list_to_append type)
string(TOLOWER "${type}" type)
string(JOIN "" has_headers_check
"$<BOOL:"
"$<TARGET_PROPERTY:"
"$<TARGET_NAME:${target}>,"
"_qt_module_has_${type}_headers"
">"
">"
)
foreach(directory IN LISTS ARGN)
list(APPEND ${list_to_append}
"$<${has_headers_check}:${directory}>")
endforeach()
set(${list_to_append} "${${list_to_append}}" PARENT_SCOPE)
endfunction()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
# This is the main entry function for creating a Qt module, that typically
# consists of a library, public header files, private header files and configurable
# features.
#
# A CMake target with the specified target parameter is created. If the current source
# directory has a configure.cmake file, then that is also processed for feature definition
# and testing. Any features defined as well as any features coming from dependencies to
# this module are imported into the scope of the calling feature.
#
# Target is without leading "Qt". So e.g. the "QtCore" module has the target "Core".
QtEntryPoint: Fix linking Release against RelWithDebInfo with MSVC To be able to link a Release user project against a RelWithDebInfo Qt we set several IMPORTED_*_RELEASE properties in the *AdditionalTargetInfo.cmake file of each Qt module. The EntryPoint module however is a bit special as it is an INTERFACE_LIBRARY linking publicly against a static library (EntryPointimplementation). Its *AdditionalTargetInfo.cmake file was almost empty, because qt_internal_export_additional_targets_file was called before EntryPointImplementation was set up. Also, qt_internal_add_module, which calls qt_internal_export_additional_targets_file, does not know that we want to export the EntryPointImplementation target. We fix this by telling qt_internal_add_module(EntryPoint) to not generate the *AdditionalTargetInfo.cmake file and call qt_internal_export_additional_targets_file later to take the targets EntryPoint and EntryPointImplementation into consideration. qt_internal_add_module learned the option NO_ADDITIONAL_TARGET_INFO to turn off the generation of *AdditionalTargetInfo.cmake files. Pick-to: 6.0 Fixes: QTBUG-90039 Change-Id: I68ec7125b538a57567035e7adb8dac3b213f95e6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-01-15 15:48:59 +01:00
#
# Options:
# NO_ADDITIONAL_TARGET_INFO
# Don't generate a Qt6*AdditionalTargetInfo.cmake file.
#
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
# MODULE_INTERFACE_NAME
# The custom name of the module interface. This name is used as a part of the include paths
# associated with the module and other interface names. The default value is the target name.
# If the INTERNAL_MODULE option is specified, MODULE_INTERFACE_NAME is not specified and the
# target name ends with the suffix 'Private', the MODULE_INTERFACE_NAME value defaults to the
# non-suffixed target name, e.g.:
# For the SomeInternalModulePrivate target, the MODULE_INTERFACE_NAME will be
# SomeInternalModule
#
qt_internal_add_module: Document HEADER_MODULE and STATIC Task-number: QTBUG-94863 Change-Id: If52ed7e17ea77d8cb6e0255e988feb0b1bd0aa76 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-11-26 09:42:27 +01:00
# HEADER_MODULE
# Creates an interface library instead of following the Qt configuration default. Mutually
# exclusive with STATIC.
#
# STATIC
# Creates a static library instead of following the Qt configuration default. Mutually
# exclusive with HEADER_MODULE.
#
Install 3rdparty headers for static builds For static builds we need 3rdparty headers to be installed. Leaf modules like qtwebengine needs 3rdparty libs and header for zlib, freetype, harfbuzz, png, jpeg. Without those the Chromium bundled versions are used, however it might end up badly if qt has already bundled one. Introduce new header only modules with additional arguments for qt_internal_add_module: * EXTERNAL_HEADERS to pick exactly which headers are public * EXTERNAL_HEADERS_DIR to include whole directory preserving the files directory structure Fix qtsync so it keep directory structure for all non-qt modules when syncing headers and do not generate warnings for headers files. Task-number: QTBUG-87154 Task-number: QTBUG-88614 Change-Id: If1c27bf8608791cd4e0a21839d6316a445a96e9f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-12-14 09:54:33 +01:00
# EXTERNAL_HEADERS
# A explicit list of non qt headers (like 3rdparty) to be installed.
# Note this option overrides install headers used as PUBLIC_HEADER by cmake install(TARGET)
# otherwise set by syncqt.
#
# EXTERNAL_HEADERS_DIR
# A module directory with non qt headers (like 3rdparty) to be installed.
# Note this option overrides install headers used as PUBLIC_HEADER by cmake install(TARGET)
# otherwise set by syncqt.
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
#
# PRIVATE_HEADER_FILTERS
# The regular expressions that filter private header files out of target sources.
# The value must use the following format 'regex1|regex2|regex3'.
#
# QPA_HEADER_FILTERS
# The regular expressions that filter QPA header files out of target sources.
# The value must use the following format 'regex1|regex2|regex3'.
Replace the syncqt.pl script with syncqt tool 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 <alexandru.croitor@qt.io>
2022-08-15 18:29:41 +02:00
#
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
# RHI_HEADER_FILTERS
# The regular expressions that filter RHI header files out of target sources.
# The value must use the following format 'regex1|regex2|regex3'.
#
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
# SSG_HEADER_FILTERS
# The regular expressions that filter ssg header files out of target sources.
# The value must use the following format 'regex1|regex2|regex3'.
#
Replace the syncqt.pl script with syncqt tool 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 <alexandru.croitor@qt.io>
2022-08-15 18:29:41 +02:00
# HEADER_SYNC_SOURCE_DIRECTORY
# The source directory for header sync procedure. Header files outside this directory will be
# ignored by syncqt. The specifying this directory allows to skip the parsing of the whole
# CMAKE_CURRENT_SOURCE_DIR for the header files that needs to be synced and only parse the
# single subdirectory, that meanwhile can be outside the CMAKE_CURRENT_SOURCE_DIR tree.
CMake: Add a way to mark modules as "load the private module too" Add FIND_PRIVATE_MODULE argument to qt_internal_add_module. If this argument is set for Qt6Foo, then find_package(Qt6Foo) will also find_package(Qt6FooPrivate). This should only be necessary in exceptional cases like Qt6Qml where Qt6QmlPrivate is used unconditionally. Task-number: QTBUG-87776 Change-Id: I8d6fbd0624c0008fc42294ff2d2ed36848963508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-27 10:02:23 +01:00
#
# FIND_PRIVATE_MODULE
# A call to find_package(Qt6Foo) will imply a call to find_package(Qt6FooPrivate).
CMake: Rename internal functions to contain qt_internal Offer compatibility wrapper functions until we update all of the Qt repos to use the new names. Task-number: QTBUG-86815 Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2020-09-22 10:02:27 +02:00
function(qt_internal_add_module target)
CMake: Provide supported qt_internal_add_module() args via a function This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-18 17:00:01 +10:00
qt_internal_get_internal_add_module_keywords(
Implement generating of private cpp exports Add the generating of private cpp exports for Qt modules. Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module that is the manual switch for private exports generator. Existing modules in qtbase doesn't follow any strict convention of using private cpp export. So there is no clue how to detect if generating of the private exports is required or not for the module. Use autogenerated private cpp exports in QtNetwork module. CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different meaning. The provided name is used as a base name for the private and non-private headers that contains cpp exports. Header files suffixes are constant: .h and _p.h for the non-private and private header files accordingly. Pick-to: 6.2 Task-number: QTBUG-90492 Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-30 17:51:07 +02:00
module_option_args
module_single_args
module_multi_args
)
Retire the qt_parse_all_arguments This replaces the qt_parse_all_arguments macro with the built-in `cmake_parse_arguments(PARSE_ARGV`. In addition, a new function, _qt_internal_validate_all_args_are_parsed, can be used to check whether any _UNPARSED_ARGUMENTS have been passed to the function. Fixes: QTBUG-99238 Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-11 15:36:18 +01:00
cmake_parse_arguments(PARSE_ARGV 1 arg
Expose cpp export related arguments for qt_internal_add_module users Functions that use qt_internal_add_module under the hood might need to generate cpp exports, e.g. qt_internal_add_qml_module. Append cpp exports related arguments to the qt_internal_add_module arguments set. Task-number: QTBUG-90492 Change-Id: I4fd539bd1d8be4d3e57ed5b1b88dd2dbc2f5ca24 Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-09-10 17:24:43 +02:00
"${module_option_args}"
"${module_single_args}"
"${module_multi_args}"
CMake: Provide supported qt_internal_add_module() args via a function This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-18 17:00:01 +10:00
)
Retire the qt_parse_all_arguments This replaces the qt_parse_all_arguments macro with the built-in `cmake_parse_arguments(PARSE_ARGV`. In addition, a new function, _qt_internal_validate_all_args_are_parsed, can be used to check whether any _UNPARSED_ARGUMENTS have been passed to the function. Fixes: QTBUG-99238 Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-11 15:36:18 +01:00
_qt_internal_validate_all_args_are_parsed(arg)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
CMake: Export a few useful Qt module target properties These include: _qt_package_name _qt_is_public_module _qt_is_private_module _qt_public_module_target_name _qt_private_module_target_name Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I012463944de8fc333f477a7880f9d27a69d6ef47 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 13:20:06 +02:00
set(is_internal_module FALSE)
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
if(arg_INTERNAL_MODULE)
CMake: Export a few useful Qt module target properties These include: _qt_package_name _qt_is_public_module _qt_is_private_module _qt_public_module_target_name _qt_private_module_target_name Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I012463944de8fc333f477a7880f9d27a69d6ef47 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 13:20:06 +02:00
set(is_internal_module TRUE)
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
set(arg_INTERNAL_MODULE "INTERNAL_MODULE")
set(arg_NO_PRIVATE_MODULE TRUE)
# Assume the interface name of the internal module should be the module name without the
# 'Private' suffix.
if(NOT arg_MODULE_INTERFACE_NAME)
if(target MATCHES "(.*)Private$")
set(arg_MODULE_INTERFACE_NAME "${CMAKE_MATCH_1}")
else()
message(WARNING "The internal module target should end with the 'Private' suffix.")
endif()
endif()
else()
unset(arg_INTERNAL_MODULE)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
if(NOT arg_MODULE_INTERFACE_NAME)
set(arg_MODULE_INTERFACE_NAME "${target}")
endif()
CMake: Cleanup module and plugin define situation The QT.<module>.DEFINES assignment in pri files needs to take into account the module name when computing the define name. This is the MODULE value that qmake specifies. In CMake that would be the value of CONFIG_MODULE_NAME. Previously the value of the define was computed in qt_internal_module_info() without taking into account the module name. While qt_internal_module_info() ended being used also for plugins and other target types, the defines computed by it were meant to be used only for Qt modules. Thus remove the <result>_define assignment from qt_internal_module_info and move its computation directly into qt_internal_add_module, taking into account the value of CONFIG_MODULE_NAME. The only other use of module_define was in qt_internal_add_plugin but that was merely a long overdue copy-paste error, qmake doesn't propagate QT_FOO_LIB defines for plugins. As result, a define special case in testlib is not needed anymore, because the define is now computed properly. Finally, QT_FOO_LIB should not be used while building the Qt module itself, so instead of using PUBLIC_DEFINES option of qt_internal_extend_target, use target_compile_definitions(INTERFACE) directly. Change-Id: I4d44f7461bac2f0c09aec3e995d02dfe36e00883 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-30 13:29:55 +01:00
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
### Define Targets:
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 12:35:18 +02:00
if(arg_HEADER_MODULE)
set(type_to_create INTERFACE)
elseif(arg_STATIC)
set(type_to_create STATIC)
else()
# Use default depending on Qt configuration.
set(type_to_create "")
endif()
_qt_internal_add_library("${target}" ${type_to_create})
CMake: Don't propagate -fapplication-extension to user projects Both the compiler and linker -fapplication-extension flag should only be applied when building Qt's libraries (not executables). It's up to the user project whether their code will be restricted with application-extension-only APIs. In qmake that can be achieved by adding to the qmake project CONFIG += app_extension_api_only In CMake it can be achieved by either adding the compiler and link flags in the project directly (using target_X_options) or by setting the appropriate setting in the Xcode project when using the Xcode generator. Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b Pick-to: 6.2 Task-number: QTBUG-95199 Change-Id: Ie7a764d460a89c7650391abff0fcc5abfcabef64 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-15 13:04:15 +02:00
qt_internal_mark_as_internal_library("${target}")
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 12:35:18 +02:00
get_target_property(target_type ${target} TYPE)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
set(is_interface_lib 0)
set(is_shared_lib 0)
CMake: Disable static plugin imports for non-executable targets There is no point in generating cpp files containing Q_IMPORT_PLUGIN() macro calls for non-executable targets like modules, plugins and object libraries in a static Qt build. It causes unnecessary compiling of 10+ files for each of those targets. In a static Qt build, plugin imports should only be done for executables, tools and applications. Pick-to: 6.0 Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-30 19:28:00 +01:00
set(is_static_lib 0)
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 12:35:18 +02:00
if(target_type STREQUAL "INTERFACE_LIBRARY")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
set(is_interface_lib 1)
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 12:35:18 +02:00
elseif(target_type STREQUAL "STATIC_LIBRARY")
CMake: Disable static plugin imports for non-executable targets There is no point in generating cpp files containing Q_IMPORT_PLUGIN() macro calls for non-executable targets like modules, plugins and object libraries in a static Qt build. It causes unnecessary compiling of 10+ files for each of those targets. In a static Qt build, plugin imports should only be done for executables, tools and applications. Pick-to: 6.0 Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-30 19:28:00 +01:00
set(is_static_lib 1)
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 12:35:18 +02:00
elseif(target_type STREQUAL "SHARED_LIBRARY")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
set(is_shared_lib 1)
else()
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 12:35:18 +02:00
message(FATAL_ERROR "Invalid target type '${target_type}' for Qt module '${target}'")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
if(NOT arg_NO_SYNC_QT AND NOT arg_NO_MODULE_HEADERS AND arg_MODULE_INCLUDE_NAME)
# qt_internal_module_info uses this property if it's set, so it must be
# specified before the qt_internal_module_info call.
set_target_properties(${target} PROPERTIES
_qt_module_include_name ${arg_MODULE_INCLUDE_NAME}
)
endif()
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
set_target_properties(${target} PROPERTIES
_qt_module_interface_name "${arg_MODULE_INTERFACE_NAME}"
CMake: Record used package version for each target dependency When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 08:44:43 +02:00
_qt_package_version "${PROJECT_VERSION}"
CMake: Export a few useful Qt module target properties These include: _qt_package_name _qt_is_public_module _qt_is_private_module _qt_public_module_target_name _qt_private_module_target_name Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I012463944de8fc333f477a7880f9d27a69d6ef47 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 13:20:06 +02:00
_qt_package_name "${INSTALL_CMAKE_NAMESPACE}${target}"
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
)
CMake: Export a few useful Qt module target properties These include: _qt_package_name _qt_is_public_module _qt_is_private_module _qt_public_module_target_name _qt_private_module_target_name Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I012463944de8fc333f477a7880f9d27a69d6ef47 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 13:20:06 +02:00
set(export_properties
"_qt_module_interface_name"
"_qt_package_version"
"_qt_package_name"
)
Introduce Qt<Module>TransitiveExtras.cmake for Qt modules This file sets the transitive module properties provided by Qt Module that is built using CMake versions < 3.30. The idea is to not limit user projects capabilities and allow using transitive Qt Module properties if user CMake version allows it. If Qt Modules are built using CMake versions >= 3.30 this code is noop, since values are stored directly in the respective INTERFACE_properties. Change-Id: I5a0bc0aa4f79a04c81dfa0fee1d37cfee5935b0f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-05-21 16:28:02 +02:00
if(CMAKE_VERSION VERSION_LESS 3.30)
# For the CMake versions higher than 3.30 the corresponding INTERFACE_
# properties will be in Qt<Module>Targets.cmake without extra code
# needed.
list(APPEND export_properties
"_qt_transitive_compile_properties"
"_qt_transitive_link_properties"
)
endif()
CMake: Export a few useful Qt module target properties These include: _qt_package_name _qt_is_public_module _qt_is_private_module _qt_public_module_target_name _qt_private_module_target_name Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I012463944de8fc333f477a7880f9d27a69d6ef47 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 13:20:06 +02:00
if(NOT is_internal_module)
set_target_properties(${target} PROPERTIES
_qt_is_public_module TRUE
)
list(APPEND export_properties
"_qt_is_public_module"
)
if(NOT ${arg_NO_PRIVATE_MODULE})
set_target_properties(${target} PROPERTIES
_qt_private_module_target_name "${target}Private"
)
list(APPEND export_properties
"_qt_private_module_target_name"
)
endif()
endif()
set_property(TARGET ${target} APPEND PROPERTY EXPORT_PROPERTIES "${export_properties}")
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
qt_internal_module_info(module "${target}")
qt_internal_add_qt_repo_known_module("${target}")
Add missing PRIVATE_MODULE_INTERFACEs to INTERNAL_MODULEs To detect the internal module ouside the qt_internal_add_module function need to mark it with the property. This adds _qt_is_internal_module property to the Qt internal modules. Since PRIVATE_MODULE_INTERFACE only was applicable to pure Private modules, INTERNAL_MODULEs is missing those dependencies if they were specified. Add extra condition to qt_internal_extend_target to link PRIVATE_MODULE_INTERFACE libraries to internal modules as well. Pick-to: 6.2 6.1 Change-Id: I9c32fa5bad3aff365f5d7663349e5365d5f1d72d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-24 13:30:51 +02:00
if(arg_INTERNAL_MODULE)
set_target_properties(${target} PROPERTIES _qt_is_internal_module TRUE)
set_property(TARGET ${target} APPEND PROPERTY EXPORT_PROPERTIES _qt_is_internal_module)
endif()
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 18:02:56 +01:00
if(arg_HEADER_MODULE)
set_target_properties(${target} PROPERTIES _qt_is_header_module TRUE)
set_property(TARGET ${target} APPEND PROPERTY EXPORT_PROPERTIES _qt_is_header_module)
endif()
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
if(NOT arg_CONFIG_MODULE_NAME)
set(arg_CONFIG_MODULE_NAME "${module_lower}")
endif()
Fix the naming of the config header files for private modules Perform a file name of the config header before adding a '_private' suffix. TODO: It makes sense to revisit the use of the CONFIG_MODULE_NAME variable since the variable is used for different purposes and mutate with use. Amends 8aee7c6b29be5a0ee7d5e7cfcb5f2db762b2e28b Pick-to: 6.2 Fixes: QTBUG-94568 Change-Id: Id5aaf8d423ec8b94afffe4641b54dab94b5453fb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-18 20:13:32 +02:00
set(module_config_header "qt${arg_CONFIG_MODULE_NAME}-config.h")
set(module_config_private_header "qt${arg_CONFIG_MODULE_NAME}-config_p.h")
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
# qt<module>-config.h/-config_p.h header files are not marked as GENERATED automatically
# for old CMake versions. Set the property explicitly here.
Use `_qt_internal_set_source_file_generated` Migrate implementations that set `GENERATED` source property Task-number: QTBUG-125077 Pick-to: 6.9 Change-Id: Ia77ecf8422bf3983f7746c26e5a9994d1f6415f2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-06 19:08:39 +01:00
_qt_internal_set_source_file_generated(
SOURCES "${module_config_header}" "${module_config_private_header}"
SKIP_AUTOGEN
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
)
Fix the naming of the config header files for private modules Perform a file name of the config header before adding a '_private' suffix. TODO: It makes sense to revisit the use of the CONFIG_MODULE_NAME variable since the variable is used for different purposes and mutate with use. Amends 8aee7c6b29be5a0ee7d5e7cfcb5f2db762b2e28b Pick-to: 6.2 Fixes: QTBUG-94568 Change-Id: Id5aaf8d423ec8b94afffe4641b54dab94b5453fb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-18 20:13:32 +02:00
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
# Module define needs to take into account the config module name.
string(TOUPPER "${arg_CONFIG_MODULE_NAME}" module_define_infix)
string(REPLACE "-" "_" module_define_infix "${module_define_infix}")
string(REPLACE "." "_" module_define_infix "${module_define_infix}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
set(property_prefix "INTERFACE_")
if(NOT arg_HEADER_MODULE)
set(property_prefix "")
endif()
Fix internal module naming in qmake .pri files Set the correct value to the _qt_config_module_name property at the internal module creating step instead of appending _private suffix when generating .pri files. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Pick-to: 6.2 Fixes: QTBUG-94568 Change-Id: I6fa8089358bc638668e313c98c3aee680bf7ec2a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-17 13:04:59 +02:00
if(arg_INTERNAL_MODULE)
string(APPEND arg_CONFIG_MODULE_NAME "_private")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
set_target_properties(${target} PROPERTIES
_qt_config_module_name "${arg_CONFIG_MODULE_NAME}"
${property_prefix}QT_QMAKE_MODULE_CONFIG "${arg_QMAKE_MODULE_CONFIG}")
set_property(TARGET "${target}" APPEND PROPERTY EXPORT_PROPERTIES _qt_config_module_name)
set(is_framework 0)
if(QT_FEATURE_framework AND NOT ${arg_HEADER_MODULE} AND NOT ${arg_STATIC})
set(is_framework 1)
set_target_properties(${target} PROPERTIES
FRAMEWORK TRUE
Use 'A' for Apple framework version instead of Qt major version All system frameworks use 'A' instead of the major version of the framework, and Xcode's code signing assumes that the framework version is 'A' when signing embedded frameworks (FB7323980), so leave the version 'A'. This is also what Apple recommends. Change-Id: Idbf2e30e156c3e869da8f75731e568524d9407e5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-07-22 15:44:43 +02:00
FRAMEWORK_VERSION "A" # Not based on Qt major version
Make framework names consistent with the module names For Apple's frameworks it's possible to include header files using the following assumption: If the framework name is "MyFramework" then '#include <MyFramework/frameworkheader.h>' will work without specifying the include path explicitly. This is broken for internal modules since they use the framework name with the 'Private' suffix. This uses the module name instead of the target name as a framework name. Amends edbe0eb335ca4c0fde23f57eae5acdf80937c9e3 Task-number: QTBUG-87775 Change-Id: I0592a28d0768724b6e10ca81aa7cefb0a3699a5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-01 11:25:41 +02:00
MACOSX_FRAMEWORK_IDENTIFIER org.qt-project.${module}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
MACOSX_FRAMEWORK_BUNDLE_VERSION ${PROJECT_VERSION}
MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}
)
Make framework names consistent with the module names For Apple's frameworks it's possible to include header files using the following assumption: If the framework name is "MyFramework" then '#include <MyFramework/frameworkheader.h>' will work without specifying the include path explicitly. This is broken for internal modules since they use the framework name with the 'Private' suffix. This uses the module name instead of the target name as a framework name. Amends edbe0eb335ca4c0fde23f57eae5acdf80937c9e3 Task-number: QTBUG-87775 Change-Id: I0592a28d0768724b6e10ca81aa7cefb0a3699a5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-01 11:25:41 +02:00
qt_internal_get_framework_info(fw ${target})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
CMake: fix the word order in "no_direct_extern_access" And take the opportunity to remove the "m" in the qmake feature name and .prf file. Pick-to: 6.4 Change-Id: I36b24183fbd041179f2ffffd170224ab75cdd968 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-15 16:32:11 -07:00
if(NOT QT_FEATURE_no_direct_extern_access AND QT_FEATURE_reduce_relocations AND
Enable -mno-direct-extern-access and ELF protected visibility The -mno-direct-extern-access tells the compiler and linker that references to symbols outside this ELF module mustn't be direct and must instead always go through the GOT or PLT (the PLT can additionally be disabled with -fno-plt). The ELF protected visibility tells the compiler and linker that this symbol is present in the dynamic symbol table as an export, but it cannot be interposed by another ELF module. This option is required for user code to link properly to Qt, otherwise they will get linker errors (assuming GNU binutils >= 2.39) or runtime failures (glibc >= 2.35). Both versions of glibc and binutils are older than GCC 12, so it's a safe assumption they are in use and downgrading the toolchain or libc is not supported. Adding this option to the compilation is assured for CMake and qmake-based projects. For example, all accessess to QCoreApplication::self in QtCore, after this change and with GCC 12 are relocation-free and direct: 000000000013ebf0 <QCoreApplicationPrivate::checkInstance(char const*)>: 13ebf0: cmpq $0x0,0x4f73d0(%rip) # 635fc8 <QCoreApplication::self> 13ebf8: setne %al 13ebfb: je a90fe <QCoreApplicationPrivate::checkInstance(char const*) [clone .cold]> 13ec01: ret Meanwhile, accesses to the same variable in other modules are indirect via the GOT: 66650: mov 0x876e1(%rip),%rax # edd38 <QCoreApplication::self@Qt_6> 66657: cmpq $0x0,(%rax) This replaces the -Bsymbolic and -Bsymbolic-functions (broken) functionality that Qt has been using or attempting to use since ~2006. See https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_606975128 Change-Id: Iad4b0a3e5c06570b9f5f571b26ed564aa0811e47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2012-01-23 11:46:58 -02:00
UNIX AND NOT is_interface_lib)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
# On x86 and x86-64 systems with ELF binaries (especially Linux), due to
# a new optimization in GCC 5.x in combination with a recent version of
# GNU binutils, compiling Qt applications with -fPIE is no longer
# enough.
# Applications now need to be compiled with the -fPIC option if the Qt option
# \"reduce relocations\" is active.
target_compile_options(${target} INTERFACE -fPIC)
if(GCC AND is_shared_lib)
target_link_options(${target} PRIVATE LINKER:-Bsymbolic-functions)
endif()
endif()
CMake: Make LTO build work We don't need to check FEATURE_ltcg, just add -fno-lto unconditionally. That makes QtCore compile with -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON. Change-Id: Icb2516126f674e7b8bb3fffd16ada2c71d7334aa Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-13 09:06:55 -07:00
if((FEATURE_ltcg OR CMAKE_INTERPROCEDURAL_OPTIMIZATION) AND GCC AND is_static_lib)
CMake: Use -ffat-lto-objects for static libraries with ltcg and GCC CMake <= 3.19 adds the '-fno-fat-lto-objects' compiler flag unconditionally when CMAKE_INTERPROCEDURAL_OPTIMIZATION is enabled. This is fine for shared libraries but static ones need the opposite compiler flag. Task-number: QTBUG-89426 Pick-to: 6.0 Change-Id: Ie5f48178803a270f6d94408f7a8e85d379eb123c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2021-01-13 09:19:32 +01:00
# CMake <= 3.19 appends -fno-fat-lto-objects for all library types if
# CMAKE_INTERPROCEDURAL_OPTIMIZATION is enabled. Static libraries need
# the opposite compiler option.
# (https://gitlab.kitware.com/cmake/cmake/-/issues/21696)
target_compile_options(${target} PRIVATE -ffat-lto-objects)
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
qt_internal_add_target_aliases("${target}")
Make per-repos WARNINGS_ARE_ERRORS work Add the WARNINGS_ARE_ERRORS flags unconditionally, so developers may control skipping per-target or per-repo. This allows setting the WARNINGS_ARE_ERRORS cmake option for each repo independently when configuring them. So qtbase might be built without the flag enabled and setting the WARNINGS_ARE_ERRORS to TRUE for the depending repo enables it for the internal Qt targets. Add the new internal function that controls the related internal flag. Keep qt_skip_warnings_are_errors for compatibility since it's used in qtwebengine. Combine qt_internal_set_skip_warnings_are_errors and qt_skip_warnings_are_errors_when_repo_unclean functionality in the new qt_internal_default_warnings_are_errors function. Change-Id: I1330c75cd67a24e6386f5e94a089e43fa2012bc4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-09-10 16:33:57 +02:00
qt_internal_default_warnings_are_errors("${target}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
# No need to compile Q_IMPORT_PLUGIN-containing files for non-executables.
if(is_static_lib)
_qt_internal_disable_static_default_plugins("${target}")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
# Add _private target to link against the private headers:
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
set(target_private "${target}Private")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
if(NOT ${arg_NO_PRIVATE_MODULE})
add_library("${target_private}" INTERFACE)
qt_internal_add_target_aliases("${target_private}")
set_target_properties(${target_private} PROPERTIES
CMake: Record used package version for each target dependency When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 08:44:43 +02:00
_qt_config_module_name ${arg_CONFIG_MODULE_NAME}_private
_qt_package_version "${PROJECT_VERSION}"
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 17:19:22 +01:00
_qt_package_name "${INSTALL_CMAKE_NAMESPACE}${target}Private"
CMake: Export a few useful Qt module target properties These include: _qt_package_name _qt_is_public_module _qt_is_private_module _qt_public_module_target_name _qt_private_module_target_name Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I012463944de8fc333f477a7880f9d27a69d6ef47 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 13:20:06 +02:00
_qt_is_private_module TRUE
_qt_public_module_target_name "${target}"
CMake: Record used package version for each target dependency When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 08:44:43 +02:00
)
CMake: Export a few useful Qt module target properties These include: _qt_package_name _qt_is_public_module _qt_is_private_module _qt_public_module_target_name _qt_private_module_target_name Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I012463944de8fc333f477a7880f9d27a69d6ef47 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 13:20:06 +02:00
set(export_properties
"_qt_config_module_name"
"_qt_package_version"
"_qt_package_name"
"_qt_is_private_module"
"_qt_public_module_target_name"
CMake: Record used package version for each target dependency When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 08:44:43 +02:00
)
CMake: Export a few useful Qt module target properties These include: _qt_package_name _qt_is_public_module _qt_is_private_module _qt_public_module_target_name _qt_private_module_target_name Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I012463944de8fc333f477a7880f9d27a69d6ef47 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-19 13:20:06 +02:00
set_property(TARGET "${target_private}" APPEND PROPERTY
EXPORT_PROPERTIES "${export_properties}")
CMake: Simplify Qt6FooPrivate -> Qt6Foo package dependency setup This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Remove the EXTRA_PACKAGE_DEPENDENCIES argument that was added in mentioned commit, and use the qt_register_target_dependencies function instead to add the package dependency Qt6FooPrivate -> Qt6Foo. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I08a48954576dc3c0b6fde809f90d2022201d7eb0 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-06 11:15:12 +01:00
# Let find_package(Qt6FooPrivate) also find_package(Qt6Foo).
Replace qt_record_extra_qt_package_dependency with qt_register_target_dependencies qt_register_target_dependencies does the same thing as qt_record_extra_qt_package_dependency but in more convenient way. Update the qt_register_target_dependencies signature and adjust naming, it now accepts PUBLIC and PRIVATE multi-value arguments and called qt_internal_register_target_dependencies. Use it and deprecate qt_record_extra_qt_package_dependency. Pick-to: 6.5 6.8 6.9 Change-Id: I0594cf699ec1e3af7210dd7450fa3f81c1f565ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-07 17:51:30 +01:00
qt_internal_register_target_dependencies("${target_private}" PUBLIC "Qt::${target}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
Enable shared library build of Qt for iOS As of f68e2c92cc0ed2c1929140402c061359bc2363a5, and its follow up changes, we can now link individual plugins statically, even if the Qt build is generally a shared build. This allows us to build Qt for iOS as shared libraries, while still keeping the platform plugin as a static library, since this is harder to port over to a shared library. This gives the benefit of faster turnaround during development, as well as binary compatibility promises for the main Qt libraries, without having to go fully shared for all of Qt. Static builds are still the default, due to the downsides of larger application bundles and slower load times for shared builds. For now the user has to manually tick the "Embed & Sign" check box in Xcode for each Qt library, which is only available with Xcode projects generated by the qmake Xcode generator. Task-number: QTBUG-85974 Change-Id: Id2b7bd2823c8e7c79068dda95295b574ada8d7f2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-12-16 16:34:31 +01:00
# FIXME: This workaround is needed because the deployment logic
# for iOS and WASM just copies/embeds the directly linked library,
# which will just be a versioned symlink to the actual library.
if((UIKIT OR WASM) AND BUILD_SHARED_LIBS)
wasm: disable x.y.z suffix versioning This simplifies deployment and eliminates the possibility for duplicate downloads due to the browser/server not understanding symlinks. Change-Id: Ife22c052c424f309d76ff0f9118c01e98426da95 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-11-08 10:59:02 +01:00
set(version_args "")
else()
set(version_args
VERSION ${PROJECT_VERSION}
SOVERSION ${PROJECT_VERSION_MAJOR})
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
if(NOT arg_HEADER_MODULE)
set_target_properties(${target} PROPERTIES
LIBRARY_OUTPUT_DIRECTORY "${QT_BUILD_DIR}/${INSTALL_LIBDIR}"
RUNTIME_OUTPUT_DIRECTORY "${QT_BUILD_DIR}/${INSTALL_BINDIR}"
ARCHIVE_OUTPUT_DIRECTORY "${QT_BUILD_DIR}/${INSTALL_LIBDIR}"
wasm: disable x.y.z suffix versioning This simplifies deployment and eliminates the possibility for duplicate downloads due to the browser/server not understanding symlinks. Change-Id: Ife22c052c424f309d76ff0f9118c01e98426da95 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-11-08 10:59:02 +01:00
${version_args}
)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
qt_set_target_info_properties(${target} ${ARGN})
qt_handle_multi_config_output_dirs("${target}")
CMake: Increase static library link multiplicity for VxWorks to 3 It appears that the VxWorks linker behaves similarly to GNU ld, where the order of link libraries on the command line matters. Our plugin linking system is not ideal (due cycles like Gui -> plugin -> Gui, or Qml -> qml plugin -> Qml), and can change the order of the linked libraries on the command line. Due to that, some of the qtdeclarative tests fail to link with undefined symbols in Qml. Apply the same workaround we did for Linux, which is to increase the LINK_INTERFACE_MULTIPLICITY of Qt modules to 3, effectively ensuring that each qt module static library appears at least 3 times on the link line, given the linker more chances to find relevant symbols. Amends 58a7e4f0bc5e9290cc205762d51adc5806b034fd More in detail reasoning explained in commit message of 69b27e09f55e63a713ca8b14f162d4f449c8dfff in qtquick3d Pick-to: 6.8 Fixes: QTBUG-129113 Task-number: QTBUG-83498 Change-Id: I7ac5665d4dd2865584ba1c96d51fd311ef224d10 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-10-25 14:30:02 +02:00
if(NOT BUILD_SHARED_LIBS AND (LINUX OR VXWORKS))
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
# Horrible workaround for static build failures due to incorrect static library link
# order. By increasing the multiplicity to 3, each library cycle will be repeated
# 3 times on the link line, reducing the probability of undefined symbols at
# link time.
# These failures are only observed on Linux with the ld linker (not sure about
# ld.gold).
# Allow opting out and modifying the value via cache value, in case if we urgently
# need to increase it without waiting for the qtbase change to propagate to
# other dependent repos.
# The proper fix will be to get rid of the cycles in the future.
# See QTBUG-83498 for details.
set(default_link_cycle_multiplicity "3")
if(DEFINED QT_LINK_CYCLE_MULTIPLICITY)
set(default_link_cycle_multiplicity "${QT_LINK_CYCLE_MULTIPLICITY}")
endif()
if(default_link_cycle_multiplicity)
set_property(TARGET "${target}"
PROPERTY
LINK_INTERFACE_MULTIPLICITY "${default_link_cycle_multiplicity}")
endif()
endif()
if (arg_SKIP_DEPENDS_INCLUDE)
CMake: Fix exclusion of QtFoo in QtBarDepends for 3rd party libs When configuring a static Qt with the -qt-zlib option and the build system creates a 3rd party header module QtZlib, syncqt does not generate a QtZlib header file that would include all its public headers. Then when the QtSvgDepends header is generated, it would add an #include <QtZlib> which would break compilation of the QtSvg PCH file (which compiles QtSvgDepends). We have logic to exclude addition of headers from regular 3rd party static libraries, but not header only 3rd party libraries. Adjust the code to handle header-only 3rd party libraries, as well as make sure it works across repos by exporting the relevant properties. As a drive-by, also rename and export some other informational properties. Amends af00402d6446c0f8f085a2a482fc83c4318aa457 Amends 6fdeaea24f9035ad53ba2548a9467b3264cf01ad Amends be2745e4788cecb0d3122081e3328e4b66923609 Pick-to: 6.2 6.3 Change-Id: I087f50b193dd845e4a5ec906e8851d63122faf80 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-02-22 16:57:00 +01:00
set_target_properties(${target} PROPERTIES _qt_module_skip_depends_include TRUE)
set_property(TARGET "${target}" APPEND PROPERTY
EXPORT_PROPERTIES _qt_module_skip_depends_include)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
if(is_framework)
set_target_properties(${target} PROPERTIES
Make framework names consistent with the module names For Apple's frameworks it's possible to include header files using the following assumption: If the framework name is "MyFramework" then '#include <MyFramework/frameworkheader.h>' will work without specifying the include path explicitly. This is broken for internal modules since they use the framework name with the 'Private' suffix. This uses the module name instead of the target name as a framework name. Amends edbe0eb335ca4c0fde23f57eae5acdf80937c9e3 Task-number: QTBUG-87775 Change-Id: I0592a28d0768724b6e10ca81aa7cefb0a3699a5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-01 11:25:41 +02:00
OUTPUT_NAME ${fw_name}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
)
else()
set_target_properties(${target} PROPERTIES
Use module interface name as OUTPUT_NAME For internal modules we should keep the name of the file in file system consistent with previous Qt versions. Pick-to: 6.2 Fixes: QTBUG-95077 Change-Id: I02e4fced0fc3172e60f07bc7d1515e23744db567 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-09 12:32:11 +02:00
OUTPUT_NAME "${INSTALL_CMAKE_NAMESPACE}${module_interface_name}${QT_LIBINFIX}"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
)
endif()
CMake: set correct COMPILE_PDB_NAME for static libraries Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-04-30 23:38:02 +08:00
qt_set_common_target_properties(${target})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
if (WIN32 AND BUILD_SHARED_LIBS)
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 13:20:55 +02:00
_qt_internal_generate_win32_rc_file(${target})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
endif()
# Module headers:
CMake: Fix missing dependencies in *Depends headers In qt_internal_create_module_depends_file we're checking the target property INTERFACE_MODULE_HAS_HEADERS. However, this property is not exported, and in per-repo builds we do not have access to this. As we cannot export INTERFACE_* properties, we export another one, called _qt_module_has_headers. This amends commit 598e873c84e6544aa67495b9b9fb1ff22f98a293. Fixes: QTBUG-88503 Change-Id: I04b3e24add6e95b577a049c80683b7361ff72f59 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-17 22:01:09 +01:00
set_property(TARGET "${target}" APPEND PROPERTY EXPORT_PROPERTIES _qt_module_has_headers)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
if(${arg_NO_MODULE_HEADERS} OR ${arg_NO_SYNC_QT})
CMake: Fix missing dependencies in *Depends headers In qt_internal_create_module_depends_file we're checking the target property INTERFACE_MODULE_HAS_HEADERS. However, this property is not exported, and in per-repo builds we do not have access to this. As we cannot export INTERFACE_* properties, we export another one, called _qt_module_has_headers. This amends commit 598e873c84e6544aa67495b9b9fb1ff22f98a293. Fixes: QTBUG-88503 Change-Id: I04b3e24add6e95b577a049c80683b7361ff72f59 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-17 22:01:09 +01:00
set_target_properties("${target}" PROPERTIES
_qt_module_has_headers OFF)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
else()
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
set_property(TARGET ${target} APPEND PROPERTY EXPORT_PROPERTIES _qt_module_include_name)
set_target_properties("${target}" PROPERTIES
Replace the syncqt.pl script with syncqt tool 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 <alexandru.croitor@qt.io>
2022-08-15 18:29:41 +02:00
_qt_module_include_name "${module_include_name}"
_qt_module_has_headers ON
)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
Remove perl related functionality from CMake files Avoid using perl in CMake scripts. Remove the syncqt.pl specific code. Task-number: QTBUG-87480 Change-Id: I7fcd5cc83d173ec463c275b5b50b84f25044a118 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-05 16:32:31 +02:00
set(sync_source_directory "${CMAKE_CURRENT_SOURCE_DIR}")
if(arg_HEADER_SYNC_SOURCE_DIRECTORY)
set(sync_source_directory "${arg_HEADER_SYNC_SOURCE_DIRECTORY}")
Replace the syncqt.pl script with syncqt tool 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 <alexandru.croitor@qt.io>
2022-08-15 18:29:41 +02:00
endif()
Remove perl related functionality from CMake files Avoid using perl in CMake scripts. Remove the syncqt.pl specific code. Task-number: QTBUG-87480 Change-Id: I7fcd5cc83d173ec463c275b5b50b84f25044a118 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-05 16:32:31 +02:00
set_target_properties(${target} PROPERTIES
_qt_sync_source_directory "${sync_source_directory}")
Do not generate cpp exports for pure STATIC modules Static libraries don't need to export their symbols, and corner cases when sources are also used in shared libraries, should be handled manually. Task-number: QTBUG-90492 Change-Id: I5cb0a3f7e280b042b678bdbe4475f2bbf9f6b9ba Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-16 19:15:05 +02:00
# We should not generate export headers if module is defined as pure STATIC.
# Static libraries don't need to export their symbols, and corner cases when sources are
# also used in shared libraries, should be handled manually.
Remove GENERATE_CPP_EXPORTS argument The behavior that argument was enabling is the default one now. Pick-to: 6.8 Task-number: QTBUG-90492 Change-Id: I11711d4c794f0b22169abb595b8ffad2eeb1300d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-11-28 14:17:19 +01:00
if(NOT arg_NO_GENERATE_CPP_EXPORTS AND NOT arg_STATIC AND NOT arg_HEADER_MODULE)
Implement generating of private cpp exports Add the generating of private cpp exports for Qt modules. Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module that is the manual switch for private exports generator. Existing modules in qtbase doesn't follow any strict convention of using private cpp export. So there is no clue how to detect if generating of the private exports is required or not for the module. Use autogenerated private cpp exports in QtNetwork module. CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different meaning. The provided name is used as a base name for the private and non-private headers that contains cpp exports. Header files suffixes are constant: .h and _p.h for the non-private and private header files accordingly. Pick-to: 6.2 Task-number: QTBUG-90492 Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-30 17:51:07 +02:00
if(arg_CPP_EXPORT_HEADER_BASE_NAME)
set(cpp_export_header_base_name
"CPP_EXPORT_HEADER_BASE_NAME;${arg_CPP_EXPORT_HEADER_BASE_NAME}"
)
endif()
qt_internal_generate_cpp_global_exports(${target} ${module_define_infix}
"${cpp_export_header_base_name}"
)
endif()
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
set(module_depends_header
"${module_build_interface_include_dir}/${module_include_name}Depends")
Use `_qt_internal_set_source_file_generated` Migrate implementations that set `GENERATED` source property Task-number: QTBUG-125077 Pick-to: 6.9 Change-Id: Ia77ecf8422bf3983f7746c26e5a9994d1f6415f2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-06 19:08:39 +01:00
_qt_internal_set_source_file_generated(SOURCES "${module_depends_header}")
Replace the syncqt.pl script with syncqt tool 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 <alexandru.croitor@qt.io>
2022-08-15 18:29:41 +02:00
set_target_properties(${target} PROPERTIES _qt_module_depends_header
"${module_depends_header}")
Fix the arg_HEADER_MODULE condition Use the variable name but not the unwrapped value. Pick-to: 6.5 6.7 6.8 Change-Id: Ie392a4875fe412b8eb273a457a83cd08cd9f5e15 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-06-12 11:46:55 +02:00
if(NOT arg_HEADER_MODULE)
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
set(module_header "${module_build_interface_include_dir}/${module_include_name}")
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
set_property(TARGET "${target}" PROPERTY MODULE_HEADER
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
"${module_header}")
CMake: Fix generation of precompiled headers in per-repo Qt builds When a Qt module Foo links against a Qt module Bar then we add the ${QT_BUILD_DIR}/include/QtBar/QtBar header to the list of precompiled header files. However, this only works if Foo and Bar are in the same build system, e.g. in the same repository or in a top-level build. For example, the QtCore header was never precompiled when in a per-repo build of QtSvg. Now, we determine whether Foo and Bar are in the same build system. If they are, we proceed as before. Otherwise, we calculate the QtBar header's location from the following data: - the location of Qt6BarConfig.cmake - the relative path to Bar's include directory The Q*Application tests' project files had to be adjusted to use NO_PCH_SOURCES now, because they use the source file apphelper_plugin.cpp that specifically checks that pre-compiled headers are not used for its compilation. Fixes: QTBUG-134424 Change-Id: I04ede51e4d853e8b813f660f29be8cfeb684c0b2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-03-10 11:58:18 +01:00
if(QT_FEATURE_no_prefix)
file(RELATIVE_PATH relative_include_dir
"/${QT_CONFIG_INSTALL_DIR}/${module_include_name}"
"/${module_build_interface_include_dir}"
)
else()
file(RELATIVE_PATH relative_include_dir
"/${QT_CONFIG_INSTALL_DIR}/${module_include_name}"
"/${module_install_interface_include_dir}"
)
endif()
set_property(TARGET "${target}" PROPERTY
_qt_module_relative_include_dir "${relative_include_dir}"
)
set_property(TARGET ${target} APPEND PROPERTY
EXPORT_PROPERTIES _qt_module_relative_include_dir
)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
set(qpa_filter_regex "")
if(arg_QPA_HEADER_FILTERS)
set(qpa_filter_regex "${arg_QPA_HEADER_FILTERS}")
endif()
set_target_properties(${target}
PROPERTIES _qt_module_qpa_headers_filter_regex "${qpa_filter_regex}")
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
set(rhi_filter_regex "")
if(arg_RHI_HEADER_FILTERS)
set(rhi_filter_regex "${arg_RHI_HEADER_FILTERS}")
endif()
set_target_properties(${target}
PROPERTIES _qt_module_rhi_headers_filter_regex "${rhi_filter_regex}")
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
set(ssg_filter_regex "")
if(arg_SSG_HEADER_FILTERS)
set(ssg_filter_regex "${arg_SSG_HEADER_FILTERS}")
endif()
set_target_properties(${target}
PROPERTIES _qt_module_ssg_headers_filter_regex "${ssg_filter_regex}")
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
set(private_filter_regex ".+_p(ch)?\\.h")
if(arg_PRIVATE_HEADER_FILTERS)
set(private_filter_regex "${private_filter_regex}|${arg_PRIVATE_HEADER_FILTERS}")
endif()
set_target_properties(${target}
PROPERTIES _qt_module_private_headers_filter_regex "${private_filter_regex}")
# If EXTERNAL_HEADERS_DIR is set we install the specified directory and keep the structure
# without taking into the account the CMake source tree and syncqt outputs.
if(arg_EXTERNAL_HEADERS_DIR)
Fix external header support in qtsync We should sync external headers for 3rdpary projects like freetype and harfbuzz-ng and keep the directory structure. Fixes: QTBUG-113416 Pick-to: 6.6 6.5 Change-Id: Ie66edb9a21cff37ca6c8c68b6d225de6d8bbad81 Reviewed-by: Michal Klocek <michal.klocek@qt.io>
2023-06-08 16:20:47 +02:00
set_property(TARGET ${target}
PROPERTY _qt_external_headers_dir "${arg_EXTERNAL_HEADERS_DIR}")
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
qt_install(DIRECTORY "${arg_EXTERNAL_HEADERS_DIR}/"
DESTINATION "${module_install_interface_include_dir}"
)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
endif()
Add NO_HEADERSCLEAN_CHECK flag to qt_internal_add_module Some modules may have header files that do not pass headersclean check under some conditions. It's nice to have an option in the qt_internal_add_module function to disable the check for the modules of this kind. At the moment this flag is useful for the ActiveQt module, since it syncs and installs header files that don't belong to it. Amends b89d63515bb352cecfd87e709320a2db5b6a1906 Task-number: QTBUG-103196 Change-Id: I21a82d50d50bdac225ed483ab0cc50339c2a4873 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-24 18:35:12 +02:00
if(arg_NO_HEADERSCLEAN_CHECK OR arg_NO_MODULE_HEADERS OR arg_NO_SYNC_QT
Remove the headersclean feature 'headersclean' shoudn't be a feature. The respective flag should behave like command-line switch that affects the only repo that it was passed for. This also avoids propagating of the headersclean feature between the different repos when qtbase was built with the headerclean enabled. Fixes: QTBUG-121722 Change-Id: I304cbc980b06030513c015a2016678a6a0965fed Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-04-09 14:36:38 +02:00
OR NOT INPUT_headersclean)
Add NO_HEADERSCLEAN_CHECK flag to qt_internal_add_module Some modules may have header files that do not pass headersclean check under some conditions. It's nice to have an option in the qt_internal_add_module function to disable the check for the modules of this kind. At the moment this flag is useful for the ActiveQt module, since it syncs and installs header files that don't belong to it. Amends b89d63515bb352cecfd87e709320a2db5b6a1906 Task-number: QTBUG-103196 Change-Id: I21a82d50d50bdac225ed483ab0cc50339c2a4873 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-24 18:35:12 +02:00
set_target_properties("${target}" PROPERTIES _qt_no_headersclean_check ON)
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
if(NOT arg_HEADER_MODULE)
# Plugin types associated to a module
if(NOT "x${arg_PLUGIN_TYPES}" STREQUAL "x")
cmake: Teach qt_internal_extend_target about PLUGIN_TYPES Change-Id: I2e8a3faa6ada66a644dceeb98f9ba8e994db4192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-25 15:28:31 +02:00
qt_internal_add_plugin_types("${target}" "${arg_PLUGIN_TYPES}")
Add the QT_PLUGIN_TARGETS transitive compile property Use the freshly introduced TRANSITIVE_COMPILE_PROPERTIES functionality to handle plugin targets across Qt modules. This will allow accessing all Qt plugins that are required for targets at once, without the need of iterating over the Qt targets at configure time. This mechanism duplicates the already existing plugin collecting routines, since we still need to support the older CMake version. This commit only introduces the helper functions and plugins collecting, but doesn't use the QT_PLUGIN_TARGETS anywhere. We don't use the direct export of properties by CMake but still rely on plugin collecting mechanism we use before to cover the situation when Qt is built using CMake versions < 3.30 and then is used to build user applications with CMake versions >= 3.30. Task-number: QTBUG-129302 Change-Id: Id3b516b92e8e16552d46b2c702b76c571366f2b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-10-30 18:18:05 +01:00
# Ensure that QT_PLUGIN_TARGETS is a known transitive compile property. Works with CMake
# versions >= 3.30.
_qt_internal_add_transitive_property(${target} COMPILE QT_PLUGIN_TARGETS)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
endif()
if(NOT arg_HEADER_MODULE)
qt_autogen_tools_initial_setup(${target})
endif()
set(private_includes
"$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>"
"$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}>"
${arg_INCLUDE_DIRECTORIES}
)
set(public_includes "")
set(public_headers_list "public_includes")
if(is_framework)
set(public_headers_list "private_includes")
endif()
# Make sure the BUILD_INTERFACE include paths come before the framework headers, so that the
# the compiler prefers the build dir includes.
#
# Make sure to add non-framework "build_dir/include" as an include path for moc to find the
# currently built module headers. qmake does this too.
# Framework-style include paths are found by moc when cmQtAutoMocUic.cxx detects frameworks by
# looking at an include path and detecting a "QtFoo.framework/Headers" path.
# Make sure to create such paths for both the the BUILD_INTERFACE and the INSTALL_INTERFACE.
#
# Only add syncqt headers if they exist.
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
# This handles cases like QmlDevToolsPrivate which do not have their own headers, but borrow
# them from another module.
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
if(NOT arg_NO_SYNC_QT AND NOT arg_NO_MODULE_HEADERS)
# Don't include private headers unless they exist, aka syncqt created them.
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
qt_internal_append_include_directories_with_headers_check(${target}
private_includes PRIVATE
"$<BUILD_INTERFACE:${module_build_interface_versioned_include_dir}>"
"$<BUILD_INTERFACE:${module_build_interface_versioned_inner_include_dir}>"
)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
list(APPEND public_includes
# For the syncqt headers
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
"$<BUILD_INTERFACE:${repo_build_interface_include_dir}>"
"$<BUILD_INTERFACE:${module_build_interface_include_dir}>")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
if(is_framework)
Move the framework related information to the common function Since the information about framework is performed in multiple places it's quite hard to control its consistency. This moves the obtaining of framework related information to the common function and adjusts the use of the information across the repo. Change-Id: I1f488d41dcea75a1e8c361926792a6b7c45e5a3f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-26 20:48:58 +02:00
set(fw_install_dir "${INSTALL_LIBDIR}/${fw_dir}")
set(fw_install_header_dir "${INSTALL_LIBDIR}/${fw_header_dir}")
set(fw_output_header_dir "${QT_BUILD_DIR}/${fw_install_header_dir}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
list(APPEND public_includes
# Add the framework Headers subdir, so that non-framework-style includes work. The
# BUILD_INTERFACE Headers symlink was previously claimed not to exist at the relevant
# time, and a fully specified Header path was used instead. This doesn't seem to be a
# problem anymore.
Move the framework related information to the common function Since the information about framework is performed in multiple places it's quite hard to control its consistency. This moves the obtaining of framework related information to the common function and adjusts the use of the information across the repo. Change-Id: I1f488d41dcea75a1e8c361926792a6b7c45e5a3f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-26 20:48:58 +02:00
"$<BUILD_INTERFACE:${fw_output_header_dir}>"
"$<INSTALL_INTERFACE:${fw_install_header_dir}>"
CMake: Mitigate moc not finding correct headers in framework builds When CMake generates compilation rules, it extracts the values from INTERFACE_INCLUDE_DIRECTORIES and checks if any of the values are framework paths. If they are, instead of adding an -I ./lib/My.framework to the compilation rules, it adds -iframework ./lib or -F ./lib. The same transformation does not happen when AUTOMOC passes include paths to moc, nor during a headersclean check. The values there are passed verbatim, with an -I prepended. This causes issues when the include file name is the same as the framework name. E.g. #include <QtQml> + -I ./lib/QtQml.framework because moc then ends up silently including the shared library ./lib/QtQml.framework/QtQml instead of the header ./lib/QtQml.framework/Headers/QtQml This can lead to a variety of silent issues during moc generation, because all the definitions of QtQml will be missing. Unfortunately, there does not seem to be a clean way to fix this in the build system due to CMake semantics. See https://gitlab.kitware.com/cmake/cmake/-/issues/23337 for details. We can mitigate the issue by ensuring that -I ./lib/QtQml.framework/Headers comes before -I ./lib/QtQml.framework by manipulating the order of values in INTERFACE_INCLUDE_DIRECTORIES. We might want to consider implementing an additional mitigation in AUTOMOC, so that it filters out include paths like -I ./lib/QtQml.framework, thus ensuring that a newer CMake version will not exhibit the same issue when used with an older Qt. We could consider doing the same in moc. The advantage of doing it in moc is that that moc will consider fewer invalid include paths when searching for headers. Amends 4b2de41b13eb71c0ce841ef357768a3913b49810 Amends d7efb2a419a88c8f512b98194c8f7bc81dbe942b Pick-to: 6.2 6.3 Fixes: QTBUG-89545 Fixes: QTBUG-101718 Fixes: QTBUG-101775 Change-Id: Ib2c25b5744bd2b5c9c83813bb04ad88c0179f6ec Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-03-17 13:23:48 +01:00
# Add the lib/Foo.framework dir as an include path to let CMake generate
# the -F compiler flag for framework-style includes to work.
# Make sure it is added AFTER the lib/Foo.framework/Headers include path,
# to mitigate issues like QTBUG-101718 and QTBUG-101775 where an include like
# #include <QtCore> might cause moc to include the QtCore framework shared library
# instead of the actual header.
"$<INSTALL_INTERFACE:${fw_install_dir}>"
Move the framework related information to the common function Since the information about framework is performed in multiple places it's quite hard to control its consistency. This moves the obtaining of framework related information to the common function and adjusts the use of the information across the repo. Change-Id: I1f488d41dcea75a1e8c361926792a6b7c45e5a3f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-26 20:48:58 +02:00
)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
if(NOT arg_NO_MODULE_HEADERS AND NOT arg_NO_SYNC_QT)
# For the syncqt headers
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
list(APPEND ${public_headers_list}
"$<INSTALL_INTERFACE:${module_install_interface_include_dir}>")
CMake: Add $import_prefix/include as an include path for each Qt module To support finding Qt headers of modules installed into a different prefix than the main one, add the $import_prefix/include path as a public include path for each built Qt module. With this, includes like #include <QtNetworkAuth/QOAuth2AuthorizationCodeFlow> will work. The macOS framework case is handled automagically by CMake, which ends up passing '-iframework $import_prefix/lib'. Change-Id: I02ce9cacf157aab9721c1d6073a377607c5b89c7 Fixes: QTBUG-86881 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-25 19:48:30 +02:00
# To support finding Qt module includes that are not installed into the main Qt prefix.
# Use case: A Qt module built by Conan installed into a prefix other than the main prefix.
# This does duplicate the include path set on Qt6::Platform target, but CMake is smart
# enough to deduplicate the include paths on the command line.
# Frameworks are automatically handled by CMake in cmLocalGenerator::GetIncludeFlags()
# by additionally passing the 'QtFoo.framework/..' dir with an -iframework argument.
list(APPEND ${public_headers_list} "$<INSTALL_INTERFACE:${INSTALL_INCLUDEDIR}>")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
list(APPEND ${public_headers_list} ${arg_PUBLIC_INCLUDE_DIRECTORIES})
set(defines_for_extend_target "")
if(NOT arg_HEADER_MODULE)
list(APPEND defines_for_extend_target
QT_NO_CAST_TO_ASCII QT_ASCII_CAST_WARNINGS
QT_MOC_COMPAT #we don't need warnings from calling moc code in our generated code
QT_DEPRECATED_WARNINGS
QT_BUILDING_QT
CMake: Cleanup module and plugin define situation The QT.<module>.DEFINES assignment in pri files needs to take into account the module name when computing the define name. This is the MODULE value that qmake specifies. In CMake that would be the value of CONFIG_MODULE_NAME. Previously the value of the define was computed in qt_internal_module_info() without taking into account the module name. While qt_internal_module_info() ended being used also for plugins and other target types, the defines computed by it were meant to be used only for Qt modules. Thus remove the <result>_define assignment from qt_internal_module_info and move its computation directly into qt_internal_add_module, taking into account the value of CONFIG_MODULE_NAME. The only other use of module_define was in qt_internal_add_plugin but that was merely a long overdue copy-paste error, qmake doesn't propagate QT_FOO_LIB defines for plugins. As result, a define special case in testlib is not needed anymore, because the define is now computed properly. Finally, QT_FOO_LIB should not be used while building the Qt module itself, so instead of using PUBLIC_DEFINES option of qt_internal_extend_target, use target_compile_definitions(INTERFACE) directly. Change-Id: I4d44f7461bac2f0c09aec3e995d02dfe36e00883 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-30 13:29:55 +01:00
QT_BUILD_${module_define_infix}_LIB ### FIXME: use QT_BUILD_ADDON for Add-ons or remove if we don't have add-ons anymore
Revert "CMake: make compile options consistent for Qt created libraries" This reverts commit 389507a047e0ec0721535052df6ddf957fbb95b3. Reason for revert: The original patch unintentionally changes the deprecation warning behavior for user projects. Merging the current change will resurface the original static qt build bug until a new fix is developed. Pick-to: 6.6 Change-Id: I29b41b43fdd76b19bc46439470e04443dc2b8ddb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Yuhang Zhao <yuhangzhao@deepin.org>
2023-06-07 07:41:52 +00:00
${deprecation_define}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
)
Do not expose Qt internals by the HEADER_MODULEs HEADER_MODULEs use the INTERFACE visibility to link libraries. This causes a transitional propagating of the Qt-internal compile definitions and options to the user targets. This commit avoids an implicit adding of the Qt::PlatformModuleInternal library to the HEADER_MODULEs and stops propagation of the Qt-internal compile definitions and options. If module wants the transitional propagation of some properties, this needs to be done explicitly. Amends 8b7894cb637d21d8fa9bd129849cd23462632d28 Pick-to: 6.1 Fixes: QTBUG-89951 Change-Id: Ia9cecc38bac98eb5bc6e47d288308b49813ab5ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-20 14:08:20 +02:00
list(APPEND arg_LIBRARIES Qt::PlatformModuleInternal)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
build system: support module local definitions This introduces a new helper function, qt_internal_add_repo_local_defines and makes use of it in qt_internal_add_{module,test,executable,benchmark,plugin}. That function checks whether QT_EXTRA_INTERNAL_TARGET_DEFINES is set. If it is, the defines listed in there will be aded to all targets passed to the functions mentioned above. The intended usage is that QT_EXTRA_INTERNAL_TARGET_DEFINES gets set in the repository local .cmake.conf. This allows e.g. opting in to source incompatible changes in leaf modules (as long as those are guarded by some define). Pick-to: 6.2 6.3 Fixes: QTBUG-101640 Change-Id: I06c3693ee69f46e95a48de724621f0c97e7cc3a8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-11 12:41:36 +01:00
qt_internal_add_repo_local_defines("${target}")
Add some utilities for UNITY_BUILD - The following commands accepts NO_UNITY_BUILD, and NO_UNITY_BUILD_SOURCES arguments to opt out of the unity build, and to exclude some source files from unity build, respectively. - qt_internal_add_executable - qt_internal_add_module - qt_internal_add_plugin - qt_internal_add_tool - qt_internal_extend_target - qt_internal_add_common_qt_library_helper - qt_internal_add_cmake_library - qt_internal_add_simd_part - Unity build is disabled by default in these: - qt_internal_add_test - qt_internal_add_test_helper - qt_internal_add_benchmark - qt_internal_add_3rdparty_library - qt_update_ignore_pch_source also excludes the files from unity_build Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I5d0e7df633738310a015142a6c73fbb78b6c3467 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-31 14:05:16 +01:00
if(arg_NO_UNITY_BUILD)
Fix an issue with passing NO_UNITY_BUILD_SOURCES Amend 31518f1a4e3c4a7c77ae2e008e903a849ba75dd6 Amend 360293623094a31586981206e59c92aa6235163d Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ibb2fd881c02b6496f06b8b623fa6009358755a26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-15 10:46:22 +01:00
set(arg_NO_UNITY_BUILD "NO_UNITY_BUILD")
Add some utilities for UNITY_BUILD - The following commands accepts NO_UNITY_BUILD, and NO_UNITY_BUILD_SOURCES arguments to opt out of the unity build, and to exclude some source files from unity build, respectively. - qt_internal_add_executable - qt_internal_add_module - qt_internal_add_plugin - qt_internal_add_tool - qt_internal_extend_target - qt_internal_add_common_qt_library_helper - qt_internal_add_cmake_library - qt_internal_add_simd_part - Unity build is disabled by default in these: - qt_internal_add_test - qt_internal_add_test_helper - qt_internal_add_benchmark - qt_internal_add_3rdparty_library - qt_update_ignore_pch_source also excludes the files from unity_build Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I5d0e7df633738310a015142a6c73fbb78b6c3467 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-31 14:05:16 +01:00
else()
set(arg_NO_UNITY_BUILD "")
endif()
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
if(NOT arg_EXTERNAL_HEADERS)
set(arg_EXTERNAL_HEADERS "")
endif()
Improvement to NO_UNITY_BUILD_SOURCES, and fix related bugs The source of the problem was in `qt_set_target_info_properties` which was not able to process the NO_UNITY_BUILD_SOURCES, and therefore leaking it into the `TARGET_COPYRIGHT`, ie., the last argument. So, I decided to pass Unity Build arguments before them, and closer to SOURCES, which is nicer to read, and avoid similar situation. And I reverted the work around in the amend commit, and passing the arguments normally. This happens because we pass an unfiltered ${ARGN} from qt_internal_add_executable to qt_set_target_info_properties and that the current change is merely a workaround that ensures they get circumstantially filtered out, because the NO_UNITY_BUILD_SOURCES option appears before any of the first TARGET_ props. Amend cd12c1f33281452d478bb94744d76bead5c7363a Task-number: QTBUG-99238 Task-number: QTBUG-109394 Pick-to: 6.5 Change-Id: Idb37937cf53e708425402c90f55bda8816e27f29 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-29 11:38:30 +02:00
CMake: Fix CMP0174 warnings CMake 3.31 introduced the policy CMP0174 that triggers a warning if a single-value argument is passed to a function without a value. We did this doing this when forwarding arguments in code that doesn't use _qt_internal_forward_function_args yet, e.g. in qt_internal_add_app: qt_internal_add_executable(... TARGET_PRODUCT ${arg_TARGET_PRODUCT} ...) Forward the warning-triggering arguments with _qt_internal_forward_function_args now, because that only forwards used arguments. In the future, we can offload more forwarding work to the _qt_internal_forward_function_args command and simplify the forwarding code in qt_internal_add_app and qt_internal_add_tool. This patch only fixes the worst offenders for now. Pick-to: 6.8 Change-Id: Ie786691e4b236decf4c62f4dd0751ed76b721177 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-11-08 14:26:32 +01:00
_qt_internal_forward_function_args(
FORWARD_PREFIX arg
FORWARD_OUT_VAR extend_target_args
FORWARD_SINGLE
PRECOMPILED_HEADER
)
CMake: Rename internal functions to contain qt_internal Offer compatibility wrapper functions until we update all of the Qt repos to use the new names. Task-number: QTBUG-86815 Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2020-09-22 10:02:27 +02:00
qt_internal_extend_target("${target}"
Improvement to NO_UNITY_BUILD_SOURCES, and fix related bugs The source of the problem was in `qt_set_target_info_properties` which was not able to process the NO_UNITY_BUILD_SOURCES, and therefore leaking it into the `TARGET_COPYRIGHT`, ie., the last argument. So, I decided to pass Unity Build arguments before them, and closer to SOURCES, which is nicer to read, and avoid similar situation. And I reverted the work around in the amend commit, and passing the arguments normally. This happens because we pass an unfiltered ${ARGN} from qt_internal_add_executable to qt_set_target_info_properties and that the current change is merely a workaround that ensures they get circumstantially filtered out, because the NO_UNITY_BUILD_SOURCES option appears before any of the first TARGET_ props. Amend cd12c1f33281452d478bb94744d76bead5c7363a Task-number: QTBUG-99238 Task-number: QTBUG-109394 Pick-to: 6.5 Change-Id: Idb37937cf53e708425402c90f55bda8816e27f29 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-29 11:38:30 +02:00
${arg_NO_UNITY_BUILD}
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
SOURCES
${arg_SOURCES}
${arg_EXTERNAL_HEADERS}
Improvement to NO_UNITY_BUILD_SOURCES, and fix related bugs The source of the problem was in `qt_set_target_info_properties` which was not able to process the NO_UNITY_BUILD_SOURCES, and therefore leaking it into the `TARGET_COPYRIGHT`, ie., the last argument. So, I decided to pass Unity Build arguments before them, and closer to SOURCES, which is nicer to read, and avoid similar situation. And I reverted the work around in the amend commit, and passing the arguments normally. This happens because we pass an unfiltered ${ARGN} from qt_internal_add_executable to qt_set_target_info_properties and that the current change is merely a workaround that ensures they get circumstantially filtered out, because the NO_UNITY_BUILD_SOURCES option appears before any of the first TARGET_ props. Amend cd12c1f33281452d478bb94744d76bead5c7363a Task-number: QTBUG-99238 Task-number: QTBUG-109394 Pick-to: 6.5 Change-Id: Idb37937cf53e708425402c90f55bda8816e27f29 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-29 11:38:30 +02:00
NO_UNITY_BUILD_SOURCES
${arg_NO_UNITY_BUILD_SOURCES}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
INCLUDE_DIRECTORIES
${private_includes}
CMake: add SYSTEM_INCLUDE_DIRECTORIES to qt_internal_extend_target This allows one to add an extra set of directories to the build, but let the compiler know that they are system paths (that is, the compiler should refrain from emitting warnings in code found there). This extends INCLUDE_DIRECTORIES and is by necessity a private include set. Will be used by qtquick3dphysics, due to its PhysX dependency. Change-Id: I76216ced393445a4ae2dfffd1729c556db0cce3d Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-11-21 17:55:13 -08:00
SYSTEM_INCLUDE_DIRECTORIES
${arg_SYSTEM_INCLUDE_DIRECTORIES}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
PUBLIC_INCLUDE_DIRECTORIES
${public_includes}
PUBLIC_DEFINES
${arg_PUBLIC_DEFINES}
DEFINES
${arg_DEFINES}
${defines_for_extend_target}
PUBLIC_LIBRARIES ${arg_PUBLIC_LIBRARIES}
Do not expose Qt internals by the HEADER_MODULEs HEADER_MODULEs use the INTERFACE visibility to link libraries. This causes a transitional propagating of the Qt-internal compile definitions and options to the user targets. This commit avoids an implicit adding of the Qt::PlatformModuleInternal library to the HEADER_MODULEs and stops propagation of the Qt-internal compile definitions and options. If module wants the transitional propagation of some properties, this needs to be done explicitly. Amends 8b7894cb637d21d8fa9bd129849cd23462632d28 Pick-to: 6.1 Fixes: QTBUG-89951 Change-Id: Ia9cecc38bac98eb5bc6e47d288308b49813ab5ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-20 14:08:20 +02:00
LIBRARIES ${arg_LIBRARIES}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
PRIVATE_MODULE_INTERFACE ${arg_PRIVATE_MODULE_INTERFACE}
FEATURE_DEPENDENCIES ${arg_FEATURE_DEPENDENCIES}
DBUS_ADAPTOR_SOURCES ${arg_DBUS_ADAPTOR_SOURCES}
DBUS_ADAPTOR_FLAGS ${arg_DBUS_ADAPTOR_FLAGS}
DBUS_INTERFACE_SOURCES ${arg_DBUS_INTERFACE_SOURCES}
DBUS_INTERFACE_FLAGS ${arg_DBUS_INTERFACE_FLAGS}
COMPILE_OPTIONS ${arg_COMPILE_OPTIONS}
PUBLIC_COMPILE_OPTIONS ${arg_PUBLIC_COMPILE_OPTIONS}
LINK_OPTIONS ${arg_LINK_OPTIONS}
PUBLIC_LINK_OPTIONS ${arg_PUBLIC_LINK_OPTIONS}
MOC_OPTIONS ${arg_MOC_OPTIONS}
ENABLE_AUTOGEN_TOOLS ${arg_ENABLE_AUTOGEN_TOOLS}
DISABLE_AUTOGEN_TOOLS ${arg_DISABLE_AUTOGEN_TOOLS}
NO_PCH_SOURCES ${arg_NO_PCH_SOURCES}
CMake: Fix CMP0174 warnings CMake 3.31 introduced the policy CMP0174 that triggers a warning if a single-value argument is passed to a function without a value. We did this doing this when forwarding arguments in code that doesn't use _qt_internal_forward_function_args yet, e.g. in qt_internal_add_app: qt_internal_add_executable(... TARGET_PRODUCT ${arg_TARGET_PRODUCT} ...) Forward the warning-triggering arguments with _qt_internal_forward_function_args now, because that only forwards used arguments. In the future, we can offload more forwarding work to the _qt_internal_forward_function_args command and simplify the forwarding code in qt_internal_add_app and qt_internal_add_tool. This patch only fixes the worst offenders for now. Pick-to: 6.8 Change-Id: Ie786691e4b236decf4c62f4dd0751ed76b721177 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-11-08 14:26:32 +01:00
${extend_target_args}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
)
CMake: Cleanup module and plugin define situation The QT.<module>.DEFINES assignment in pri files needs to take into account the module name when computing the define name. This is the MODULE value that qmake specifies. In CMake that would be the value of CONFIG_MODULE_NAME. Previously the value of the define was computed in qt_internal_module_info() without taking into account the module name. While qt_internal_module_info() ended being used also for plugins and other target types, the defines computed by it were meant to be used only for Qt modules. Thus remove the <result>_define assignment from qt_internal_module_info and move its computation directly into qt_internal_add_module, taking into account the value of CONFIG_MODULE_NAME. The only other use of module_define was in qt_internal_add_plugin but that was merely a long overdue copy-paste error, qmake doesn't propagate QT_FOO_LIB defines for plugins. As result, a define special case in testlib is not needed anymore, because the define is now computed properly. Finally, QT_FOO_LIB should not be used while building the Qt module itself, so instead of using PUBLIC_DEFINES option of qt_internal_extend_target, use target_compile_definitions(INTERFACE) directly. Change-Id: I4d44f7461bac2f0c09aec3e995d02dfe36e00883 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-30 13:29:55 +01:00
# The public module define is not meant to be used when building the module itself,
# it's only meant to be used for consumers of the module,
# thus we can't use qt_internal_extend_target()'s PUBLIC_DEFINES option.
target_compile_definitions(${target} INTERFACE QT_${module_define_infix}_LIB)
Fix the condition that enables/defaults exceptions Not sure why it worked at implementation time. But now it definitely doesn't. We may check the EXCEPTIONS flag value, since it's the equivalent of its presence/non-presence in the argument list. Amends f98fd705290ac7bd9434552a07e38b775e6a6dbf Task-number: QTBUG-118901 Pick-to: 6.9 Change-Id: I9769b4921a2f72d31aea2b0bffd2511edd89f88f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-17 10:07:25 +01:00
if(NOT arg_EXCEPTIONS)
Add the 'exceptions' feature The feature allows enabling/disabling exceptions for the Qt builds. The feature is disabled by default. This commit reworks the way the exception flags are set for Qt targets. Instead of setting them per-target, flags now are set for the QtPlatformCommonInternal target, which transitively propagates the flag to other Qt targets. To disable/enable exception flags the newly introduced property _qt_internal_use_exceptions can be used. The flags enabling/disabling now can happen any time, but not only at target creation time. The property has 3 states: TRUE, FALSE, DEFAULT(or empty). If the property is not set or is set to DEFAULT, the exceptions feature value is used to set the required exceptions flags. Otherwise the flags are set according to the property value. The logic of EXCEPTION argument of the various qt_internal_add_ functions was also updated. If the argument is not provided, the _qt_internal_use_exceptions property value is set to DEFAULT, which gives the control on the exception flags to the feature. If the argument is provided, the exceptions are enabled by setting the _qt_internal_use_exceptions property to TRUE. Task-number: QTBUG-118901 Change-Id: I83e3bf52d48a3d16977cce849c9b0765c34f1f21 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-08-01 16:25:09 +02:00
qt_internal_set_exceptions_flags("${target}" "DEFAULT")
else()
qt_internal_set_exceptions_flags("${target}" "${arg_EXCEPTIONS}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
set(configureFile "${CMAKE_CURRENT_SOURCE_DIR}/configure.cmake")
if(arg_CONFIGURE_FILE_PATH)
set(configureFile "${arg_CONFIGURE_FILE_PATH}")
endif()
if(EXISTS "${configureFile}" AND NOT arg_NO_CONFIG_HEADER_FILE)
qt_feature_module_begin(
LIBRARY "${target}"
Fix the naming of the config header files for private modules Perform a file name of the config header before adding a '_private' suffix. TODO: It makes sense to revisit the use of the CONFIG_MODULE_NAME variable since the variable is used for different purposes and mutate with use. Amends 8aee7c6b29be5a0ee7d5e7cfcb5f2db762b2e28b Pick-to: 6.2 Fixes: QTBUG-94568 Change-Id: Id5aaf8d423ec8b94afffe4641b54dab94b5453fb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-18 20:13:32 +02:00
PUBLIC_FILE "${module_config_header}"
PRIVATE_FILE "${module_config_private_header}"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
PUBLIC_DEPENDENCIES ${arg_FEATURE_DEPENDENCIES}
PRIVATE_DEPENDENCIES ${arg_FEATURE_DEPENDENCIES}
)
include(${configureFile})
qt_feature_module_end("${target}")
Add <module>-config[-p].h files to the module sources <module>-config[-p].h files need to be added to the CMake source tree Amends 8539e641f6f48a605547f66c47266d19e537f74e Task-number: QTBUG-103196 Change-Id: I8baaa672ad869da8a030d890da8bdea5bd8c7794 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-09-08 12:18:34 +02:00
qt_internal_extend_target("${target}"
SOURCES
"${CMAKE_CURRENT_BINARY_DIR}/${module_config_header}"
"${CMAKE_CURRENT_BINARY_DIR}/${module_config_private_header}"
)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
# Handle creation of cmake files for consumers of find_package().
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}${target}")
qt_path_join(config_build_dir ${QT_CONFIG_BUILD_DIR} ${path_suffix})
qt_path_join(config_install_dir ${QT_CONFIG_INSTALL_DIR} ${path_suffix})
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
if(NOT arg_NO_PRIVATE_MODULE)
set(path_suffix "${INSTALL_CMAKE_NAMESPACE}${target_private}")
qt_path_join(private_config_build_dir ${QT_CONFIG_BUILD_DIR} ${path_suffix})
qt_path_join(private_config_install_dir ${QT_CONFIG_INSTALL_DIR} ${path_suffix})
endif()
unset(path_suffix)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
set(extra_cmake_files)
set(extra_cmake_includes)
if (EXISTS "${CMAKE_CURRENT_LIST_DIR}/${INSTALL_CMAKE_NAMESPACE}${target}Macros.cmake")
list(APPEND extra_cmake_files "${CMAKE_CURRENT_LIST_DIR}/${INSTALL_CMAKE_NAMESPACE}${target}Macros.cmake")
list(APPEND extra_cmake_includes "${INSTALL_CMAKE_NAMESPACE}${target}Macros.cmake")
endif()
Improve the QT_NAMESPACE definition in Qt6CoreExtras The perivous version generated weird condition, and seems changing the QT_NAMESPACE after qtbase configuration is noop, we may replace the generated condition with the conditional generation. Change-Id: Ifa09dba4db00099a07da2cff5505e6fd0b008289 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-06 11:52:11 +01:00
Introduce Qt<Module>TransitiveExtras.cmake for Qt modules This file sets the transitive module properties provided by Qt Module that is built using CMake versions < 3.30. The idea is to not limit user projects capabilities and allow using transitive Qt Module properties if user CMake version allows it. If Qt Modules are built using CMake versions >= 3.30 this code is noop, since values are stored directly in the respective INTERFACE_properties. Change-Id: I5a0bc0aa4f79a04c81dfa0fee1d37cfee5935b0f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-05-21 16:28:02 +02:00
if(CMAKE_VERSION VERSION_LESS 3.30)
# For the CMake versions higher than 3.30 the corresponding INTERFACE_
# properties will be in Qt<Module>Targets.cmake without extra code
# needed.
configure_file(
"${QT_CMAKE_DIR}/QtTransitiveExtras.cmake.in"
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}TransitiveExtras.cmake"
@ONLY
)
list(APPEND extra_cmake_files
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}TransitiveExtras.cmake")
list(APPEND extra_cmake_includes
"${INSTALL_CMAKE_NAMESPACE}${target}TransitiveExtras.cmake")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
if (EXISTS "${CMAKE_CURRENT_LIST_DIR}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigExtras.cmake.in")
CMake: Set some additional info variables in Qt6CoreConfigExtras Add info whether Qt was an infix built, and whether the reduce_exports feature was enabled. These variable were set before in Qt5CoreConfigExtras.cmake. Change-Id: Id077763cfffd5ee6f1a7a28d04cf92dc46390c54 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-07 16:32:46 +02:00
if(target STREQUAL Core)
Improve the QT_NAMESPACE definition in Qt6CoreExtras The perivous version generated weird condition, and seems changing the QT_NAMESPACE after qtbase configuration is noop, we may replace the generated condition with the conditional generation. Change-Id: Ifa09dba4db00099a07da2cff5505e6fd0b008289 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-06 11:52:11 +01:00
if(NOT "${QT_NAMESPACE}" STREQUAL "")
Add sanity check for QT_NAMESPACE validness It looks like we don't even support nested namespace(RCC namespace mangling fails). Assuming that QT_NAMESPACE should be the valid C/C++ indentifier. Change-Id: I5c2073c21964eb96abb3e894d83e1df65f7730b4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-06 12:06:48 +01:00
string(MAKE_C_IDENTIFIER "${QT_NAMESPACE}" qt_namespace_sanity)
if(NOT "${QT_NAMESPACE}" STREQUAL "${qt_namespace_sanity}")
message(FATAL_ERROR "QT_NAMESPACE is not a valid C++ identifier: "
"${QT_NAMESPACE}.")
endif()
Improve the QT_NAMESPACE definition in Qt6CoreExtras The perivous version generated weird condition, and seems changing the QT_NAMESPACE after qtbase configuration is noop, we may replace the generated condition with the conditional generation. Change-Id: Ifa09dba4db00099a07da2cff5505e6fd0b008289 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-06 11:52:11 +01:00
string(JOIN "" qtcore_namespace_definition
"set_property(TARGET \${__qt_core_target} "
"APPEND PROPERTY INTERFACE_COMPILE_DEFINITIONS QT_NAMESPACE=${QT_NAMESPACE})"
)
endif()
CMake: Set some additional info variables in Qt6CoreConfigExtras Add info whether Qt was an infix built, and whether the reduce_exports feature was enabled. These variable were set before in Qt5CoreConfigExtras.cmake. Change-Id: Id077763cfffd5ee6f1a7a28d04cf92dc46390c54 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-07 16:32:46 +02:00
set(extra_cmake_code "")
# Add some variables for compatibility with Qt5 config files.
if(QT_FEATURE_reduce_exports)
string(APPEND qtcore_extra_cmake_code "
set(QT_VISIBILITY_AVAILABLE TRUE)")
endif()
if(QT_LIBINFIX)
string(APPEND qtcore_extra_cmake_code "
set(QT_LIBINFIX \"${QT_LIBINFIX}\")")
endif()
CMake: Add switch for allowing missing Qt6*Tools packages Consider a cross build of Qt with qtbase, qtshadertools and qtdeclarative. If a user projects only links against QtQml without creating an actual QtQuick module, no host tools from qtdeclarative are needed. Normally, find_package(Qt6Qml) pulls in Qt6QmlTools and errors out if it's not found. By setting QT_ALLOW_MISSING_TOOLS_PACKAGES when configuring Qt, one can disable the error and build a user project such as the one outlined above. Pick-to: 6.4 6.5 Fixes: QTBUG-109547 Change-Id: I45e727713912d19e6007a7fbf3d61533f82b71d9 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jaeyoon Jung <jaeyoon.jung@lge.com>
2023-01-06 16:12:34 +01:00
# Store whether find_package(Qt6Foo) should succeed if Qt6FooTools is missing.
if(QT_ALLOW_MISSING_TOOLS_PACKAGES)
string(APPEND qtcore_extra_cmake_code "
set(QT_ALLOW_MISSING_TOOLS_PACKAGES TRUE)")
endif()
CMake: Set some additional info variables in Qt6CoreConfigExtras Add info whether Qt was an infix built, and whether the reduce_exports feature was enabled. These variable were set before in Qt5CoreConfigExtras.cmake. Change-Id: Id077763cfffd5ee6f1a7a28d04cf92dc46390c54 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-07 16:32:46 +02:00
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
configure_file("${CMAKE_CURRENT_LIST_DIR}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigExtras.cmake.in"
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigExtras.cmake"
@ONLY)
list(APPEND extra_cmake_files "${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}ConfigExtras.cmake")
list(APPEND extra_cmake_includes "${INSTALL_CMAKE_NAMESPACE}${target}ConfigExtras.cmake")
endif()
foreach(cmake_file IN LISTS arg_EXTRA_CMAKE_FILES)
Add interface to install `EXTRA_CMAKE_FILES` in other paths If the source file sets `QT_INSTALL_PATH` property, it will install the CMake files in the relative path starting from the config-dir in both the build and install paths. Pick-to: 6.8 6.9 Change-Id: I86197d62bfac96f9c142d8abfe85c9b6f6f1a527 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-02-18 11:52:21 +01:00
get_source_file_property(install_path ${cmake_file} QT_INSTALL_PATH)
if(NOT install_path)
# Sanitize the install_path from `NOTFOUND` to ""
set(install_path "")
endif()
file(COPY ${cmake_file} DESTINATION "${config_build_dir}/${install_path}")
qt_install(FILES
${cmake_file}
DESTINATION "${config_install_dir}/${install_path}"
COMPONENT Devel
)
CMake: Reconfigure whenever module EXTRA_FILES are touched Otherwise the touched files will not be re-copied and re-installed until an explicit rerun of cmake. Pick-to: 6.7 Change-Id: I5abb752b45d8b33885a59363fe987225a89e713a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-20 11:51:50 +01:00
# Make sure touched extra cmake files cause a reconfigure, so they get re-copied.
Introduce _qt_internal_append_cmake_configure_depends The function append the unique entries to the CMAKE_CONFIGURE_DEPENDS property. This suppress the ninja recompat issue, which complains about the duplicated entries in that come from the CMAKE_CONFIGURE_DEPENDS property. It's likely the CMake issue, but we may work around it. Pick-to: 6.8 6.9 6.10 Change-Id: I2f10834b0dca3d2aa08fe13fba69849e97fa77d0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-11 13:48:28 +01:00
_qt_internal_append_cmake_configure_depends("${cmake_file}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endforeach()
list(APPEND extra_cmake_includes ${arg_EXTRA_CMAKE_INCLUDES})
set(extra_cmake_code "")
CMake: Add qt 'policy' support This mimics CMake's policy support. The policy state is stored in an internal __QT_INTERNAL_POLICY_<policy> variable; by using normal variables, we gain support for stacking for free. Policies can be explicitly en- or disable via qt6_policy; that command also has a GET mode to retrieve them again. Furthermore, one can now pass min and max version to qt6_standard_project_setup, to opt in to a certain set of defaults introduced in a given Qt version. We add support for policies in QtModuleHelpers, so that we can check for known policies while building Qt itself. No actual policies exist yet; but a follow up commit will introduce one for qt_add_qml_module. Change-Id: I57a0404c9193926dd499f94cc5f73e359355c0b3 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-12-06 21:07:38 +01:00
if(arg_POLICIES)
set(policies "")
foreach(policy IN LISTS arg_POLICIES)
list(APPEND policies "set(QT_KNOWN_POLICY_${policy} TRUE)")
# When building Qt, tests and examples might expect a policy to be known, but they
# won't be known depending on which scope or when a find_package(Module) with the
# respective policy is called. Check the global list of known policies to accommodate
# that.
set_property(GLOBAL APPEND PROPERTY _qt_global_known_policies "${policy}")
endforeach()
list(JOIN policies "\n" policies_str)
string(APPEND extra_cmake_code "${policies_str}\n")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
# Generate metatypes
Remove GENERATE_METATYPES It doesn't seem like that it is being used anymore, except an instance in pro2cmake which I replaced by NO_GENERATE_METATYPES. Pick-to: 6.5 Change-Id: I135cf47e6041e98b354fb684f0079dad30689dea Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-16 16:05:57 +01:00
if (NOT ${arg_NO_GENERATE_METATYPES} AND NOT target_type STREQUAL "INTERFACE_LIBRARY")
set(args "")
if(QT_WILL_INSTALL)
set(metatypes_install_dir "${INSTALL_ARCHDATADIR}/metatypes")
CMake: Fix CMP0177 warnings CMake 3.31 introduced CMP0177 that warns if an install destination is a not-normalized path. Fix this by normalizing the offending paths before using them. Pick-to: 6.8 Change-Id: I1586bf192a4fd26108aa0448431f19e69df8aacd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-11-08 15:48:24 +01:00
if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.31")
cmake_path(SET metatypes_install_dir NORMALIZE "${metatypes_install_dir}")
endif()
Remove GENERATE_METATYPES It doesn't seem like that it is being used anymore, except an instance in pro2cmake which I replaced by NO_GENERATE_METATYPES. Pick-to: 6.5 Change-Id: I135cf47e6041e98b354fb684f0079dad30689dea Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-16 16:05:57 +01:00
list(APPEND args
__QT_INTERNAL_INSTALL __QT_INTERNAL_INSTALL_DIR "${metatypes_install_dir}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
Remove GENERATE_METATYPES It doesn't seem like that it is being used anymore, except an instance in pro2cmake which I replaced by NO_GENERATE_METATYPES. Pick-to: 6.5 Change-Id: I135cf47e6041e98b354fb684f0079dad30689dea Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-16 16:05:57 +01:00
qt6_extract_metatypes(${target} ${args})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
Remove GENERATE_METATYPES It doesn't seem like that it is being used anymore, except an instance in pro2cmake which I replaced by NO_GENERATE_METATYPES. Pick-to: 6.5 Change-Id: I135cf47e6041e98b354fb684f0079dad30689dea Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-01-16 16:05:57 +01:00
CMake: Enable NEW policies by CMake version with a global default When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-30 18:46:49 +11:00
qt_internal_get_min_new_policy_cmake_version(min_new_policy_version)
qt_internal_get_max_new_policy_cmake_version(max_new_policy_version)
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 17:19:22 +01:00
if(is_static_lib)
set(write_basic_module_package_args IS_STATIC_LIB)
else()
set(write_basic_module_package_args "")
endif()
CMake: Add a way to mark modules as "load the private module too" Add FIND_PRIVATE_MODULE argument to qt_internal_add_module. If this argument is set for Qt6Foo, then find_package(Qt6Foo) will also find_package(Qt6FooPrivate). This should only be necessary in exceptional cases like Qt6Qml where Qt6QmlPrivate is used unconditionally. Task-number: QTBUG-87776 Change-Id: I8d6fbd0624c0008fc42294ff2d2ed36848963508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-27 10:02:23 +01:00
if(arg_FIND_PRIVATE_MODULE)
set(write_basic_public_module_package_args FIND_PRIVATE_MODULE)
else()
set(write_basic_public_module_package_args "")
endif()
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
qt_internal_write_basic_module_package("${target}" "${target_private}"
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 17:19:22 +01:00
${write_basic_module_package_args}
CMake: Add a way to mark modules as "load the private module too" Add FIND_PRIVATE_MODULE argument to qt_internal_add_module. If this argument is set for Qt6Foo, then find_package(Qt6Foo) will also find_package(Qt6FooPrivate). This should only be necessary in exceptional cases like Qt6Qml where Qt6QmlPrivate is used unconditionally. Task-number: QTBUG-87776 Change-Id: I8d6fbd0624c0008fc42294ff2d2ed36848963508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-27 10:02:23 +01:00
${write_basic_public_module_package_args}
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
CONFIG_BUILD_DIR ${config_build_dir}
CONFIG_INSTALL_DIR ${config_install_dir}
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
)
if (EXISTS "${CMAKE_CURRENT_LIST_DIR}/${INSTALL_CMAKE_NAMESPACE}${target}BuildInternals.cmake")
configure_file("${CMAKE_CURRENT_LIST_DIR}/${INSTALL_CMAKE_NAMESPACE}${target}BuildInternals.cmake"
"${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}BuildInternals.cmake"
@ONLY)
list(APPEND extra_cmake_files "${config_build_dir}/${INSTALL_CMAKE_NAMESPACE}${target}BuildInternals.cmake")
endif()
qt_install(FILES
${extra_cmake_files}
DESTINATION "${config_install_dir}"
COMPONENT Devel
)
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
if(NOT arg_NO_PRIVATE_MODULE)
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 17:19:22 +01:00
qt_internal_write_basic_module_package("${target}" "${target_private}"
${write_basic_module_package_args}
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
PRIVATE
CONFIG_BUILD_DIR ${private_config_build_dir}
CONFIG_INSTALL_DIR ${private_config_install_dir}
)
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
file(COPY ${extra_cmake_files} DESTINATION "${config_build_dir}")
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
_qt_internal_forward_function_args(
FORWARD_PREFIX arg
FORWARD_OUT_VAR export_module_args
FORWARD_OPTIONS NO_ADDITIONAL_TARGET_INFO
)
qt_internal_export_module(${target}
${export_module_args}
CONFIG_BUILD_DIR ${config_build_dir}
CONFIG_INSTALL_DIR ${config_install_dir}
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
)
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
if(NOT arg_NO_PRIVATE_MODULE)
qt_internal_export_module(${target_private}
${export_module_args}
CONFIG_BUILD_DIR ${private_config_build_dir}
CONFIG_INSTALL_DIR ${private_config_install_dir}
)
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
wasm: add cmake build support A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-03 18:29:41 +10:00
if(BUILD_SHARED_LIBS)
qt_apply_rpaths(TARGET "${target}" INSTALL_PATH "${INSTALL_LIBDIR}" RELATIVE_RPATH)
CMake: Work around build rpath issue when CMAKE_STAGING_PREFIX is set CMake has logic to rewrite build rpaths that contain CMAKE_STAGING_PREFIX to instead point to CMAKE_INSTALL_PREFIX. This breaks running executables from the build directory, because their build rpath will point to a location where the libraries might not exist yet (we didn't install Qt yet). Work around this by setting CMAKE_STAGING_PREFIX to a fake path, so that CMake does not do the rewriting anymore. CMAKE_STAGING_PREFIX needs to be set at subdirectory scope, not function scope, which is why qt_internal_apply_staging_prefix_build_rpath_workaround() is a macro that is called from within each Qt internal function that creates a target. The workaround can be disabled by configuring with -DQT_NO_STAGING_PREFIX_BUILD_RPATH_WORKAROUND=ON The downside of this workaround is that it breaks per-subdirectory install rules like 'ninja src/gui/install'. Regular global installation like 'ninja install' works fine. This is similar to what we do for tests in qt_set_up_fake_standalone_tests_install_prefix() introduced by 20292250d44e08437306096e9096fc655cc9fb8b The reason it's not as good for other target types is because in contrast to tests, we do want to install them. In case if someone does call `ninja src/gui/install' they will most likely get a permission error, telling them it's not possible to install into /qt_fake_staging_prefix/ check_qt_internal_apply_staging_prefix_build_rpath_workaround Fixes: QTBUG-102592 Change-Id: I6ce78dde1924a8d830ef5c62808ff674c9639d65 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-04-14 18:04:41 +02:00
qt_internal_apply_staging_prefix_build_rpath_workaround()
wasm: add cmake build support A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-03 18:29:41 +10:00
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
if (ANDROID AND NOT arg_HEADER_MODULE)
# Record install library location so it can be accessed by
CMake: make sure to collect Android dependencies for plugins androiddeployqt relies on *-android-dependencies.xml files to know what dependencies like jar files and permissions a Qt module requires. CMake create those files under Qt prefix's lib dir but CMake was not accounting for module plugins. Fixes: QTBUG-90812 Pick-to: 6.1 6.0 Change-Id: Ib3b2e2bb237159b4851ac0f23dc75f8e56af3f7a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-02-10 00:07:58 +02:00
# qt_internal_android_dependencies without having to specify it again.
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
set_target_properties(${target} PROPERTIES
QT_ANDROID_MODULE_INSTALL_DIR ${INSTALL_LIBDIR})
endif()
### fixme: cmake is missing a built-in variable for this. We want to apply it only to modules and plugins
# that belong to Qt.
if(NOT arg_HEADER_MODULE)
qt_internal_add_link_flags_no_undefined("${target}")
endif()
set(interface_includes "")
Fix internal module mappings of the qtdeclarative repo Add 'Private' suffix to the internal module names in the mappings of the qmake files for modules of the qtdeclarative repo. Change-Id: I1592ebad0f0db553322ea766561b1b8c3fd38aea Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-29 17:45:19 +02:00
# Handle cases like QmlDevToolsPrivate which do not have their own headers, but rather borrow them
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
# from another module.
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
if(NOT arg_NO_SYNC_QT AND NOT arg_NO_MODULE_HEADERS)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
list(APPEND interface_includes "$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}>")
Fix comment in QtModuleHelpers.cmake Don't talk about syncqt.pl anymore. Change-Id: If153ffde9992c784cf71ae1bb5192e5e4bbb8628 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-06-23 09:23:55 +02:00
# syncqt does not create a private header directory like 'include/6.0/QtFoo' unless
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
# the module has foo_p.h header files. For QtZlib, there are no such private headers, so we
# need to make sure not to add such include paths unless the directory exists, otherwise
# consumers of the module will fail at CMake generation time stating that
# INTERFACE_INCLUDE_DIRECTORIES contains a non-existent path.
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
qt_internal_append_include_directories_with_headers_check(${target}
interface_includes PRIVATE
"$<BUILD_INTERFACE:${module_build_interface_versioned_include_dir}>"
"$<BUILD_INTERFACE:${module_build_interface_versioned_inner_include_dir}>"
)
if(is_framework)
set(fw_install_private_header_dir "${INSTALL_LIBDIR}/${fw_private_header_dir}")
set(fw_install_private_module_header_dir
"${INSTALL_LIBDIR}/${fw_private_module_header_dir}")
qt_internal_append_include_directories_with_headers_check(${target}
interface_includes PRIVATE
"$<INSTALL_INTERFACE:${fw_install_private_header_dir}>"
"$<INSTALL_INTERFACE:${fw_install_private_module_header_dir}>"
)
else()
qt_internal_append_include_directories_with_headers_check(${target}
interface_includes PRIVATE
"$<INSTALL_INTERFACE:${module_install_interface_versioned_include_dir}>"
"$<INSTALL_INTERFACE:${module_install_interface_versioned_inner_include_dir}>"
)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endif()
endif()
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
if(arg_INTERNAL_MODULE)
target_include_directories("${target}" INTERFACE ${interface_includes})
elseif(NOT ${arg_NO_PRIVATE_MODULE})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
target_include_directories("${target_private}" INTERFACE ${interface_includes})
target_link_libraries("${target_private}" INTERFACE "${target}")
endif()
CMake Build: Enable separate debug info for all target types Now all shared libraries and executables will get .debug files on the platforms that support FEATURE_separate_debug_info With the directory property _qt_skip_separate_debug_info certain targets can retain the debug symbols in the binary e.g. lupdate with MinGW 8.1.0 will cause objcopy / strip to fail. Fixes: QTBUG-87015 Change-Id: I03b106e68ef0a42011d1ba641e6f686b2e7b7fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-02 12:40:57 +01:00
set(debug_install_dir "${INSTALL_LIBDIR}")
if (MINGW)
set(debug_install_dir "${INSTALL_BINDIR}")
endif()
qt_enable_separate_debug_info(${target} "${debug_install_dir}")
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 22:07:33 +02:00
set(pdb_install_dir "${INSTALL_BINDIR}")
if(NOT is_shared_lib)
set(pdb_install_dir "${INSTALL_LIBDIR}")
endif()
qt_internal_install_pdb_files(${target} "${pdb_install_dir}")
cmake: Respect NO_PRIVATE_MODULE when generating module pri files Change-Id: Id5816d6598a0a484c20674f34f6f809e68671e6b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-21 14:13:49 +02:00
if (arg_NO_PRIVATE_MODULE)
set(arg_NO_PRIVATE_MODULE "NO_PRIVATE_MODULE")
else()
unset(arg_NO_PRIVATE_MODULE)
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
qt_describe_module(${target})
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 18:02:56 +01:00
if(QT_GENERATE_SBOM)
CMake: Allow specifying most SBOM options to qt_internal_add_foo Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-06-14 19:07:16 +02:00
set(sbom_args "")
CMake: Detect 3rd party header modules during SBOM generation They should inherit the version of the 3rd party library they are part of, and not be treated as Qt modules. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: Ibf99f4481fbc1acca488fc96cca048298b080d35 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-08-02 15:06:31 +02:00
# 3rd party header modules should not be treated as Qt modules.
if(arg_IS_QT_3RD_PARTY_HEADER_MODULE)
list(APPEND sbom_args TYPE QT_THIRD_PARTY_MODULE)
else()
list(APPEND sbom_args TYPE QT_MODULE)
endif()
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 18:02:56 +01:00
qt_get_cmake_configurations(configs)
foreach(config IN LISTS configs)
_qt_internal_sbom_append_multi_config_aware_single_arg_option(
RUNTIME_PATH
"${INSTALL_BINDIR}"
"${config}"
sbom_args
)
_qt_internal_sbom_append_multi_config_aware_single_arg_option(
LIBRARY_PATH
"${INSTALL_LIBDIR}"
"${config}"
sbom_args
)
_qt_internal_sbom_append_multi_config_aware_single_arg_option(
ARCHIVE_PATH
"${INSTALL_LIBDIR}"
"${config}"
sbom_args
)
_qt_internal_sbom_append_multi_config_aware_single_arg_option(
FRAMEWORK_PATH
"${INSTALL_LIBDIR}/${fw_versioned_binary_dir}"
"${config}"
sbom_args
)
endforeach()
CMake: Allow specifying most SBOM options to qt_internal_add_foo Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2024-06-14 19:07:16 +02:00
_qt_internal_forward_function_args(
FORWARD_APPEND
FORWARD_PREFIX arg
FORWARD_OUT_VAR sbom_args
FORWARD_OPTIONS
${__qt_internal_sbom_optional_args}
FORWARD_SINGLE
${__qt_internal_sbom_single_args}
FORWARD_MULTI
${__qt_internal_sbom_multi_args}
)
CMake: Decouple Qt specific handling from SBOM implementation The SBOM functions so far had a lot of Qt-specific logic inside them. Decouple this logic into separate Qt-specific functions or explicitly guard the code with Qt-specific handling options, to prepare for a cleaner SBOM public API. The generic functions then call the Qt-specific ones if various internal options are set. This approach is used, rather than directly passing values to the generic functions because: - we have cases where we need to recursively pass the values all the way down to all recursively created attribution targets - some of the logic needs to know about values before and after qt processing, and this could be achieved with something like lambdas but it's not worth the complexity Pick-to: 6.8 6.9 Task-number: QTBUG-122899 Change-Id: I4399c41f4d976f20b16a0bb0c674d4f07ee1ccd4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2025-01-13 15:30:15 +01:00
qt_internal_extend_qt_entity_sbom(${target} ${sbom_args})
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 18:02:56 +01:00
endif()
Do not use the HEADER_MODULE argument in qt_generate_module_pri_file HEADER_MODULE argument is passed to qt_generate_module_pri_file from the qt_internal_add_module function, but the property means that the module is an interface library. So it makes sense to replace this argument with the reading of the target TYPE. Change-Id: I1d8cd2ff732f526975cde6bdd4783fee44c8bd98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-10 16:21:37 +02:00
qt_add_list_file_finalizer(qt_finalize_module ${target} ${arg_INTERNAL_MODULE} ${arg_NO_PRIVATE_MODULE})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endfunction()
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
# Write and install the basic Qt6Foo and Qt6FooPrivate packages.
#
# If PRIVATE is specified, write Qt6FooPrivate.
# Otherwise write its public counterpart.
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 17:19:22 +01:00
function(qt_internal_write_basic_module_package target target_private)
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
set(no_value_options
CMake: Add a way to mark modules as "load the private module too" Add FIND_PRIVATE_MODULE argument to qt_internal_add_module. If this argument is set for Qt6Foo, then find_package(Qt6Foo) will also find_package(Qt6FooPrivate). This should only be necessary in exceptional cases like Qt6Qml where Qt6QmlPrivate is used unconditionally. Task-number: QTBUG-87776 Change-Id: I8d6fbd0624c0008fc42294ff2d2ed36848963508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-27 10:02:23 +01:00
FIND_PRIVATE_MODULE
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 17:19:22 +01:00
IS_STATIC_LIB
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
PRIVATE
)
set(single_value_options
CONFIG_BUILD_DIR
CONFIG_INSTALL_DIR
)
set(multi_value_options "")
cmake_parse_arguments(PARSE_ARGV 0 arg
"${no_value_options}" "${single_value_options}" "${multi_value_options}"
)
CMake: Add a way to mark modules as "load the private module too" Add FIND_PRIVATE_MODULE argument to qt_internal_add_module. If this argument is set for Qt6Foo, then find_package(Qt6Foo) will also find_package(Qt6FooPrivate). This should only be necessary in exceptional cases like Qt6Qml where Qt6QmlPrivate is used unconditionally. Task-number: QTBUG-87776 Change-Id: I8d6fbd0624c0008fc42294ff2d2ed36848963508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-27 10:02:23 +01:00
set(always_load_private_module OFF)
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
if(arg_PRIVATE)
set(package_name "${INSTALL_CMAKE_NAMESPACE}${target_private}")
set(module_config_input_file "QtModuleConfigPrivate.cmake.in")
else()
set(package_name "${INSTALL_CMAKE_NAMESPACE}${target}")
set(module_config_input_file "QtModuleConfig.cmake.in")
CMake: Add a way to mark modules as "load the private module too" Add FIND_PRIVATE_MODULE argument to qt_internal_add_module. If this argument is set for Qt6Foo, then find_package(Qt6Foo) will also find_package(Qt6FooPrivate). This should only be necessary in exceptional cases like Qt6Qml where Qt6QmlPrivate is used unconditionally. Task-number: QTBUG-87776 Change-Id: I8d6fbd0624c0008fc42294ff2d2ed36848963508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-27 10:02:23 +01:00
if(arg_FIND_PRIVATE_MODULE)
set(always_load_private_module ON)
endif()
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
endif()
CMake: Fix -no-prefix build with CMake < 3.26 on macOS On macOS, Core has plugins that link against CorePrivate. In a non-prefix build, user projects failed on find_package(Qt6 REQUIRED COMPONENTS Core), because CorePrivate is required for these plugins in a non-prefix build, but it's not automatically pulled in. This is only an issue for CMake < 3.26, because these older CMake versions lack the BUILD_LOCAL_INTERFACE generator expression. Fix this by pulling in the private modules for non-prefix builds when using CMake < 3.26. Also, issue a warning in this situation. Fixes: QTBUG-134407 Change-Id: I7f182c9518686390e657663b452cad8101d870a2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-06 14:42:46 +01:00
if((QT_FEATURE_no_prefix OR arg_IS_STATIC_LIB)
AND NOT arg_PRIVATE
AND CMAKE_VERSION VERSION_LESS "3.26")
# We auto-load the private module package from the public module package if we have a
# statically built module or a non-prefix build and CMake's version is < 3.26. This is
# needed for the case "Qt6Foo links against Qt6BarPrivate", because CMake generates a check
# for the target Qt6::BarPrivate in Qt6FooTargets.cmake. Once we can require CMake 3.26, we
# can simply link against $<BUILD_LOCAL_INTERFACE:Qt6BarPrivate> in
# qt_internal_extend_target.
CMake: Only load Qt6FooPrivate automatically when building Qt [ChangeLog][CMake] CMake packages of public Qt modules don't provide the targets of their private counterparts anymore. User projects must now call find_package(Qt6 COMPONENTS FooPrivate) to make use of the Qt6::FooPrivate target. User projects that rely on the old behavior can set the CMake variable QT_FIND_PRIVATE_MODULES to ON. For user projects, the warning message we know from QMake is displayed. The warning can be disabled by setting the CMake variable QT_NO_PRIVATE_MODULE_WARNING to ON. Within Qt itself, find_package(Qt6Foo) will still find_package(Qt6FooPrivate). For static Qt builds, we need to wrap usage of private Qt modules in $<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >= 3.26). Static builds with CMake < 3.26 will always load the private modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This is the case in non-prefix builds and (in the future) when building examples as external project. This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f. Pick-to: 6.9 Task-number: QTBUG-87776 Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-03 17:19:22 +01:00
#
# For older CMake versions, we create an additional CMake file that's optionally included by
# Qt6FooConfig.cmake to work around the lack of BUILD_LOCAL_INTERFACE.
file(CONFIGURE
OUTPUT "${arg_CONFIG_BUILD_DIR}/${package_name}-build.cmake"
CONTENT "# This file marks this directory as part of Qt's build tree.
set(__qt_${target}_always_load_private_module ON)
"
)
endif()
CMake: Split off private module config packages [ChangeLog][CMake] Private Qt modules have been split off into separate Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will now implicitly find_package(Qt6FooPrivate). It's not an error if Qt6FooPrivate isn't available as it may be the case on certain Linux distros that split their Qt module packages into private and public parts. For every public module Qt6Foo that has an associated Qt6FooPrivate module, create a separate Qt6FooPrivate CMake config package. Let Qt6FooPrivate find Qt6Foo. This is a required dependency. Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level VERBOSE is issued if Qt6FooPrivate is not found. Implementation notes: In QtModuleConfig.cmake.in, we pull in the private module. This is not part of the *Dependencies.cmake file, because 1. The Qt6FooPrivate package references the Qt6::Foo target, therefore it must be available. And Qt6FooDependencies.cmake is loaded before creating targets. 2. The dependency needs to be optional, and we don't have facilities for optional dependencies in Qt6FooDependencies yet. 3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo dependency. Fixes: QTBUG-87776 Pick-to: 6.9 Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-09 21:14:50 +01:00
configure_package_config_file(
"${QT_CMAKE_DIR}/${module_config_input_file}"
"${arg_CONFIG_BUILD_DIR}/${package_name}Config.cmake"
INSTALL_DESTINATION "${arg_CONFIG_INSTALL_DIR}"
)
write_basic_package_version_file(
"${arg_CONFIG_BUILD_DIR}/${package_name}ConfigVersionImpl.cmake"
VERSION ${PROJECT_VERSION}
COMPATIBILITY AnyNewerVersion
)
qt_internal_write_qt_package_version_file(
"${package_name}"
"${arg_CONFIG_BUILD_DIR}/${package_name}ConfigVersion.cmake"
)
qt_install(FILES
"${arg_CONFIG_BUILD_DIR}/${package_name}Config.cmake"
"${arg_CONFIG_BUILD_DIR}/${package_name}ConfigVersion.cmake"
"${arg_CONFIG_BUILD_DIR}/${package_name}ConfigVersionImpl.cmake"
DESTINATION "${arg_CONFIG_INSTALL_DIR}"
COMPONENT Devel
)
endfunction()
function(qt_internal_export_module target)
set(no_value_options
NO_ADDITIONAL_TARGET_INFO
)
set(single_value_options
CONFIG_BUILD_DIR
CONFIG_INSTALL_DIR
)
set(multi_value_options "")
cmake_parse_arguments(PARSE_ARGV 1 arg
"${no_value_options}" "${single_value_options}" "${multi_value_options}"
)
_qt_internal_validate_all_args_are_parsed(arg)
set(export_name "${INSTALL_CMAKE_NAMESPACE}${target}Targets")
qt_install(TARGETS ${target}
EXPORT ${export_name}
RUNTIME DESTINATION ${INSTALL_BINDIR}
LIBRARY DESTINATION ${INSTALL_LIBDIR}
ARCHIVE DESTINATION ${INSTALL_LIBDIR}
FRAMEWORK DESTINATION ${INSTALL_LIBDIR}
)
qt_install(EXPORT ${export_name}
NAMESPACE ${QT_CMAKE_EXPORT_NAMESPACE}::
DESTINATION ${arg_CONFIG_INSTALL_DIR})
if(NOT arg_NO_ADDITIONAL_TARGET_INFO)
qt_internal_export_additional_targets_file(
TARGETS ${target}
EXPORT_NAME_PREFIX ${INSTALL_CMAKE_NAMESPACE}${target}
CONFIG_INSTALL_DIR "${arg_CONFIG_INSTALL_DIR}")
endif()
qt_internal_export_modern_cmake_config_targets_file(
TARGETS ${target}
EXPORT_NAME_PREFIX ${INSTALL_CMAKE_NAMESPACE}${target}
CONFIG_BUILD_DIR "${arg_CONFIG_BUILD_DIR}"
CONFIG_INSTALL_DIR "${arg_CONFIG_INSTALL_DIR}"
)
qt_internal_export_genex_properties(TARGETS ${target}
EXPORT_NAME_PREFIX ${INSTALL_CMAKE_NAMESPACE}${target}
CONFIG_INSTALL_DIR "${arg_CONFIG_INSTALL_DIR}"
)
endfunction()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
cmake: Generate Apple privacy manifest files for Qt modules The default manifest is a minimal file that claims NSPrivacyTracking false, along with an empty list of NSPrivacyTrackingDomains and NSPrivacyCollectedDataTypes, as Qt does not generally do user tracking. Modules can override the default manifest by setting the PRIVACY_MANIFEST target property, specifying a custom privacy manifest. The NSPrivacyAccessedAPITypes key is only required for iOS for now. Even though we don't build Qt for iOS as frameworks yet, which is required to embed a privacy manifest, we include the keys for the APIs we known we use. Task-number: QTBUG-114319 Change-Id: I654bb52b98ee963adeeb744b35f3a1c2a1270969 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-12 15:19:56 +01:00
function(qt_internal_apply_apple_privacy_manifest target)
CMake: Fix calling some functions in CMake 3.16 Calling qt_internal_get_framework_info failed when the target was an INTERFACE_LIBRARY, because it tried to access properties that aren't allowed on such a target. Interface libraries can't be frameworks, so just add an early return guard. Do the same for qt_internal_apply_apple_privacy_manifest. Change-Id: I85b73449a0d56b92cd01b032d4ce5db905643c9f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 18:02:56 +01:00
# Avoid "INTERFACE_LIBRARY targets may only have whitelisted properties" error on CMake < 3.17.
get_target_property(target_type ${target} TYPE)
if("${target_type}" STREQUAL "INTERFACE_LIBRARY")
return()
endif()
cmake: Generate Apple privacy manifest files for Qt modules The default manifest is a minimal file that claims NSPrivacyTracking false, along with an empty list of NSPrivacyTrackingDomains and NSPrivacyCollectedDataTypes, as Qt does not generally do user tracking. Modules can override the default manifest by setting the PRIVACY_MANIFEST target property, specifying a custom privacy manifest. The NSPrivacyAccessedAPITypes key is only required for iOS for now. Even though we don't build Qt for iOS as frameworks yet, which is required to embed a privacy manifest, we include the keys for the APIs we known we use. Task-number: QTBUG-114319 Change-Id: I654bb52b98ee963adeeb744b35f3a1c2a1270969 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-12 15:19:56 +01:00
if(APPLE)
# Privacy manifest
get_target_property(is_framework ${target} FRAMEWORK)
if(is_framework)
get_target_property(privacy_manifest ${target} _qt_privacy_manifest)
if(NOT privacy_manifest)
set(privacy_manifest
"${__qt_internal_cmake_apple_support_files_path}/PrivacyInfo.xcprivacy")
endif()
target_sources("${target}" PRIVATE "${privacy_manifest}")
set_property(TARGET "${target}" APPEND PROPERTY RESOURCE "${privacy_manifest}")
endif()
endif()
endfunction()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
function(qt_finalize_module target)
CMake: Warn on creation of private modules without private headers Private modules without private headers don't make much sense and needlessly create CMake packages and QMake module pri files. In qt_finalize_module we check whether the module has any private headers. But the private module was already created before in qt_internal_add_module. Moving the creation of the private module or the CMake package files to the finalization phase would be a bigger refactoring that's probably not worth the hassle. An easier way to avoid the package creation issue is to mandate that a Qt module must be created with NO_PRIVATE_MODULE if it doesn't have any private headers. Add a warning if a Qt module without private headers is created without NO_PRIVATE_MODULE. Also warn if a Qt module with private headers is created with NO_PRIVATE_MODULE. This allows us to easily spot the places where NO_PRIVATE_MODULE is missing. Task-number: QTBUG-132526 Change-Id: I897f25790a99eaa320c39cd8c2728f26bceb824e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-12 09:28:35 +01:00
set(no_value_options
INTERNAL_MODULE
NO_PRIVATE_MODULE
)
set(single_value_options "")
set(multi_value_options "")
cmake_parse_arguments(PARSE_ARGV 1 arg
"${no_value_options}" "${single_value_options}" "${multi_value_options}"
)
_qt_internal_validate_all_args_are_parsed(arg)
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
qt_internal_collect_module_headers(module_headers ${target})
CMake: Warn on creation of private modules without private headers Private modules without private headers don't make much sense and needlessly create CMake packages and QMake module pri files. In qt_finalize_module we check whether the module has any private headers. But the private module was already created before in qt_internal_add_module. Moving the creation of the private module or the CMake package files to the finalization phase would be a bigger refactoring that's probably not worth the hassle. An easier way to avoid the package creation issue is to mandate that a Qt module must be created with NO_PRIVATE_MODULE if it doesn't have any private headers. Add a warning if a Qt module without private headers is created without NO_PRIVATE_MODULE. Also warn if a Qt module with private headers is created with NO_PRIVATE_MODULE. This allows us to easily spot the places where NO_PRIVATE_MODULE is missing. Task-number: QTBUG-132526 Change-Id: I897f25790a99eaa320c39cd8c2728f26bceb824e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-03-12 09:28:35 +01:00
# Issue a warning if we
# - suppressed creation of the private module but have private headers
# - created a private module but don't have any private headers
if(NOT arg_INTERNAL_MODULE)
get_target_property(has_private_headers ${target} _qt_module_has_private_headers)
if(arg_NO_PRIVATE_MODULE AND has_private_headers)
message(AUTHOR_WARNING
"Module ${target} has private headers. "
"Please remove NO_PRIVATE_MODULE from its creation flags."
)
elseif(NOT arg_NO_PRIVATE_MODULE AND NOT has_private_headers)
message(AUTHOR_WARNING
"Module ${target} does not have private headers. "
"Please add NO_PRIVATE_MODULE to its creation flags."
)
endif()
endif()
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
# qt_internal_install_module_headers needs to be called before
# qt_finalize_framework_headers_copy, because the last uses the QT_COPIED_FRAMEWORK_HEADERS
Replace the syncqt.pl script with syncqt tool 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 <alexandru.croitor@qt.io>
2022-08-15 18:29:41 +02:00
# property which supposed to be updated inside every qt_internal_install_module_headers
# call.
Remove perl related functionality from CMake files Avoid using perl in CMake scripts. Remove the syncqt.pl specific code. Task-number: QTBUG-87480 Change-Id: I7fcd5cc83d173ec463c275b5b50b84f25044a118 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-05 16:32:31 +02:00
qt_internal_add_headersclean_target(${target} "${module_headers_public}")
CMake: Fix dbus and vk headers to be excluded from doc generation Before this change, if someone called ninja Gui_generate_docs, it would implicitly depend on sync_all_public_headers -> Gui_sync_headers which would generate dbus headers. This caused trouble with the new 'build doc tools from qttools/dev/HEAD' approach, because an older pre-built dbus tool might be passed a newer option when integrating a qtbase change that passes the new option. To avoid that, we now filter out the dbus headers from the list of headers that should be processed by syncqt when building a documentation target. We do the same for the qvkgen generated headers. This also removes the dependency on the ${target}_sync_headers target, which means there is a potential issue when someone manually calls `ninja sync_all_public_headers Gui_sync_headers` or something like it, which would spawn two syncqt processes that access the same files concurrently. This is an edge case that should not happen, but if it ends up happening, we will have to implement some kind of lock file mechanism. Pick-to: 6.8 6.9 Fixes: QTBUG-134672 Task-number: QTBUG-128730 Change-Id: I9061f9495e2faa77744f5f5c0de8fedd362ba228 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-03-20 15:39:02 +01:00
qt_internal_target_sync_headers(${target}
"${module_headers_all}"
"${module_headers_generated}"
"${module_headers_exclude_from_docs}"
)
Remove perl related functionality from CMake files Avoid using perl in CMake scripts. Remove the syncqt.pl specific code. Task-number: QTBUG-87480 Change-Id: I7fcd5cc83d173ec463c275b5b50b84f25044a118 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-05 16:32:31 +02:00
get_target_property(module_depends_header ${target} _qt_module_depends_header)
qt_internal_install_module_headers(${target}
PUBLIC ${module_headers_public} "${module_depends_header}"
PRIVATE ${module_headers_private}
QPA ${module_headers_qpa}
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
RHI ${module_headers_rhi}
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
SSG ${module_headers_ssg}
Remove perl related functionality from CMake files Avoid using perl in CMake scripts. Remove the syncqt.pl specific code. Task-number: QTBUG-87480 Change-Id: I7fcd5cc83d173ec463c275b5b50b84f25044a118 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-05 16:32:31 +02:00
)
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
Move qt_finalize_framework_headers_copy to the scope finalizer The qt_finalize_framework_headers_copy function uses the module QT_COPIED_FRAMEWORK_HEADERS property to generate the dependency list for the ${target}_framework_headers target. In a common case elements can be added to the QT_COPIED_FRAMEWORK_HEADERS property after the qt_internal_add_module command call, that's why we need to make sure that qt_finalize_framework_headers_copy is called after collecting all headers assigned to the module. Pick-to: 6.2 Change-Id: I2878fa6b8d4b11677c3f48345bf6e239221074c2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-03 10:44:38 +01:00
qt_finalize_framework_headers_copy(${target})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
qt_generate_prl_file(${target} "${INSTALL_LIBDIR}")
qt_generate_module_pri_file("${target}" ${ARGN})
CMake build: generate pkgconfig for public modules After the update to the CMake based build system the ability to generate pkgconfig files, like it was with QMake, was lost. This patch adds pkgconfig generation again via a new internal command named qt_internal_export_pkg_config_file. The functionality of this command consists in checking if the target is internal. Then gets the compile definitions. It performs a search for dependencies that is somewhat similar to qt_get_direct_module_dependencies, although it won't recurse down for more deps. Each dependency is then again, checked if it's internal or has a public interface. Later these deps get deduplicated and lastly a pkgconfig file is filled. The resulting pkgconfig files of many of the Qt6 packages were validated via invocations of `pkg-config --validate` and `pkg-config --simulate` commands and later used to build local projects plus tests that use the pkg-config provided details at compilation time. Although it has some limitations, with qt_internal_add_qml_module if it specifies non-public deps these won't be listed and with non-Qt requirements, notably in static builds, not being appended to the PkgConfig file. Task-number: QTBUG-86080 Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-11 14:39:53 -03:00
qt_internal_generate_pkg_config_file(${target})
cmake: Generate Apple privacy manifest files for Qt modules The default manifest is a minimal file that claims NSPrivacyTracking false, along with an empty list of NSPrivacyTrackingDomains and NSPrivacyCollectedDataTypes, as Qt does not generally do user tracking. Modules can override the default manifest by setting the PRIVACY_MANIFEST target property, specifying a custom privacy manifest. The NSPrivacyAccessedAPITypes key is only required for iOS for now. Even though we don't build Qt for iOS as frameworks yet, which is required to embed a privacy manifest, we include the keys for the APIs we known we use. Task-number: QTBUG-114319 Change-Id: I654bb52b98ee963adeeb744b35f3a1c2a1270969 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-02-12 15:19:56 +01:00
qt_internal_apply_apple_privacy_manifest(${target})
CMake: Generate an SPDX v2.3 SBOM file for each built repository This change adds a new -sbom configure option to allow generating and installing an SPDX v2.3 SBOM file when building a qt repo. The -sbom-dir option can be used to configure the location where each repo sbom file will be installed. By default it is installed into $prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx which is basically ~/Qt/sbom/qtbase-6.8.0.spdx The file is installed as part of the default installation rules, but it can also be installed manually using the "sbom" installation component, or "sbom_$lower_project_name" in a top-level build. For example: cmake install . --component sbom_qtbase CMake 3.19+ is needed to read the qt_attribution.json files for copyrights, license info, etc. When using an older cmake version, configuration will error out. It is possible to opt into using an older cmake version, but the generated sbom will lack all the attribution file information. Using an older cmake version is untested and not officially supported. Implementation notes. The bulk of the implementation is split into 4 new files: - QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing and dispatching the generation of various pieces of the SBOM document e.g. a SDPX package associated with a target like Core, a SDPX file entry for each target binary file (per-config shared library, archive, executable, etc) - QtPublicSbomGenerationHelpers.cmake - for non-Qt specific implementation of SPDX generation. This also has some code that was taken from the cmake-sbom 3rd party project, so it is dual licensed under the usual Qt build system BSD license, as well as the MIT license of the 3rd party project - QtPublicGitHelpers.cmake - for git related features, mainly to embed queried hashes or tags into version strings, is dual-licensed for the same reasons as QtPublicSbomGenerationHelpers.cmake - QtSbomHelpers.cmake - Qt-specific functions that just forward arguments to the public functions. These are meant to be used in our Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones for naming consistency. These function would mostly be used to annotate 3rd party libraries with sbom info and to add sbom info for unusual target setups (like the Bootstrap library), because most of the handling is already done automatically via qt_internal_add_module/plugin/etc. The files are put into Public cmake files, with the future hope of making this available to user projects in some capacity. The distinction of Qt-specific and non-Qt specific code might blur a bit, and thus the separation across files might not always be consistent, but it was best effort. The main purpose of the code is to collect various information about targets and their relationships and generate equivalent SPDX info. Collection is currently done for the following targets: Qt modules, plugins, apps, tools, system libraries, bundled 3rd party libraries and partial 3rd party sources compiled directly as part of Qt targets. Each target has an equivalent SPDX package generated with information like version, license, copyright, CPE (common vulnerability identifier), files that belong to the package, and relationships on other SPDX packages (associated cmake targets), mostly gathered from direct linking dependencies. Each package might also contain files, e.g. libQt6Core.so for the Core target. Each file also has info like license id, copyrights, but also the list of source files that were used to generate the file and a sha1 checksum. SPDX documents can also refer to packages in other SPDX documents, and those are referred to via external document references. This is the case when building qtdeclarative and we refer to Core. For qt provided targets, we have complete information regarding licenses, and copyrights. For bundled 3rd party libraries, we should also have most information, which is usually parsed from the src/3rdparty/libfoo/qt_attribution.json files. If there are multiple attribution files, or if the files have multiple entries, we create a separate SBOM package for each of those entries, because each might have a separate copyright or version, and an sbom package can have only one version (although many copyrights). For system libraries we usually lack the information because we don't have attribution files for Find scripts. So the info needs to be manually annotated via arguments to the sbom function calls, or the FindFoo.cmake scripts expose that information in some form and we can query it. There are also corner cases like 3rdparty sources being directly included in a Qt library, like the m4dc files for Gui, or PCRE2 for Bootstrap. Or QtWebEngine libraries (either Qt bundled or Chromium bundled or system libraries) which get linked in by GN instead of CMake, so there are no direct targets for them. The information for these need to be annotated manually as well. There is also a distinction to be made for static Qt builds (or any static Qt library in a shared build), where the system libraries found during the Qt build might not be the same that are linked into the final user application or library. The actual generation of the SBOM is done by file(GENERATE)-ing one .cmake file for each target, file, external ref, etc, which will be included in a top-level cmake script. The top-level cmake script will run through each included file, to append to a "staging" spdx file, which will then be used in a configure_file() call to replace some final variables, like embedding a file checksum. There are install rules to generate a complete SBOM during installation, and an optional 'sbom' custom target that allows building an incomplete SBOM during the build step. The build target is just for convenience and faster development iteration time. It is incomplete because it is missing the installed file SHA1 checksums and the document verification code (the sha1 of all sha1s). We can't compute those during the build before the files are actually installed. A complete SBOM can only be achieved at installation time. The install script will include all the generated helper files, but also set some additional variables to ensure checksumming happens, and also handle multi-config installation, among other small things. For multi-config builds, CMake doesn't offer a way to run code after all configs are installed, because they might not always be installed, someone might choose to install just Release. To handle that, we rely on ninja installing each config sequentially (because ninja places the install rules into the 'console' pool which runs one task at a time). For each installed config we create a config-specific marker file. Once all marker files are present, whichever config ends up being installed as the last one, we run the sbom generation once, and then delete all marker files. There are a few internal variables that can be set during configuration to enable various checks (and other features) on the generated spdx files: - QT_INTERNAL_SBOM_VERIFY - QT_INTERNAL_SBOM_AUDIT - QT_INTERNAL_SBOM_AUDIT_NO_ERROR - QT_INTERNAL_SBOM_GENERATE_JSON - QT_INTERNAL_SBOM_SHOW_TABLE - QT_INTERNAL_SBOM_DEFAULT_CHECKS These use 3rd party python tools, so they are not enabled by default. If enabled, they run at installation time after the sbom is installed. We will hopefully enable them in CI. Overall, the code is still a bit messy in a few places, due to time constraints, but can be improved later. Some possible TODOs for the future: - Do we need to handle 3rd party libs linked into a Qt static library in a Qt shared build, where the Qt static lib is not installed, but linked into a Qt shared library, somehow specially? We can record a package for it, but we can't create a spdx file record for it (and associated source relationships) because we don't install the file, and spdx requires the file to be installed and checksummed. Perhaps we can consider adding some free-form text snippet to the package itself? - Do we want to add parsing of .cpp source files for Copyrights, to embed them into the packages? This will likely slow down configuration quite a bit. - Currently sbom info attached to WrapFoo packages in one repo is not exported / available in other repos. E.g. If we annotate WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be available when looking up WrapZLIB in qtimageformats. This is because they are IMPORTED libraries, and are not exported. We might want to record this info in the future. [ChangeLog][Build System] A new -sbom configure option can be used to generate and install a SPDX SBOM (Software Bill of Materials) file for each built Qt repository. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 18:02:56 +01:00
_qt_internal_finalize_sbom(${target})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endfunction()
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
# Get a set of Qt module related values based on the target.
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
#
# The function uses the _qt_module_interface_name and _qt_module_include_name target properties to
# preform values for the output variables. _qt_module_interface_name it's the basic name of module
# without "Qtfication" and the "Private" suffix if we speak about INTERNAL_MODULEs. Typical value of
# the _qt_module_interface_name is the provided to qt_internal_add_module ${target} name, e.g. Core.
# _qt_module_interface_name is used to preform all the include paths unless the
# _qt_module_include_name property is specified. _qt_module_include_name is legacy property that
# replaces the module name in include paths and has a higher priority than the
# _qt_module_interface_name property.
#
# When doing qt_internal_module_info(foo Core) this method will set the following variables in
# the caller's scope:
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
# * foo with the value "QtCore"
# * foo_versioned with the value "Qt6Core" (based on major Qt version)
# * foo_upper with the value "CORE"
# * foo_lower with the value "core"
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
# * foo_include_name with the value"QtCore"
# Usually the module name from ${foo} is used, but the name might be different if the
# MODULE_INCLUDE_NAME argument is set when creating the module.
# * foo_versioned_include_dir with the value "QtCore/6.2.0"
# * foo_versioned_inner_include_dir with the value "QtCore/6.2.0/QtCore"
# * foo_private_include_dir with the value "QtCore/6.2.0/QtCore/private"
Add qpa include directory to the return values of qt_internal_module_info Change-Id: I0540ce70e4a5dbde4027d97d9308c61248230c96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-21 17:42:23 +02:00
# * foo_qpa_include_dir with the value "QtCore/6.2.0/QtCore/qpa"
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
# * foo_rhi_include_dir with the value "QtCore/6.2.0/QtCore/rhi"
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
# * foo_ssg_include_dir with the value "QtQuick3D/6.2.0/QtQuick3D/ssg"
Use module interface name as OUTPUT_NAME For internal modules we should keep the name of the file in file system consistent with previous Qt versions. Pick-to: 6.2 Fixes: QTBUG-95077 Change-Id: I02e4fced0fc3172e60f07bc7d1515e23744db567 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-09 12:32:11 +02:00
# * foo_interface_name the interface name of the module stored in _qt_module_interface_name
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
# property, e.g. Core.
#
# The function also sets a bunch of module include paths for the build and install interface.
# Variables that contains these paths start with foo_build_interface_ and foo_install_interface_
# accordingly.
# The following variables are set in the caller's scope:
# * foo_<build|install>_interface_include_dir with
# qtbase_build_dir/include/QtCore for build interface and
# include/QtCore for install interface.
# * foo_<build|install>_interface_versioned_include_dir with
# qtbase_build_dir/include/QtCore/6.2.0 for build interface and
# include/QtCore/6.2.0 for install interface.
# * foo_<build|install>_versioned_inner_include_dir with
# qtbase_build_dir/include/QtCore/6.2.0/QtCore for build interface and
# include/QtCore/6.2.0/QtCore for install interface.
# * foo_<build|install>_private_include_dir with
# qtbase_build_dir/include/QtCore/6.2.0/QtCore/private for build interface and
# include/QtCore/6.2.0/QtCore/private for install interface.
Add qpa include directory to the return values of qt_internal_module_info Change-Id: I0540ce70e4a5dbde4027d97d9308c61248230c96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-21 17:42:23 +02:00
# * foo_<build|install>_qpa_include_dir with
# qtbase_build_dir/include/QtCore/6.2.0/QtCore/qpa for build interface and
# include/QtCore/6.2.0/QtCore/qpa for install interface.
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
# * foo_<build|install>_rhi_include_dir with
# qtbase_build_dir/include/QtCore/6.2.0/QtCore/rhi for build interface and
# include/QtCore/6.2.0/QtCore/rhi for install interface.
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
# * foo_<build|install>_ssg_include_dir with
# qtbase_build_dir/include/<module>/x.y.z/<module>/ssg for build interface and
# include/<module>/x.y.z/<module>/ssg for install interface.
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
# The following values are set by the function and might be useful in caller's scope:
# * repo_install_interface_include_dir contains path to the top-level repository include directory,
# e.g. qtbase_build_dir/include
# * repo_install_interface_include_dir contains path to the non-prefixed top-level include
# directory is used for the installation, e.g. include
# Note: that for non-prefixed Qt configurations the build interface paths will start with
# <build_directory>/qtbase/include, e.g foo_build_interface_include_dir of the Qml module looks
# like qt_toplevel_build_dir/qtbase/include/QtQml
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
function(qt_internal_module_info result target)
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
if(result STREQUAL "repo")
message(FATAL_ERROR "'repo' keyword is reserved for internal use, please specify \
the different base name for the module info variables.")
endif()
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
get_target_property(module_interface_name ${target} _qt_module_interface_name)
if(NOT module_interface_name)
message(FATAL_ERROR "${target} is not a module.")
endif()
qt_internal_qtfy_target(module ${module_interface_name})
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
get_target_property("${result}_include_name" ${target} _qt_module_include_name)
if(NOT ${result}_include_name)
set("${result}_include_name" "${module}")
endif()
set("${result}_versioned_include_dir"
"${${result}_include_name}/${PROJECT_VERSION}")
set("${result}_versioned_inner_include_dir"
"${${result}_versioned_include_dir}/${${result}_include_name}")
set("${result}_private_include_dir"
"${${result}_versioned_inner_include_dir}/private")
Add qpa include directory to the return values of qt_internal_module_info Change-Id: I0540ce70e4a5dbde4027d97d9308c61248230c96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-21 17:42:23 +02:00
set("${result}_qpa_include_dir"
"${${result}_versioned_inner_include_dir}/qpa")
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
set("${result}_rhi_include_dir"
"${${result}_versioned_inner_include_dir}/rhi")
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
set("${result}_ssg_include_dir"
"${${result}_versioned_inner_include_dir}/ssg")
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
# Module build interface directories
set(repo_build_interface_include_dir "${QT_BUILD_DIR}/include")
set("${result}_build_interface_include_dir"
"${repo_build_interface_include_dir}/${${result}_include_name}")
set("${result}_build_interface_versioned_include_dir"
"${repo_build_interface_include_dir}/${${result}_versioned_include_dir}")
set("${result}_build_interface_versioned_inner_include_dir"
"${repo_build_interface_include_dir}/${${result}_versioned_inner_include_dir}")
set("${result}_build_interface_private_include_dir"
"${repo_build_interface_include_dir}/${${result}_private_include_dir}")
Add qpa include directory to the return values of qt_internal_module_info Change-Id: I0540ce70e4a5dbde4027d97d9308c61248230c96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-21 17:42:23 +02:00
set("${result}_build_interface_qpa_include_dir"
"${repo_build_interface_include_dir}/${${result}_qpa_include_dir}")
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
set("${result}_build_interface_rhi_include_dir"
"${repo_build_interface_include_dir}/${${result}_rhi_include_dir}")
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
set("${result}_build_interface_ssg_include_dir"
"${repo_build_interface_include_dir}/${${result}_ssg_include_dir}")
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
CMake: Fix typos Found by codespell Pick-to: 6.4 Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-10 16:41:59 +02:00
# Module install interface directories
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
set(repo_install_interface_include_dir "${INSTALL_INCLUDEDIR}")
set("${result}_install_interface_include_dir"
"${repo_install_interface_include_dir}/${${result}_include_name}")
set("${result}_install_interface_versioned_include_dir"
"${repo_install_interface_include_dir}/${${result}_versioned_include_dir}")
set("${result}_install_interface_versioned_inner_include_dir"
"${repo_install_interface_include_dir}/${${result}_versioned_inner_include_dir}")
set("${result}_install_interface_private_include_dir"
"${repo_install_interface_include_dir}/${${result}_private_include_dir}")
Add qpa include directory to the return values of qt_internal_module_info Change-Id: I0540ce70e4a5dbde4027d97d9308c61248230c96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-21 17:42:23 +02:00
set("${result}_install_interface_qpa_include_dir"
"${repo_install_interface_include_dir}/${${result}_qpa_include_dir}")
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
set("${result}_install_interface_rhi_include_dir"
"${repo_install_interface_include_dir}/${${result}_rhi_include_dir}")
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
set("${result}_install_interface_ssg_include_dir"
"${repo_install_interface_include_dir}/${${result}_ssg_include_dir}")
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
set("${result}" "${module}" PARENT_SCOPE)
Merge main and private targets of the internal modules In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-06 18:57:11 +02:00
set("${result}_versioned" "${module_versioned}" PARENT_SCOPE)
string(TOUPPER "${module_interface_name}" upper)
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
string(TOLOWER "${module_interface_name}" lower)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
set("${result}_upper" "${upper}" PARENT_SCOPE)
set("${result}_lower" "${lower}" PARENT_SCOPE)
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
set("${result}_include_name" "${${result}_include_name}" PARENT_SCOPE)
set("${result}_versioned_include_dir" "${${result}_versioned_include_dir}" PARENT_SCOPE)
set("${result}_versioned_inner_include_dir"
"${${result}_versioned_inner_include_dir}" PARENT_SCOPE)
set("${result}_private_include_dir" "${${result}_private_include_dir}" PARENT_SCOPE)
Add qpa include directory to the return values of qt_internal_module_info Change-Id: I0540ce70e4a5dbde4027d97d9308c61248230c96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-21 17:42:23 +02:00
set("${result}_qpa_include_dir" "${${result}_qpa_include_dir}" PARENT_SCOPE)
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
set("${result}_rhi_include_dir" "${${result}_rhi_include_dir}" PARENT_SCOPE)
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
set("${result}_ssg_include_dir" "${${result}_ssg_include_dir}" PARENT_SCOPE)
Use module interface name as OUTPUT_NAME For internal modules we should keep the name of the file in file system consistent with previous Qt versions. Pick-to: 6.2 Fixes: QTBUG-95077 Change-Id: I02e4fced0fc3172e60f07bc7d1515e23744db567 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-09 12:32:11 +02:00
set("${result}_interface_name" "${module_interface_name}" PARENT_SCOPE)
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
# Setting module build interface directories in parent scope
set(repo_build_interface_include_dir "${repo_build_interface_include_dir}" PARENT_SCOPE)
set("${result}_build_interface_include_dir"
"${${result}_build_interface_include_dir}" PARENT_SCOPE)
set("${result}_build_interface_versioned_include_dir"
"${${result}_build_interface_versioned_include_dir}" PARENT_SCOPE)
set("${result}_build_interface_versioned_inner_include_dir"
"${${result}_build_interface_versioned_inner_include_dir}" PARENT_SCOPE)
set("${result}_build_interface_private_include_dir"
"${${result}_build_interface_private_include_dir}" PARENT_SCOPE)
Add qpa include directory to the return values of qt_internal_module_info Change-Id: I0540ce70e4a5dbde4027d97d9308c61248230c96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-21 17:42:23 +02:00
set("${result}_build_interface_qpa_include_dir"
"${${result}_build_interface_qpa_include_dir}" PARENT_SCOPE)
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
set("${result}_build_interface_rhi_include_dir"
"${${result}_build_interface_rhi_include_dir}" PARENT_SCOPE)
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
set("${result}_build_interface_ssg_include_dir"
"${${result}_build_interface_ssg_include_dir}" PARENT_SCOPE)
Use correct module include name across the project Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-30 13:16:10 +02:00
# Setting module install interface directories in parent scope
set(repo_install_interface_include_dir "${repo_install_interface_include_dir}" PARENT_SCOPE)
set("${result}_install_interface_include_dir"
"${${result}_install_interface_include_dir}" PARENT_SCOPE)
set("${result}_install_interface_versioned_include_dir"
"${${result}_install_interface_versioned_include_dir}" PARENT_SCOPE)
set("${result}_install_interface_versioned_inner_include_dir"
"${${result}_install_interface_versioned_inner_include_dir}" PARENT_SCOPE)
set("${result}_install_interface_private_include_dir"
"${${result}_install_interface_private_include_dir}" PARENT_SCOPE)
Add qpa include directory to the return values of qt_internal_module_info Change-Id: I0540ce70e4a5dbde4027d97d9308c61248230c96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-21 17:42:23 +02:00
set("${result}_install_interface_qpa_include_dir"
"${${result}_install_interface_qpa_include_dir}" PARENT_SCOPE)
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
set("${result}_install_interface_rhi_include_dir"
"${${result}_install_interface_rhi_include_dir}" PARENT_SCOPE)
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
set("${result}_install_interface_ssg_include_dir"
"${${result}_install_interface_ssg_include_dir}" PARENT_SCOPE)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
endfunction()
CMake: Store the plugin types in the module json files This will be read by windeployqt. Pick-to: 6.5 Change-Id: I8dfebae755ef61967e924db3c5631af5cc4e2440 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-12-08 15:47:27 +01:00
function(qt_internal_list_to_json_array out_var list_var)
set(result "")
foreach(item IN LISTS ${list_var})
if(NOT "${result}" STREQUAL "")
string(APPEND result ", ")
endif()
string(APPEND result "\"${item}\"")
endforeach()
set("${out_var}" "[${result}]" PARENT_SCOPE)
endfunction()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
# Generate a module description file based on the template in ModuleDescription.json.in
function(qt_describe_module target)
set(path_suffix "${INSTALL_DESCRIPTIONSDIR}")
qt_path_join(build_dir ${QT_BUILD_DIR} ${path_suffix})
qt_path_join(install_dir ${QT_INSTALL_DIR} ${path_suffix})
set(descfile_in "${QT_CMAKE_DIR}/ModuleDescription.json.in")
CMake: Provide a way to find all available Qt module packages A project might want to find_package all available (installed) Qt CMake packages that contain qt modules. A use case might be a qml app that needs to link to all of Qt, and support showing qml files that can load any Qt qml module. Add a new Qt6 COMPONENT called ALL_QT_MODULES. It can be used like this: find_package(Qt6 COMPONENTS ALL_QT_MODULES). The implementation will find all installed Qt modules by globbing over all json files installed in $qt/modules dir, and treat the file names as package names. It will then tell Qt6 to find_package each of those packages. Pick-to: 6.8 6.9 Change-Id: I89242307438576a0cbb3cdca80a9cb72818b6035 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2025-01-23 19:29:17 +01:00
# IMPORTANT: If you adjust the file name not to be the exact target name and thus the CMake
# package name, it needs to consider also the code in QtConfig.cmake.in that globs the json
# files.
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
set(descfile_out "${build_dir}/${target}.json")
CMake: Provide a way to find all available Qt module packages A project might want to find_package all available (installed) Qt CMake packages that contain qt modules. A use case might be a qml app that needs to link to all of Qt, and support showing qml files that can load any Qt qml module. Add a new Qt6 COMPONENT called ALL_QT_MODULES. It can be used like this: find_package(Qt6 COMPONENTS ALL_QT_MODULES). The implementation will find all installed Qt modules by globbing over all json files installed in $qt/modules dir, and treat the file names as package names. It will then tell Qt6 to find_package each of those packages. Pick-to: 6.8 6.9 Change-Id: I89242307438576a0cbb3cdca80a9cb72818b6035 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2025-01-23 19:29:17 +01:00
CMake: Store the plugin types in the module json files This will be read by windeployqt. Pick-to: 6.5 Change-Id: I8dfebae755ef61967e924db3c5631af5cc4e2440 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-12-08 15:47:27 +01:00
string(TOLOWER "${PROJECT_NAME}" lower_case_project_name)
set(extra_module_information "")
CMake: Rework the module JSON files The linked issue reports a lack of information about multi-arch builds of Qt on Apple platforms. In order to add the information we take the chance to rework the structure of the module JSON files and make the format future-proof for when we'll create multi-platform bundles (xcframeworks). The new module JSON files differ from the old ones in the following points: - The 'schema_version' key denotes the version of the module JSON file schema. It's set to 2. - The 'built_with' key was removed. The relevant information was moved to 'platforms' entries. - The 'cross_compiled' key was removed. It was only used to determine whether a Qt build contained host tools. Since one needs the actual path to host tools anyway, it's more useful to query qtpaths for that information. - A 'platforms' key was added that holds a list of target platforms. Currently, only an iOS simulator-and-device build has more than one platform: "name": "iOS", "variant": "iphoneos", and "name": "iOS", "variant": "iphonesimulator", - A 'targets' key was added under each 'platforms' entry. This contains information about the target architecture(s) and other relevant properties. - The 'android' key was flattened and moved to the 'targets' entries. [ChangeLog][CMake] The structure of the module JSON files, e.g. modules/Core.json has been reworked. Consumers of these files need to be updated. A 'schema_version' key was added and set to 2 to ease reading different versions of these files. Fixes: QTBUG-129996 Change-Id: I5a6ac9746aa19ad0ee9f2d020bf7486bdac28226 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-11-06 14:35:25 +01:00
set(platforms_information "")
CMake: Store the plugin types in the module json files This will be read by windeployqt. Pick-to: 6.5 Change-Id: I8dfebae755ef61967e924db3c5631af5cc4e2440 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-12-08 15:47:27 +01:00
get_target_property(target_type ${target} TYPE)
if(NOT target_type STREQUAL "INTERFACE_LIBRARY")
CMake: Store unsanitized plugin type names in module .json files The module information .json gained a "plugin_types" key in 6.5.0. Unfortunately, this contained the "sanitized" version of plugin types, meaning dashes converted to underscores. For plugin types that contain dashes, e.g. wayland-decoration-client, the file contained wayland_decoration_client, which doesn't match its plugin directory name. Since "unsanitizing" plugin names is hard and "sanitizing" is easy, we now store the unsanitized plugin names and burden the consumer of the module .json files with the sanitation task. [ChangeLog][CMake] The module information JSON files now contain the unsanitized plugin types of a module, e.g. wayland-decoration-client instead of wayland_decoration_client. Consumers of the module information file must sanitize plugin types themselves if necessary. Pick-to: 6.5 Fixes: QTBUG-112872 Change-Id: I09cc9406b360779087086707abee3d5219a24452 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-04-14 15:23:05 +02:00
get_target_property(plugin_types ${target} QMAKE_MODULE_PLUGIN_TYPES)
CMake: Store the plugin types in the module json files This will be read by windeployqt. Pick-to: 6.5 Change-Id: I8dfebae755ef61967e924db3c5631af5cc4e2440 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-12-08 15:47:27 +01:00
if(plugin_types)
qt_internal_list_to_json_array(plugin_types plugin_types)
string(APPEND extra_module_information "\n \"plugin_types\": ${plugin_types},")
endif()
endif()
CMake: Rework the module JSON files The linked issue reports a lack of information about multi-arch builds of Qt on Apple platforms. In order to add the information we take the chance to rework the structure of the module JSON files and make the format future-proof for when we'll create multi-platform bundles (xcframeworks). The new module JSON files differ from the old ones in the following points: - The 'schema_version' key denotes the version of the module JSON file schema. It's set to 2. - The 'built_with' key was removed. The relevant information was moved to 'platforms' entries. - The 'cross_compiled' key was removed. It was only used to determine whether a Qt build contained host tools. Since one needs the actual path to host tools anyway, it's more useful to query qtpaths for that information. - A 'platforms' key was added that holds a list of target platforms. Currently, only an iOS simulator-and-device build has more than one platform: "name": "iOS", "variant": "iphoneos", and "name": "iOS", "variant": "iphonesimulator", - A 'targets' key was added under each 'platforms' entry. This contains information about the target architecture(s) and other relevant properties. - The 'android' key was flattened and moved to the 'targets' entries. [ChangeLog][CMake] The structure of the module JSON files, e.g. modules/Core.json has been reworked. Consumers of these files need to be updated. A 'schema_version' key was added and set to 2 to ease reading different versions of these files. Fixes: QTBUG-129996 Change-Id: I5a6ac9746aa19ad0ee9f2d020bf7486bdac28226 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-11-06 14:35:25 +01:00
# Generate extra module information
CMake: Store whether a module is internal in module json files Pick-to: 6.5 Change-Id: Ic7e5e3b69a41a7723643332bebbde76854966b89 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
2022-12-09 17:05:09 +01:00
get_target_property(is_internal ${target} _qt_is_internal_module)
if(is_internal)
string(APPEND extra_module_information "\n \"internal\": true,")
endif()
CMake: Rework the module JSON files The linked issue reports a lack of information about multi-arch builds of Qt on Apple platforms. In order to add the information we take the chance to rework the structure of the module JSON files and make the format future-proof for when we'll create multi-platform bundles (xcframeworks). The new module JSON files differ from the old ones in the following points: - The 'schema_version' key denotes the version of the module JSON file schema. It's set to 2. - The 'built_with' key was removed. The relevant information was moved to 'platforms' entries. - The 'cross_compiled' key was removed. It was only used to determine whether a Qt build contained host tools. Since one needs the actual path to host tools anyway, it's more useful to query qtpaths for that information. - A 'platforms' key was added that holds a list of target platforms. Currently, only an iOS simulator-and-device build has more than one platform: "name": "iOS", "variant": "iphoneos", and "name": "iOS", "variant": "iphonesimulator", - A 'targets' key was added under each 'platforms' entry. This contains information about the target architecture(s) and other relevant properties. - The 'android' key was flattened and moved to the 'targets' entries. [ChangeLog][CMake] The structure of the module JSON files, e.g. modules/Core.json has been reworked. Consumers of these files need to be updated. A 'schema_version' key was added and set to 2 to ease reading different versions of these files. Fixes: QTBUG-129996 Change-Id: I5a6ac9746aa19ad0ee9f2d020bf7486bdac28226 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-11-06 14:35:25 +01:00
if(APPLE)
set(bundle_type "none")
if(QT_FEATURE_framework)
set(bundle_type "framework")
endif()
string(APPEND extra_module_information "\n \"bundle_type\": \"framework\",")
endif()
CMake: Write Qt's namespace into module info JSON files If Qt was configure with QT_NAMESPACE set, store that in the module information files under 'built_with.namespace'. Task-number: QTBUG-111158 Change-Id: I273309cb263c64f801dbb7238440336d7afa635e Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-17 17:04:39 +01:00
if(NOT QT_NAMESPACE STREQUAL "")
CMake: Rework the module JSON files The linked issue reports a lack of information about multi-arch builds of Qt on Apple platforms. In order to add the information we take the chance to rework the structure of the module JSON files and make the format future-proof for when we'll create multi-platform bundles (xcframeworks). The new module JSON files differ from the old ones in the following points: - The 'schema_version' key denotes the version of the module JSON file schema. It's set to 2. - The 'built_with' key was removed. The relevant information was moved to 'platforms' entries. - The 'cross_compiled' key was removed. It was only used to determine whether a Qt build contained host tools. Since one needs the actual path to host tools anyway, it's more useful to query qtpaths for that information. - A 'platforms' key was added that holds a list of target platforms. Currently, only an iOS simulator-and-device build has more than one platform: "name": "iOS", "variant": "iphoneos", and "name": "iOS", "variant": "iphonesimulator", - A 'targets' key was added under each 'platforms' entry. This contains information about the target architecture(s) and other relevant properties. - The 'android' key was flattened and moved to the 'targets' entries. [ChangeLog][CMake] The structure of the module JSON files, e.g. modules/Core.json has been reworked. Consumers of these files need to be updated. A 'schema_version' key was added and set to 2 to ease reading different versions of these files. Fixes: QTBUG-129996 Change-Id: I5a6ac9746aa19ad0ee9f2d020bf7486bdac28226 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-11-06 14:35:25 +01:00
string(APPEND extra_module_information "\n \"namespace\": \"${QT_NAMESPACE}\",")
CMake: Write Qt's namespace into module info JSON files If Qt was configure with QT_NAMESPACE set, store that in the module information files under 'built_with.namespace'. Task-number: QTBUG-111158 Change-Id: I273309cb263c64f801dbb7238440336d7afa635e Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-17 17:04:39 +01:00
endif()
CMake: Add QPA information to modules/Gui.json The list of available QPA platforms and the default QPA platform is now available in modules/Gui.json. Change-Id: I059286d80c8507080d5ec3d790cf8ea22c5daddd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-11-06 15:30:45 +01:00
if(target STREQUAL "Gui")
qt_internal_list_to_json_array(qpa_platforms_array QT_QPA_PLATFORMS)
string(APPEND extra_module_information "
\"qpa\": {
\"platforms\": ${qpa_platforms_array},
\"default_platform\": \"${QT_QPA_DEFAULT_PLATFORM}\"
},")
endif()
CMake: Rework the module JSON files The linked issue reports a lack of information about multi-arch builds of Qt on Apple platforms. In order to add the information we take the chance to rework the structure of the module JSON files and make the format future-proof for when we'll create multi-platform bundles (xcframeworks). The new module JSON files differ from the old ones in the following points: - The 'schema_version' key denotes the version of the module JSON file schema. It's set to 2. - The 'built_with' key was removed. The relevant information was moved to 'platforms' entries. - The 'cross_compiled' key was removed. It was only used to determine whether a Qt build contained host tools. Since one needs the actual path to host tools anyway, it's more useful to query qtpaths for that information. - A 'platforms' key was added that holds a list of target platforms. Currently, only an iOS simulator-and-device build has more than one platform: "name": "iOS", "variant": "iphoneos", and "name": "iOS", "variant": "iphonesimulator", - A 'targets' key was added under each 'platforms' entry. This contains information about the target architecture(s) and other relevant properties. - The 'android' key was flattened and moved to the 'targets' entries. [ChangeLog][CMake] The structure of the module JSON files, e.g. modules/Core.json has been reworked. Consumers of these files need to be updated. A 'schema_version' key was added and set to 2 to ease reading different versions of these files. Fixes: QTBUG-129996 Change-Id: I5a6ac9746aa19ad0ee9f2d020bf7486bdac28226 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-11-06 14:35:25 +01:00
# Set up indentation helper variables.
set(indent1 " ")
set(k 1)
foreach(i RANGE 2 5)
set(indent${i} "${indent${k}}${indent1}")
set(k ${i})
endforeach()
# Set up the platforms to write.
set(nr_of_platforms 1)
set(platform_0_name "${CMAKE_SYSTEM_NAME}")
set(platform_0_variant "")
set(platform_0_architectures "${TEST_architecture_architectures}")
# Handle iOS builds specially.
if(platform_0_name STREQUAL "iOS")
if(QT_FEATURE_simulator_and_device)
# This must match the setup done in qt_auto_detect_apple.
set(nr_of_platforms 2)
set(platform_0_name "iOS")
set(platform_0_variant "iphoneos")
set(platform_0_architectures "arm64")
set(platform_1_name "iOS")
set(platform_1_variant "iphonesimulator")
set(platform_1_architectures "x86_64")
elseif(NOT "${QT_APPLE_SDK}" STREQUAL "")
# Explicit SDK requested.
set(platform_0_variant "${QT_APPLE_SDK}")
endif()
CMake: Add Android build information to generated module .json files Qt Creator maintains a mapping from Qt version to Android NDK version and other build information. It's simpler to let the Qt build write the Android build information into modules/Core.json and have Qt Creator use this information. This adds the following properties to the module JSON files: - built_with.android.api_version - built_with.android.ndk.version Task-number: QTBUG-108292 Change-Id: I0febda5192289c5afb1a098880b31bef6317db35 Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-12-06 16:12:12 +01:00
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
CMake: Rework the module JSON files The linked issue reports a lack of information about multi-arch builds of Qt on Apple platforms. In order to add the information we take the chance to rework the structure of the module JSON files and make the format future-proof for when we'll create multi-platform bundles (xcframeworks). The new module JSON files differ from the old ones in the following points: - The 'schema_version' key denotes the version of the module JSON file schema. It's set to 2. - The 'built_with' key was removed. The relevant information was moved to 'platforms' entries. - The 'cross_compiled' key was removed. It was only used to determine whether a Qt build contained host tools. Since one needs the actual path to host tools anyway, it's more useful to query qtpaths for that information. - A 'platforms' key was added that holds a list of target platforms. Currently, only an iOS simulator-and-device build has more than one platform: "name": "iOS", "variant": "iphoneos", and "name": "iOS", "variant": "iphonesimulator", - A 'targets' key was added under each 'platforms' entry. This contains information about the target architecture(s) and other relevant properties. - The 'android' key was flattened and moved to the 'targets' entries. [ChangeLog][CMake] The structure of the module JSON files, e.g. modules/Core.json has been reworked. Consumers of these files need to be updated. A 'schema_version' key was added and set to 2 to ease reading different versions of these files. Fixes: QTBUG-129996 Change-Id: I5a6ac9746aa19ad0ee9f2d020bf7486bdac28226 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2024-11-06 14:35:25 +01:00
# Write platform information. At the moment, we write exactly one platform. With xcframeworks
# for example, we'd support multiple platforms.
math(EXPR last_platform_idx "${nr_of_platforms} - 1")
foreach(i RANGE 0 ${last_platform_idx})
# Write target architecture information.
set(platform_name "${platform_${i}_name}")
set(platform_variant "${platform_${i}_variant}")
set(platform_architectures "${platform_${i}_architectures}")
set(targets_information "")
foreach(architecture IN LISTS platform_architectures)
if(NOT targets_information STREQUAL "")
string(APPEND targets_information ",")
endif()
string(APPEND targets_information "\n${indent4}{\n")
if(NOT QT_FEATURE_shared)
string(APPEND targets_information "${indent5}\"static\": true,\n")
endif()
if(ANDROID)
string(APPEND targets_information
"${indent5}\"api_version\": \"${QT_ANDROID_API_USED_FOR_JAVA}\",
${indent5}\"ndk_version\": \"${ANDROID_NDK_REVISION}\",\n")
endif()
string(APPEND targets_information "${indent5}\"architecture\": \"${architecture}\",\n")
string(APPEND targets_information "${indent5}\"abi\": \"${TEST_arch_${architecture}_abi}\"\n")
string(APPEND targets_information "${indent4}}")
endforeach()
if(i GREATER 0)
string(APPEND platforms_information ",")
endif()
string(APPEND platforms_information "
${indent2}{
${indent3}\"name\": \"${platform_name}\",")
if(NOT platform_variant STREQUAL "")
string(APPEND platforms_information "
${indent3}\"variant\": \"${platform_variant}\",")
endif()
if(NOT "${CMAKE_SYSTEM_VERSION}" STREQUAL "")
string(APPEND platforms_information "
${indent3}\"version\": \"${CMAKE_SYSTEM_VERSION}\",")
endif()
string(APPEND platforms_information "
${indent3}\"compiler_id\": \"${CMAKE_CXX_COMPILER_ID}\",
${indent3}\"compiler_version\": \"${CMAKE_CXX_COMPILER_VERSION}\",
${indent3}\"targets\": [${targets_information}
${indent3}]
${indent2}}")
endforeach()
configure_file("${descfile_in}" "${descfile_out}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 17:37:47 +02:00
qt_install(FILES "${descfile_out}" DESTINATION "${install_dir}")
endfunction()
Implement generating of a module cpp export header Add an option that automatically generates an export header for a Qt module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related content, so it's not a full replacement of 'global' header files. Task-number: QTBUG-90492 Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-22 17:37:55 +02:00
Add explicit install rules for the autogenerated cpp exports If qt_internal_generate_cpp_global_exports is called outside the qt_internall_add_module function scope, install rule that is generated by qt_internall_add_module won't include generated cpp export header files. This adds the explicit file-based install rule for the generated cpp exports. Since qt_internal_generate_cpp_global_exports now encapsulates all install rules related to the generated cpp exports, no need to expose the generated filenames outside the function. It's expected that module public headers now could be added outside the qt_internal_add_module function. Tune generating of the module timestamp by replacing the DEPENDS value with generator expression. Task-number: QTBUG-90492 Change-Id: I0f086abc8187c5d51117c3a75c47b58580f6913f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-14 17:45:22 +02:00
function(qt_internal_generate_cpp_global_exports target module_define_infix)
Implement generating of a module cpp export header Add an option that automatically generates an export header for a Qt module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related content, so it's not a full replacement of 'global' header files. Task-number: QTBUG-90492 Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-22 17:37:55 +02:00
cmake_parse_arguments(arg
Avoid generating private cpp exports Ignore GENERATE_PRIVATE_CPP_EXPORTS argument of qt_internal_add_module. Task-number: QTBUG-117983 Change-Id: I03a443cb575628f3225b944316507a033d262894 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-11-23 12:13:02 +01:00
""
Expose cpp export related arguments for qt_internal_add_module users Functions that use qt_internal_add_module under the hood might need to generate cpp exports, e.g. qt_internal_add_qml_module. Append cpp exports related arguments to the qt_internal_add_module arguments set. Task-number: QTBUG-90492 Change-Id: I4fd539bd1d8be4d3e57ed5b1b88dd2dbc2f5ca24 Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-09-10 17:24:43 +02:00
"CPP_EXPORT_HEADER_BASE_NAME"
"" ${ARGN}
Implement generating of private cpp exports Add the generating of private cpp exports for Qt modules. Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module that is the manual switch for private exports generator. Existing modules in qtbase doesn't follow any strict convention of using private cpp export. So there is no clue how to detect if generating of the private exports is required or not for the module. Use autogenerated private cpp exports in QtNetwork module. CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different meaning. The provided name is used as a base name for the private and non-private headers that contains cpp exports. Header files suffixes are constant: .h and _p.h for the non-private and private header files accordingly. Pick-to: 6.2 Task-number: QTBUG-90492 Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-30 17:51:07 +02:00
)
Implement generating of a module cpp export header Add an option that automatically generates an export header for a Qt module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related content, so it's not a full replacement of 'global' header files. Task-number: QTBUG-90492 Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-22 17:37:55 +02:00
qt_internal_module_info(module "${target}")
Implement generating of private cpp exports Add the generating of private cpp exports for Qt modules. Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module that is the manual switch for private exports generator. Existing modules in qtbase doesn't follow any strict convention of using private cpp export. So there is no clue how to detect if generating of the private exports is required or not for the module. Use autogenerated private cpp exports in QtNetwork module. CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different meaning. The provided name is used as a base name for the private and non-private headers that contains cpp exports. Header files suffixes are constant: .h and _p.h for the non-private and private header files accordingly. Pick-to: 6.2 Task-number: QTBUG-90492 Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-30 17:51:07 +02:00
set(header_base_name "qt${module_lower}exports")
if(arg_CPP_EXPORT_HEADER_BASE_NAME)
set(header_base_name "${arg_CPP_EXPORT_HEADER_BASE_NAME}")
Implement generating of a module cpp export header Add an option that automatically generates an export header for a Qt module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related content, so it's not a full replacement of 'global' header files. Task-number: QTBUG-90492 Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-22 17:37:55 +02:00
endif()
Implement generating of private cpp exports Add the generating of private cpp exports for Qt modules. Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module that is the manual switch for private exports generator. Existing modules in qtbase doesn't follow any strict convention of using private cpp export. So there is no clue how to detect if generating of the private exports is required or not for the module. Use autogenerated private cpp exports in QtNetwork module. CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different meaning. The provided name is used as a base name for the private and non-private headers that contains cpp exports. Header files suffixes are constant: .h and _p.h for the non-private and private header files accordingly. Pick-to: 6.2 Task-number: QTBUG-90492 Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-30 17:51:07 +02:00
# Is used as a part of the header guard define.
string(TOUPPER "${header_base_name}" header_base_name_upper)
Implement generating of a module cpp export header Add an option that automatically generates an export header for a Qt module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related content, so it's not a full replacement of 'global' header files. Task-number: QTBUG-90492 Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-22 17:37:55 +02:00
set(generated_header_path
Implement generating of private cpp exports Add the generating of private cpp exports for Qt modules. Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module that is the manual switch for private exports generator. Existing modules in qtbase doesn't follow any strict convention of using private cpp export. So there is no clue how to detect if generating of the private exports is required or not for the module. Use autogenerated private cpp exports in QtNetwork module. CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different meaning. The provided name is used as a base name for the private and non-private headers that contains cpp exports. Header files suffixes are constant: .h and _p.h for the non-private and private header files accordingly. Pick-to: 6.2 Task-number: QTBUG-90492 Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-30 17:51:07 +02:00
"${module_build_interface_include_dir}/${header_base_name}.h"
Implement generating of a module cpp export header Add an option that automatically generates an export header for a Qt module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related content, so it's not a full replacement of 'global' header files. Task-number: QTBUG-90492 Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-22 17:37:55 +02:00
)
configure_file("${QT_CMAKE_DIR}/modulecppexports.h.in"
"${generated_header_path}" @ONLY
)
Implement generating of private cpp exports Add the generating of private cpp exports for Qt modules. Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module that is the manual switch for private exports generator. Existing modules in qtbase doesn't follow any strict convention of using private cpp export. So there is no clue how to detect if generating of the private exports is required or not for the module. Use autogenerated private cpp exports in QtNetwork module. CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different meaning. The provided name is used as a base name for the private and non-private headers that contains cpp exports. Header files suffixes are constant: .h and _p.h for the non-private and private header files accordingly. Pick-to: 6.2 Task-number: QTBUG-90492 Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-30 17:51:07 +02:00
set(${out_public_header} "${generated_header_path}" PARENT_SCOPE)
Implement generating of a module cpp export header Add an option that automatically generates an export header for a Qt module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related content, so it's not a full replacement of 'global' header files. Task-number: QTBUG-90492 Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-22 17:37:55 +02:00
target_sources(${target} PRIVATE "${generated_header_path}")
Use `_qt_internal_set_source_file_generated` Migrate implementations that set `GENERATED` source property Task-number: QTBUG-125077 Pick-to: 6.9 Change-Id: Ia77ecf8422bf3983f7746c26e5a9994d1f6415f2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-01-06 19:08:39 +01:00
_qt_internal_set_source_file_generated(
SOURCES "${generated_header_path}"
CONFIGURE_GENERATED
)
Change the `GENERATED` property of module export header Use a more specific property Change-Id: I68702fd66902273b108f7f207f583f73693087ed Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-02-04 14:01:24 +01:00
# Make sure the file is installed when processed by `qt_internal_collect_module_headers`
set_source_files_properties("${generated_header_path}" PROPERTIES _qt_syncqt_force_include TRUE)
Implement generating of a module cpp export header Add an option that automatically generates an export header for a Qt module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related content, so it's not a full replacement of 'global' header files. Task-number: QTBUG-90492 Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-22 17:37:55 +02:00
endfunction()
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
function(qt_internal_install_module_headers target)
set(options)
set(one_value_args)
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
set(multi_value_args PUBLIC PRIVATE QPA RHI SSG)
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
cmake_parse_arguments(arg "${options}" "${one_value_args}" "${multi_value_args}" ${ARGN})
qt_internal_module_info(module ${target})
get_target_property(target_type ${target} TYPE)
set(is_interface_lib FALSE)
if(target_type STREQUAL "INTERFACE_LIBRARY")
set(is_interface_lib TRUE)
else()
get_target_property(is_framework ${target} FRAMEWORK)
endif()
foreach(header_type IN LISTS multi_value_args)
if(NOT arg_${header_type})
set(arg_${header_type} "")
endif()
endforeach()
if(is_framework)
qt_copy_framework_headers(${target}
PUBLIC ${arg_PUBLIC}
PRIVATE ${arg_PRIVATE}
QPA ${arg_QPA}
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
RHI ${arg_RHI}
Fix installation of the SSG headers for framework builds The QtQuick3D semi-public headers were not installed correctly due to a typo in QtModuleHelpers. This amends 9c3c87f6d0d5c70b9 Change-Id: Iec6ed4e1785fbb1189385104f476c37481ef47fb Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
2023-10-10 14:47:13 +02:00
SSG ${arg_SSG}
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
)
else()
if(arg_PUBLIC)
qt_install(FILES ${arg_PUBLIC}
DESTINATION "${module_install_interface_include_dir}")
endif()
if(arg_PRIVATE)
qt_install(FILES ${arg_PRIVATE}
DESTINATION "${module_install_interface_private_include_dir}")
endif()
Replace the syncqt.pl script with syncqt tool 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 <alexandru.croitor@qt.io>
2022-08-15 18:29:41 +02:00
if(arg_QPA)
qt_install(FILES ${arg_QPA} DESTINATION "${module_install_interface_qpa_include_dir}")
endif()
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
if(arg_RHI)
qt_install(FILES ${arg_RHI} DESTINATION "${module_install_interface_rhi_include_dir}")
endif()
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
if(arg_SSG)
qt_install(FILES ${arg_SSG} DESTINATION "${module_install_interface_ssg_include_dir}")
endif()
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
endif()
endfunction()
function(qt_internal_collect_module_headers out_var target)
set(${out_var}_public "")
set(${out_var}_private "")
CMake: Fix dbus and vk headers to be excluded from doc generation Before this change, if someone called ninja Gui_generate_docs, it would implicitly depend on sync_all_public_headers -> Gui_sync_headers which would generate dbus headers. This caused trouble with the new 'build doc tools from qttools/dev/HEAD' approach, because an older pre-built dbus tool might be passed a newer option when integrating a qtbase change that passes the new option. To avoid that, we now filter out the dbus headers from the list of headers that should be processed by syncqt when building a documentation target. We do the same for the qvkgen generated headers. This also removes the dependency on the ${target}_sync_headers target, which means there is a potential issue when someone manually calls `ninja sync_all_public_headers Gui_sync_headers` or something like it, which would spawn two syncqt processes that access the same files concurrently. This is an edge case that should not happen, but if it ends up happening, we will have to implement some kind of lock file mechanism. Pick-to: 6.8 6.9 Fixes: QTBUG-134672 Task-number: QTBUG-128730 Change-Id: I9061f9495e2faa77744f5f5c0de8fedd362ba228 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-03-20 15:39:02 +01:00
set(${out_var}_exclude_from_docs "")
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
set(${out_var}_qpa "")
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
set(${out_var}_rhi "")
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
set(${out_var}_ssg "")
Replace the syncqt.pl script with syncqt tool 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 <alexandru.croitor@qt.io>
2022-08-15 18:29:41 +02:00
set(${out_var}_all "")
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
qt_internal_get_target_sources(sources ${target})
Avoid syncing and installation of non-module headers Add CMake rules to skip syncing and installation of header files that are recognized as non-module. Previously these rules were in syncqt.cpp only and CMake ignored them when creating the installation rules. Now we skip any post processing for the header files that: - are public and located in the '3rdparty' directory unless the module is the 3rdparty one - are not a part of the module source tree unless they are generated - have the _qt_non_module_header property set to TRUE Pick-to: 6.5 Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-30 16:54:49 +02:00
get_target_property(target_type ${target} TYPE)
if(target_type STREQUAL "INTERFACE_LIBRARY")
set(source_dir "${CMAKE_CURRENT_SOURCE_DIR}")
Use the relative header path when checking if it's 3rdparty If source or build directry contain '3rdparty' in their path, all header files are marked as 3rdparty and will never be installed. This commit is CMake counterpart of ea4a3d78a776e10955caf6cf9b1054ddb50f40d3 Amends ea4a3d78a776e10955caf6cf9b1054ddb50f40d3 Fixes: QTBUG-116137 Pick-to: 6.5 6.6 Change-Id: Ib93fb879867e3aeb6e44193c4253e73173c141d2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-16 17:01:23 +02:00
set(binary_dir "${CMAKE_CURRENT_BINARY_DIR}")
Avoid syncing and installation of non-module headers Add CMake rules to skip syncing and installation of header files that are recognized as non-module. Previously these rules were in syncqt.cpp only and CMake ignored them when creating the installation rules. Now we skip any post processing for the header files that: - are public and located in the '3rdparty' directory unless the module is the 3rdparty one - are not a part of the module source tree unless they are generated - have the _qt_non_module_header property set to TRUE Pick-to: 6.5 Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-30 16:54:49 +02:00
else()
get_target_property(source_dir ${target} SOURCE_DIR)
Use the relative header path when checking if it's 3rdparty If source or build directry contain '3rdparty' in their path, all header files are marked as 3rdparty and will never be installed. This commit is CMake counterpart of ea4a3d78a776e10955caf6cf9b1054ddb50f40d3 Amends ea4a3d78a776e10955caf6cf9b1054ddb50f40d3 Fixes: QTBUG-116137 Pick-to: 6.5 6.6 Change-Id: Ib93fb879867e3aeb6e44193c4253e73173c141d2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-16 17:01:23 +02:00
get_target_property(binary_dir ${target} BINARY_DIR)
Avoid syncing and installation of non-module headers Add CMake rules to skip syncing and installation of header files that are recognized as non-module. Previously these rules were in syncqt.cpp only and CMake ignored them when creating the installation rules. Now we skip any post processing for the header files that: - are public and located in the '3rdparty' directory unless the module is the 3rdparty one - are not a part of the module source tree unless they are generated - have the _qt_non_module_header property set to TRUE Pick-to: 6.5 Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-30 16:54:49 +02:00
endif()
get_filename_component(source_dir "${source_dir}" ABSOLUTE)
Use the relative header path when checking if it's 3rdparty If source or build directry contain '3rdparty' in their path, all header files are marked as 3rdparty and will never be installed. This commit is CMake counterpart of ea4a3d78a776e10955caf6cf9b1054ddb50f40d3 Amends ea4a3d78a776e10955caf6cf9b1054ddb50f40d3 Fixes: QTBUG-116137 Pick-to: 6.5 6.6 Change-Id: Ib93fb879867e3aeb6e44193c4253e73173c141d2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-16 17:01:23 +02:00
get_filename_component(binary_dir "${binary_dir}" ABSOLUTE)
Avoid syncing and installation of non-module headers Add CMake rules to skip syncing and installation of header files that are recognized as non-module. Previously these rules were in syncqt.cpp only and CMake ignored them when creating the installation rules. Now we skip any post processing for the header files that: - are public and located in the '3rdparty' directory unless the module is the 3rdparty one - are not a part of the module source tree unless they are generated - have the _qt_non_module_header property set to TRUE Pick-to: 6.5 Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-30 16:54:49 +02:00
get_target_property(is_3rdparty_library ${target} _qt_module_is_3rdparty_header_library)
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
get_target_property(public_filter ${target} _qt_module_public_headers_filter_regex)
get_target_property(private_filter ${target} _qt_module_private_headers_filter_regex)
get_target_property(qpa_filter ${target} _qt_module_qpa_headers_filter_regex)
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
get_target_property(rhi_filter ${target} _qt_module_rhi_headers_filter_regex)
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
get_target_property(ssg_filter ${target} _qt_module_ssg_headers_filter_regex)
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
Add CONDITION_INDEPENDENT_SOURCES argument to qt_internal_extend_target The argument allows to ignore the condition for source files if they are used in the Qt code without corresponding guards. The header files of this kind usually have internal guards, that suppress the error at the location where they are used, so AUTOGEN is skipped for these header files to suppress the warnings from CMake. If file belongs to a module, it will display AUTHOR_WARNING which should urge Qt maintainers to guard the use of the source file properly. Task-number: QTBUG-103196 Change-Id: I7b4c12031a5d19ff15868d4782c0d396ef7aed8c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-11-03 16:38:51 +01:00
set(condition_independent_headers_warning "")
Avoid the 'file' command shadowing Avoid the 'file' command shadowing by a variable and use file name when filtering header files by type. Amends 8539e641f6f48a605547f66c47266d19e537f74e Task-number: QTBUG-103196 Change-Id: If012975efafaf119cffbd89baf84df334bc057ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-09-21 13:30:37 +02:00
foreach(file_path IN LISTS sources)
get_filename_component(file_name "${file_path}" NAME)
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
if(NOT file_name MATCHES ".+\\.h$")
continue()
endif()
Avoid syncing and installation of non-module headers Add CMake rules to skip syncing and installation of header files that are recognized as non-module. Previously these rules were in syncqt.cpp only and CMake ignored them when creating the installation rules. Now we skip any post processing for the header files that: - are public and located in the '3rdparty' directory unless the module is the 3rdparty one - are not a part of the module source tree unless they are generated - have the _qt_non_module_header property set to TRUE Pick-to: 6.5 Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-30 16:54:49 +02:00
get_source_file_property(non_module_header ${file_path} _qt_non_module_header)
if(non_module_header)
continue()
endif()
get_filename_component(file_path "${file_path}" ABSOLUTE)
Use `_qt_internal_path_is_prefix` Change-Id: I3eeb514c33340956328eff33409dfa2899023eb5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-02-04 13:56:23 +01:00
_qt_internal_path_is_prefix(source_dir "${file_path}" is_inside_module_source_dir)
Avoid syncing and installation of non-module headers Add CMake rules to skip syncing and installation of header files that are recognized as non-module. Previously these rules were in syncqt.cpp only and CMake ignored them when creating the installation rules. Now we skip any post processing for the header files that: - are public and located in the '3rdparty' directory unless the module is the 3rdparty one - are not a part of the module source tree unless they are generated - have the _qt_non_module_header property set to TRUE Pick-to: 6.5 Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-30 16:54:49 +02:00
Change the `GENERATED` property of module export header Use a more specific property Change-Id: I68702fd66902273b108f7f207f583f73693087ed Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-02-04 14:01:24 +01:00
get_source_file_property(forced_include "${file_path}" _qt_syncqt_force_include)
Avoid syncing and installation of non-module headers Add CMake rules to skip syncing and installation of header files that are recognized as non-module. Previously these rules were in syncqt.cpp only and CMake ignored them when creating the installation rules. Now we skip any post processing for the header files that: - are public and located in the '3rdparty' directory unless the module is the 3rdparty one - are not a part of the module source tree unless they are generated - have the _qt_non_module_header property set to TRUE Pick-to: 6.5 Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-30 16:54:49 +02:00
get_source_file_property(is_generated "${file_path}" GENERATED)
Change the `GENERATED` property of module export header Use a more specific property Change-Id: I68702fd66902273b108f7f207f583f73693087ed Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-02-04 14:01:24 +01:00
# Skip all header files outside the module source directory, except the generated files,
# or files explicitly marked to be included for syncqt.
if(NOT (forced_include OR is_inside_module_source_dir OR is_generated))
Avoid syncing and installation of non-module headers Add CMake rules to skip syncing and installation of header files that are recognized as non-module. Previously these rules were in syncqt.cpp only and CMake ignored them when creating the installation rules. Now we skip any post processing for the header files that: - are public and located in the '3rdparty' directory unless the module is the 3rdparty one - are not a part of the module source tree unless they are generated - have the _qt_non_module_header property set to TRUE Pick-to: 6.5 Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-30 16:54:49 +02:00
continue()
endif()
Add CONDITION_INDEPENDENT_SOURCES argument to qt_internal_extend_target The argument allows to ignore the condition for source files if they are used in the Qt code without corresponding guards. The header files of this kind usually have internal guards, that suppress the error at the location where they are used, so AUTOGEN is skipped for these header files to suppress the warnings from CMake. If file belongs to a module, it will display AUTHOR_WARNING which should urge Qt maintainers to guard the use of the source file properly. Task-number: QTBUG-103196 Change-Id: I7b4c12031a5d19ff15868d4782c0d396ef7aed8c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-11-03 16:38:51 +01:00
get_source_file_property(condition ${file_path} _qt_extend_target_condition)
if(NOT condition STREQUAL "" AND NOT condition STREQUAL "NOTFOUND")
list(JOIN condition " " condition_string)
string(APPEND condition_independent_headers_warning
"\nFile:\n ${file_path}"
"\nCondition:\n ${condition_string}")
endif()
Use `_qt_internal_path_is_prefix` Change-Id: I3eeb514c33340956328eff33409dfa2899023eb5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-02-04 13:56:23 +01:00
if(is_inside_module_source_dir)
Use the relative header path when checking if it's 3rdparty If source or build directry contain '3rdparty' in their path, all header files are marked as 3rdparty and will never be installed. This commit is CMake counterpart of ea4a3d78a776e10955caf6cf9b1054ddb50f40d3 Amends ea4a3d78a776e10955caf6cf9b1054ddb50f40d3 Fixes: QTBUG-116137 Pick-to: 6.5 6.6 Change-Id: Ib93fb879867e3aeb6e44193c4253e73173c141d2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-16 17:01:23 +02:00
set(base_dir "${source_dir}")
Use `_qt_internal_path_is_prefix` Change-Id: I3eeb514c33340956328eff33409dfa2899023eb5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-02-04 13:56:23 +01:00
else()
set(base_dir "${binary_dir}")
Use the relative header path when checking if it's 3rdparty If source or build directry contain '3rdparty' in their path, all header files are marked as 3rdparty and will never be installed. This commit is CMake counterpart of ea4a3d78a776e10955caf6cf9b1054ddb50f40d3 Amends ea4a3d78a776e10955caf6cf9b1054ddb50f40d3 Fixes: QTBUG-116137 Pick-to: 6.5 6.6 Change-Id: Ib93fb879867e3aeb6e44193c4253e73173c141d2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-16 17:01:23 +02:00
endif()
file(RELATIVE_PATH file_path_rel "${base_dir}" "${file_path}")
if(file_path_rel MATCHES "3rdparty/.+" AND NOT is_3rdparty_library)
Avoid syncing and installation of non-module headers Add CMake rules to skip syncing and installation of header files that are recognized as non-module. Previously these rules were in syncqt.cpp only and CMake ignored them when creating the installation rules. Now we skip any post processing for the header files that: - are public and located in the '3rdparty' directory unless the module is the 3rdparty one - are not a part of the module source tree unless they are generated - have the _qt_non_module_header property set to TRUE Pick-to: 6.5 Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-30 16:54:49 +02:00
set(is_3rdparty_header TRUE)
else()
set(is_3rdparty_header FALSE)
endif()
Avoid the 'file' command shadowing Avoid the 'file' command shadowing by a variable and use file name when filtering header files by type. Amends 8539e641f6f48a605547f66c47266d19e537f74e Task-number: QTBUG-103196 Change-Id: If012975efafaf119cffbd89baf84df334bc057ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-09-21 13:30:37 +02:00
list(APPEND ${out_var}_all "${file_path}")
CMake: Fix dbus and vk headers to be excluded from doc generation Before this change, if someone called ninja Gui_generate_docs, it would implicitly depend on sync_all_public_headers -> Gui_sync_headers which would generate dbus headers. This caused trouble with the new 'build doc tools from qttools/dev/HEAD' approach, because an older pre-built dbus tool might be passed a newer option when integrating a qtbase change that passes the new option. To avoid that, we now filter out the dbus headers from the list of headers that should be processed by syncqt when building a documentation target. We do the same for the qvkgen generated headers. This also removes the dependency on the ${target}_sync_headers target, which means there is a potential issue when someone manually calls `ninja sync_all_public_headers Gui_sync_headers` or something like it, which would spawn two syncqt processes that access the same files concurrently. This is an edge case that should not happen, but if it ends up happening, we will have to implement some kind of lock file mechanism. Pick-to: 6.8 6.9 Fixes: QTBUG-134672 Task-number: QTBUG-128730 Change-Id: I9061f9495e2faa77744f5f5c0de8fedd362ba228 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-03-20 15:39:02 +01:00
get_source_file_property(exclude_from_docs "${file_path}" _qt_syncqt_exclude_from_docs)
if(exclude_from_docs)
list(APPEND ${out_var}_exclude_from_docs "${file_path}")
endif()
Avoid the 'file' command shadowing Avoid the 'file' command shadowing by a variable and use file name when filtering header files by type. Amends 8539e641f6f48a605547f66c47266d19e537f74e Task-number: QTBUG-103196 Change-Id: If012975efafaf119cffbd89baf84df334bc057ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-09-21 13:30:37 +02:00
if(qpa_filter AND file_name MATCHES "${qpa_filter}")
list(APPEND ${out_var}_qpa "${file_path}")
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
elseif(rhi_filter AND file_name MATCHES "${rhi_filter}")
list(APPEND ${out_var}_rhi "${file_path}")
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
elseif(ssg_filter AND file_name MATCHES "${ssg_filter}")
list(APPEND ${out_var}_ssg "${file_path}")
Avoid the 'file' command shadowing Avoid the 'file' command shadowing by a variable and use file name when filtering header files by type. Amends 8539e641f6f48a605547f66c47266d19e537f74e Task-number: QTBUG-103196 Change-Id: If012975efafaf119cffbd89baf84df334bc057ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-09-21 13:30:37 +02:00
elseif(private_filter AND file_name MATCHES "${private_filter}")
list(APPEND ${out_var}_private "${file_path}")
Avoid syncing and installation of non-module headers Add CMake rules to skip syncing and installation of header files that are recognized as non-module. Previously these rules were in syncqt.cpp only and CMake ignored them when creating the installation rules. Now we skip any post processing for the header files that: - are public and located in the '3rdparty' directory unless the module is the 3rdparty one - are not a part of the module source tree unless they are generated - have the _qt_non_module_header property set to TRUE Pick-to: 6.5 Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-30 16:54:49 +02:00
elseif((NOT public_filter OR file_name MATCHES "${public_filter}")
AND NOT is_3rdparty_header)
Avoid the 'file' command shadowing Avoid the 'file' command shadowing by a variable and use file name when filtering header files by type. Amends 8539e641f6f48a605547f66c47266d19e537f74e Task-number: QTBUG-103196 Change-Id: If012975efafaf119cffbd89baf84df334bc057ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-09-21 13:30:37 +02:00
list(APPEND ${out_var}_public "${file_path}")
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
endif()
Replace the syncqt.pl script with syncqt tool 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 <alexandru.croitor@qt.io>
2022-08-15 18:29:41 +02:00
if(is_generated)
list(APPEND ${out_var}_generated "${file_path}")
endif()
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
endforeach()
Add CONDITION_INDEPENDENT_SOURCES argument to qt_internal_extend_target The argument allows to ignore the condition for source files if they are used in the Qt code without corresponding guards. The header files of this kind usually have internal guards, that suppress the error at the location where they are used, so AUTOGEN is skipped for these header files to suppress the warnings from CMake. If file belongs to a module, it will display AUTHOR_WARNING which should urge Qt maintainers to guard the use of the source file properly. Task-number: QTBUG-103196 Change-Id: I7b4c12031a5d19ff15868d4782c0d396ef7aed8c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-11-03 16:38:51 +01:00
if(NOT condition_independent_headers_warning STREQUAL "" AND QT_FEATURE_developer_build)
message(AUTHOR_WARNING "Condition is ignored when adding the following header file(s) to"
" the ${target} module:"
"${condition_independent_headers_warning}"
"\nThe usage of the file(s) is not properly isolated in this or other modules according"
" to the condition. This warning is for the Qt maintainers. Please make sure that file"
" include(s) are guarded with the appropriate macros in the Qt code. If files should be"
" added to the module unconditionally, please move them to the common SOURCES section"
" in the qt_internal_add_module call.")
endif()
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
set(header_types public private qpa rhi ssg)
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
set(has_header_types_properties "")
foreach(header_type IN LISTS header_types)
get_target_property(current_propety_value ${target} _qt_module_has_${header_type}_headers)
if(${out_var}_${header_type})
list(APPEND has_header_types_properties
_qt_module_has_${header_type}_headers TRUE)
endif()
set(${out_var}_${header_type} "${${out_var}_${header_type}}" PARENT_SCOPE)
endforeach()
Replace the syncqt.pl script with syncqt tool 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 <alexandru.croitor@qt.io>
2022-08-15 18:29:41 +02:00
set(${out_var}_all "${${out_var}_all}" PARENT_SCOPE)
set(${out_var}_generated "${${out_var}_generated}" PARENT_SCOPE)
CMake: Fix dbus and vk headers to be excluded from doc generation Before this change, if someone called ninja Gui_generate_docs, it would implicitly depend on sync_all_public_headers -> Gui_sync_headers which would generate dbus headers. This caused trouble with the new 'build doc tools from qttools/dev/HEAD' approach, because an older pre-built dbus tool might be passed a newer option when integrating a qtbase change that passes the new option. To avoid that, we now filter out the dbus headers from the list of headers that should be processed by syncqt when building a documentation target. We do the same for the qvkgen generated headers. This also removes the dependency on the ${target}_sync_headers target, which means there is a potential issue when someone manually calls `ninja sync_all_public_headers Gui_sync_headers` or something like it, which would spawn two syncqt processes that access the same files concurrently. This is an edge case that should not happen, but if it ends up happening, we will have to implement some kind of lock file mechanism. Pick-to: 6.8 6.9 Fixes: QTBUG-134672 Task-number: QTBUG-128730 Change-Id: I9061f9495e2faa77744f5f5c0de8fedd362ba228 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2025-03-20 15:39:02 +01:00
set(${out_var}_exclude_from_docs "${${out_var}_exclude_from_docs}" PARENT_SCOPE)
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
if(has_header_types_properties)
set_target_properties(${target} PROPERTIES ${has_header_types_properties})
endif()
set_property(TARGET ${target} APPEND PROPERTY
EXPORT_PROPERTIES
_qt_module_has_public_headers
_qt_module_has_private_headers
_qt_module_has_qpa_headers
rhi: Make it a QPA-style private but semi-public API qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-04-27 13:16:29 +02:00
_qt_module_has_rhi_headers
Add enablers to expose semi-public APIs for QtQuick3D Follow the same patterns as for qpa and rhi. Semi-public APIs will be put under the "namespace" ssg which is short for Spatial Scene Graph. Taks-number: QTBUG-116570 Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-04 16:57:42 +02:00
_qt_module_has_ssg_headers
Respect CMake source tree when installing header files Use CMake source tree when installing header files instead installing all header files that syncqt.pl produces. This avoid adding header files which cannot be used because of platform or feature incompatibility with Qt version. Since syncqt.pl doesn't respect CMake build tree when generating master header and CaMeL case header files, these header files still will be installed regardless platform or feature limitations. This will not be the case once we switch to syncqt.cpp, which will install only headers that are relevant to the selected platform and enabled features. Task-number: QTBUG-103196 Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-12 19:53:14 +02:00
)
endfunction()
Introduce qt_internal_set_module_transitive_properties The function sets properties on target that then are propagated transitively. This only works with Qt modules, but can be extended for other Qt targets later. These transitive properties not necessarly require Qt be built using CMake versions supporting transitive properties(>= 3.30). Properties are stored and exported within the Qt module unconditionally and can be used in user projects, if CMake version allows this. Change-Id: I1ff6f1099753784c721dc1e3cd972dcd9dafedc4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-05-22 15:59:58 +02:00
# Set the value of the respective module properties and make the properties
# transitive. The property is not stored as target property, but is set as
# INTERFACE property, so its value is not considered by target itself, but only
# by depending targets. Also this require all properties have the
# INTERFACE_<property_name> name format.
#
# Synopsis
# qt_internal_set_module_transitive_properties(<target>
# PROPERTIES <prop1> <value1> [<prop2> <value2>] ...
# )
#
# Arguments
#
# `target` Qt module target. Unlike CMake set_target_properties this function
# accepts only one target as argument.
#
# `PROPERTIES` List of the property name-value pairs.
#
# `TYPE` The transitive property type: COMPILE or LINK.
function(qt_internal_set_module_transitive_properties target)
cmake_parse_arguments(PARSE_ARGV 1 arg "" "TYPE" "PROPERTIES")
if(NOT arg_PROPERTIES)
message(FATAL_ERROR "PROPERTIES argument is missing.")
endif()
if(NOT arg_TYPE)
message(FATAL_ERROR "TYPE argument is missing.")
endif()
list(LENGTH arg_PROPERTIES count)
math(EXPR even_args_count "${count} % 2")
if(NOT even_args_count EQUAL 0)
message(FATAL_ERROR "Insufficient number of PROPERTIES values.")
endif()
_qt_internal_dealias_target(target)
set(property_names "")
set(internal_property_names "")
math(EXPR last "${count} - 1")
foreach(name_idx RANGE 0 ${last} 2)
list(GET arg_PROPERTIES ${name_idx} interface_property_name)
if(interface_property_name MATCHES "^INTERFACE_(.+)$")
set(property_name "${CMAKE_MATCH_1}")
else()
message(FATAL_ERROR "Incorrect property name ${interface_property_name}. The property"
" name must have the INTERFACE_ prefix. Use regular set_target_properties call to set"
" the non-transitive property.")
endif()
string(TOLOWER "${property_name}" property_name_lower)
list(APPEND property_names ${property_name})
math(EXPR value_idx "${name_idx} + 1")
list(GET arg_PROPERTIES ${value_idx} property_value)
if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.30)
# The collected interface properties exposed in module build tree and have the
# same transitive capabilities as after the module is installed. Supported for
# CMake version >= 3.30
set_property(TARGET ${target} PROPERTY ${interface_property_name} "${property_value}")
else()
# Internal properties are exported within the Qt module. They have limitations that
# EXPORT_PROPERTIES apply. These properties are exported even if we are building Qt
# with CMake versions that do not support transitive properties. It allows using
# them as transitive properties in user projects if CMake allows this.
list(APPEND internal_property_names _qt_internal_${property_name_lower})
set_property(TARGET ${target} PROPERTY
_qt_internal_${property_name_lower} "${property_value}")
endif()
_qt_internal_add_transitive_property(${target} ${arg_TYPE} ${property_name})
endforeach()
get_target_property(transitive_properties ${target} _qt_transitive_${type_lower}_properties)
if(NOT transitive_properties)
set(transitive_properties "")
endif()
list(APPEND transitive_properties ${property_names})
list(REMOVE_DUPLICATES transitive_properties)
get_target_property(export_properties ${target} EXPORT_PROPERTIES)
if(NOT export_properties)
set(export_properties "")
endif()
list(APPEND export_properties ${internal_property_names})
list(REMOVE_DUPLICATES export_properties)
string(TOLOWER "${arg_TYPE}" type_lower)
set_target_properties(${target} PROPERTIES
EXPORT_PROPERTIES "${export_properties}"
_qt_transitive_${type_lower}_properties "${transitive_properties}"
)
endfunction()
Reference in New Issue Copy Permalink