summaryrefslogtreecommitdiffstats
path: root/cmake/QtExecutableHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* cmake: Respect CMAKE_MACOSX_BUNDLE and CMAKE_WIN32_EXECUTABLETor Arne Vestbø2025-03-311-2/+9
| | | | | | | | | | | | | The user may set different global defaults for CMAKE_MACOSX_BUNDLE and CMAKE_WIN32_EXECUTABLE, so we shouldn't unconditionally override them on a target level. This allows cmake ~/foo/ -DCMAKE_MACOSX_BUNDLE=ON to build a project as a GUI app without needing to modify the CMakeLists.txt with target specific overrides. Change-Id: Id49adb1c0aedfe82a2b1d919d086c5112ba92b93 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix the condition that enables/defaults exceptionsAlexey Edelev2025-03-171-1/+1
| | | | | | | | | | | | | Not sure why it worked at implementation time. But now it definitely doesn't. We may check the EXCEPTIONS flag value, since it's the equivalent of its presence/non-presence in the argument list. Amends f98fd705290ac7bd9434552a07e38b775e6a6dbf Task-number: QTBUG-118901 Pick-to: 6.9 Change-Id: I9769b4921a2f72d31aea2b0bffd2511edd89f88f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Use `_qt_internal_path_is_prefix`Cristian Le2025-02-171-2/+3
| | | | | | Change-Id: I3eeb514c33340956328eff33409dfa2899023eb5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Remove qt executable SBOM generation stale codeAlexandru Croitor2025-01-241-17/+0
| | | | | | | | | | | | | | | We never ended up calling _qt_internal_finalize_sbom for generic Qt repo executables, and we never passed an SBOM type, so this code never worked. Remove it to avoid confusion. It might be re-added in the future. This doesn't affect the SBOM generation for Qt tools and apps. Pick-to: 6.8 6.9 Task-number: QTBUG-122899 Change-Id: Iffde964efe2a6b70e6e0b64ec0803af5e84172fb Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Build executables in single-config debug-and-release buildsAlexandru Croitor2025-01-211-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If qtbase is configured with -debug-and-release -force-debug-info, which maps to '-GNinja Multi-Config' '-DCMAKE_CONFIGURATION_TYPES=RelWIthDebInfo;Debug' and then qtopcua is configured with -GNinja -DCMAKE_BUILD_TYPE=Release building the 'all' target would not build executables or tools. That's because the targets have their EXCLUDE_FROM_ALL property set to exclude any non-first multi-config, and Release doesn't match RelWithDebInfo. Such a scenario can happen for our multi-config windows builds, when someone tries to build a repo not with qt-configure-module but rather with cmake directly. They would then not specify the same build types or generator, which can happen when opening in an IDE like Qt Creator. Make sure to also check if the current generator is a multi-config one, in addition to whether QT_FEATURE_debug_and_release is ON, before adding the genex to the EXCLUDE_FROM_ALL property. This allows building and installing executables and tools in such a scenario, because in a single config build, the genex would not be added, even if QT_FEATURE_debug_and_release is ON. Pick-to: 6.8 6.9 Fixes: QTBUG-132609 Task-number: QTBUG-132338 Change-Id: Iaee1a0afb19df97ee1263dbaf27c8e29fc127831 Reviewed-by: Jannis Völker <jannis.voelker@basyskom.com> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Move separate debug info handling to an executable finalizerAlexandru Croitor2024-11-141-3/+14
| | | | | | | | | | | | | | | | | | Currently the separate debug info handling is done inside the call of qt_internal_add_executable. But there might be extra properties set after the executable is created, which we might want to consider when handling the separate debug info, like whether the executable is a macOS bundle. Introduce a new qt_internal_finalize_executable finalizer. Move the separate debug info handler to be called in this finalizer. To be consistent run the separate debug info handler in a finalizer for qt tools as well. Pick-to: 6.8 Change-Id: I46412249aaab099628a50b11efff541f5719aff5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Run finalizers for test-like executables on all platformsAlexandru Croitor2024-11-061-5/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we ran some finalizer functions for tests and manual tests, only for specific platforms, and via different code paths. This change introduces a new unified way of running all finalizers for all test-like executables, including benchmarks. To ensure a smoother transition, the new way is opt-out, and the old way can be enabled by setting the QT_INTERNAL_SKIP_TEST_FINALIZERS_V2 variable to true in case we encounter some issues in the CI. The finalizers are only run for test-like executables, and not all internal executables, because there are some unsolved issues there. One particular case is in qtdeclarative where that will create a cycle for qmlimportscanner to depend on itself. A proper solution here would be to have some kind of mapping or mechanism to exclude finalizers for targets where they would try to run themselves. Pick-to: 6.8 Task-number: QTBUG-93625 Task-number: QTBUG-112212 Change-Id: I52b3a1c02c298c4a18ce2c75d7e491ae79d191a0 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Mark benchmark executables with a propertyAlexandru Croitor2024-10-301-0/+1
| | | | | | | | | | This will be used in a follow up patch to identify them. Pick-to: 6.8 Task-number: QTBUG-93625 Task-number: QTBUG-112212 Change-Id: I39d5eb9f79ac67af0808efeda4d7f4e0a6908cc9 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake:Android: add wrapper scripts to easily run appsAssam Boudjelthia2024-10-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a script that allows running an app or a test easily similar to running on host. This improves development workflow and time by allowing quick runs without having to manually call the various adb commands to launch, get a pid of the app and then print the logcat, let alone passing parameters or environment variables. For normal apps, the app package name is retrieved by the script, run and live logcat is printed as long as the app is still running. For tests, the script calls androidtestrunner, allowing test parameters to be passed to the test. For CI debugging, this would save quite a lot of hussle and frustration trying to run or debug a test app. One other benefit for this is enabling running Android tests from Qt Creator's testlib plugin without big changes to Qt Creator to support androidtestrunner explicitly. Because file(GENERATE) would fail if called twice for the same file, I use file(WRITE). This is used because at the time of calling the target executable finalizer, we don't know if the target is a test or not, so we rely on writing the script first as a normal target, then call it if the target is a test where it overrides the script. For this also, parameters passed to the runner or androidtestrunner can't handle generator expressions. [ChangeLog][CMake][Android] Add wrapper scripts to run Android apps and tests with ease from the host. Task-number: QTBUG-129889 Change-Id: I84e85ce2bbf6944c8aa20bdc2c2b6d7b956bc748 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Make per-repos WARNINGS_ARE_ERRORS workAlexey Edelev2024-09-121-1/+2
| | | | | | | | | | | | | | | | | | | | Add the WARNINGS_ARE_ERRORS flags unconditionally, so developers may control skipping per-target or per-repo. This allows setting the WARNINGS_ARE_ERRORS cmake option for each repo independently when configuring them. So qtbase might be built without the flag enabled and setting the WARNINGS_ARE_ERRORS to TRUE for the depending repo enables it for the internal Qt targets. Add the new internal function that controls the related internal flag. Keep qt_skip_warnings_are_errors for compatibility since it's used in qtwebengine. Combine qt_internal_set_skip_warnings_are_errors and qt_skip_warnings_are_errors_when_repo_unclean functionality in the new qt_internal_default_warnings_are_errors function. Change-Id: I1330c75cd67a24e6386f5e94a089e43fa2012bc4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add the 'exceptions' featureAlexey Edelev2024-08-121-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | The feature allows enabling/disabling exceptions for the Qt builds. The feature is disabled by default. This commit reworks the way the exception flags are set for Qt targets. Instead of setting them per-target, flags now are set for the QtPlatformCommonInternal target, which transitively propagates the flag to other Qt targets. To disable/enable exception flags the newly introduced property _qt_internal_use_exceptions can be used. The flags enabling/disabling now can happen any time, but not only at target creation time. The property has 3 states: TRUE, FALSE, DEFAULT(or empty). If the property is not set or is set to DEFAULT, the exceptions feature value is used to set the required exceptions flags. Otherwise the flags are set according to the property value. The logic of EXCEPTION argument of the various qt_internal_add_ functions was also updated. If the argument is not provided, the _qt_internal_use_exceptions property value is set to DEFAULT, which gives the control on the exception flags to the feature. If the argument is provided, the exceptions are enabled by setting the _qt_internal_use_exceptions property to TRUE. Task-number: QTBUG-118901 Change-Id: I83e3bf52d48a3d16977cce849c9b0765c34f1f21 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Skip handling binary files in SBOM for excluded targetsAlexandru Croitor2024-06-251-1/+4
| | | | | | | | | | | | | | | | If a target has the _qt_internal_excluded_from_default_target property set, don't try to add file SBOM information for the target, because the file will not be built nor installed by default. We check for a new custom _qt_internal_excluded_from_default_target property instead of EXCLUDE_FROM_ALL, because EXCLUDE_FROM_ALL might be set to a genex that excludes all configs except the main one, but we are interested whether the target is entirely excluded. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I79d6a4b0c65356da14f7ff50ee3639705f5fabbd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* wasm: refactor cmake finalizersMorten Sørvig2024-06-191-4/+3
| | | | | | | | | | | Avoid duplication and move finalizer code to a new function "_qt_internal_finalize_wasm_app", which can be called from the add_executable functions. Pick-to: 6.8 Change-Id: I4859a3999725ebf61a496d78665b6a259dfeb0f5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
* CMake: Allow specifying most SBOM options to qt_internal_add_fooAlexandru Croitor2024-06-181-4/+17
| | | | | | | | | | | | | | | | | | | | | | Previously, only a very short subset of options related to attribution files could be specified to qt_internal_add_module / qt_internal_extend_target. It is more convenient to allow specifying most (safe) options, instead of calling another function. Unsafe are considered paths like INSTALL_PATH and derivatives, TYPE which is too generic, and some other ones like LIBRARIES which would be duplicated, and causes warnings in cmake_parse_arguments if duplicated. Change the code to allow specifying most SBOM options and forwarding them to _qt_internal_extend_sbom. Pick-to: 6.8 Task-number: QTBUG-122899 Change-Id: I6eb723e165edf59973d83c66eace43acdce237de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Generate an SPDX v2.3 SBOM file for each built repositoryAlexandru Croitor2024-06-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Fix configs passed to qt_get_install_target_default_argsAlexandru Croitor2024-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because the configs passed to the ALL_CMAKE_CONFIGS option were quoted cmake_parse_arguments(PARSE_ARGV) would escape the semicolon in the set value, effectively doing set(arg_ALL_CMAKE_CONFIGS "Release\;Debug") Then the list(GET arg_ALL_CMAKE_CONFIGS 0 first_config) call would essentially do set(first_config "Release;Debug") and the if(all_configs_count GREATER 1 AND NOT arg_CMAKE_CONFIG STREQUAL first_config) condition would never trigger because a single config string can never equal a double config string. Remove the quotes to ensure correct behavior. This won't really trigger any behavior change, because we exclude installation of Debug executables in -debug-and-release builds, but it will make --trace-expand logs less confusing. Amends f240d94f140ba1614828804efafd2fc5e6d00099 Pick-to: 6.7 Change-Id: I53179511c7698c90b33cb3ff2762cef680a99815 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Consider the qt_internal_extend_target calls when adding deps on ↵Alexey Edelev2024-05-081-9/+0
| | | | | | | | | | | | | qpa_default_plugins Applications not necessarly link QtGui module in qt_internal_add_executable. They still may add link it in followoup qt_internal_extend_target calls. We should consider this when adding dependencies on qpa_default_plugins to the internal executables. Pick-to: 6.7 Change-Id: Icc413bd35b631b3a356e4033faab4e6c01b29a60 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Consider the versioned Qt6::Gui when target when adding the plugin dependenciesAlexey Edelev2024-05-081-1/+2
| | | | | | | | | | QtGui module can be linked using both versioned and non versioned targets. Consider this when adding the dependencies to the qpa_default_plugins targets. Pick-to: 6.7 Change-Id: Iccbf3009ab8a4f9df4de1677f1b41445814c8c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix the static linking of plugins to the Qt tools and internal executablesAlexey Edelev2024-05-081-89/+0
| | | | | | | | | | | | | | | Qt tools and executables may required the static plugins from modules that are build as part of the Qt build tree. In this case we need to force plugin importing. This adds the qt_internal_import_plugins call when we extend the executable target. Replace the previos solution that considered libraries that were provided in the arguments of the qt_internal_add_executable call only. Pick-to: 6.7 6.6 6.5 Fixes: QTBUG-111988 Change-Id: Ifa2cf7f1f68d9f90cafc64f225aebe11d4cdb2ae Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix syncqt IMPORTED_LOCATION path for multi-config buildsAlexandru Croitor2024-03-111-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building examples as ExternalProjects as part of a multi-config qtbase build, syncqt can not be located with the following error: CMake Error at Qt6CoreToolsAdditionalTargetInfo.cmake:10 (message): Unable to add configure time executable Qt6::syncqt qtbase/libexec/syncqt doesn't exist Call Stack (most recent call first): qtbase/lib/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake:44 (include) qtbase/cmake/QtPublicDependencyHelpers.cmake:65 (find_package) qtbase/lib/cmake/Qt6Core/Qt6CoreDependencies.cmake:34 (_qt_internal_find_tool_dependencies) qtbase/lib/cmake/Qt6Core/Qt6CoreConfig.cmake:42 (include) qtbase/lib/cmake/Qt6/Qt6Config.cmake:165 (find_package) CMakeLists.txt:13 (find_package) The Qt6CoreToolsAdditionalTargetInfo.cmake file is used both for install(EXPORT) Config files as well as export(EXPORT) Config files, and in the latter case, the path that syncqt is looked up in is not correct because syncqt is not yet installed. In addition to checking whether syncqt exists in the install path, also check if it exists in the build dir. Ideally the additional path would be stored in a separate file that is not installed, but the current code infrastructure does not provide such a feature. Because we store a relative path instead of an absolute path, the build path does not leak, so the situation is bearable. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I16ad5c280751e050bc9b039ebd38ec9a66a6554c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* wasm: remove DISABLE_EXCEPTION_CATCHING workaroundMorten Sørvig2024-02-271-6/+1
| | | | | | | | | | Qt no longer sets DISABLE_EXCEPTION_CATCHING and can use the common logic here. Task-number: QTBUG-121822 Change-Id: If02feafe9eeac49fa2861d2357b358a19e756438 Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
* Consider changes of the CMake flags when re-building syncqtAlexey Edelev2023-10-161-26/+34
| | | | | | | | | | | Configure time executables don't adopt new cmake flags if they were changed. Cache all flags that were used when building configure time executables and consider changes when decide rebuilding them. Pick-to: 6.6 6.5 Change-Id: Ifba77833f362c790120f0ab1f808a855327bc49f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
* Add variable linked to configure-time executables to detect CMakeCache wipingAlexey Edelev2023-09-111-1/+8
| | | | | | | | | | | Wiping of CMakeCache should lead to removing of CMakeCache that is generated for configure-time executable. Otherwise configure-time executables might still use wrong compiler or compiler flags. Pick-to: 6.6 6.5 Task-number: QTBUG-116789 Change-Id: I702d5d29e0c5f35a8a36311cf9a84ea7a0f4d781 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake helpers: support NO_PCH_SOURCES wherever NO_UNITY_BUILD_SOURCES areMarc Mutz2023-08-071-0/+1
| | | | | | | | | | | The former implies the latter, so it makes little sense to treat them differently. Even if some types of targets are (currently) never compiled with PCH, users of qt_internal_all_x() shouldn't need to know such details. Pick-to: 6.6 6.5 Change-Id: I8ead238a8d9e55da632b2929638b67724a42d73c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Fix syncqt compiler and linker flags handlingAlexey Edelev2023-06-291-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | We want syncqt to be built optimized by default. The current approach set the default build type for the external projects and optimized flags for the non-configure-time syncqt build. The problem is that syncqt still have compiler flags littered by either the Qt configuration type or the system defaults that are applicable for RelWithDebugInfo configuration(the default one we chose for syncqt). This patch makes sure that we cleanup all compiler flags from any optimizations and apply optimized flags for all configurations. Also we discard '/RTC1' flag if it's set. Configure time executables now respect the language related flags that are set in the project and adjust the flags passed to try_compile. For linker flags we should use those that are applicable for the preferred build type. Since syncqt is built in RelWithDebugInfo by default we should replace linker flags in all configs with those are used for RelWithDebugInfo configuration. Fixes: QTBUG-114925 Pick-to: 6.5 6.6 Change-Id: I782f81a36f5ef7ee4d342ce8ac6c217cb2552f3b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Introduce QT_SYNC_HEADERS_AT_CONFIGURE_TIME flagAlexey Edelev2023-06-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The syncqt tool was originally designed to run at build time, as a part of dependency chain of Qt modules. This works well unless we need the code model of the Qt project in IDE, since Qt source code actively uses header aliases, and creating them at build time breaks the code model until the initial build is done. So we made syncqt the configure time tool to not break the developer experience. It's more likely that developers build Qt using command line or don't need the code model before the first build. So running the tool at configure time should be optional. QT_SYNC_HEADERS_AT_CONFIGURE_TIME switches the "mode" of the syncqt tool from build time tool to the configure time tool. Without the option enabled build procedure runs all the syncing targets at build time only. The exception are the developer builds, if the '-developer-build' option is enabled, QT_SYNC_HEADERS_AT_CONFIGURE_TIME is set to TRUE by default. This gives better development experience for the developers that don't use the code model in their IDE or don't require it before the first build is finished. Also this build time mode is preferred for the CI or similar build procedures where code model is not required at all. By default, the option initialized from the QT_INTERNAL_CONFIGURE_FROM_IDE CMake variable. TODO: The option is forced to TRUE for the static Ninja Multi-Config builds. See QTBUG-113974 for details. [ChangeLog][Build System] When building Qt from sources, syncqt and Qt header files are now created at build time, not configure time. This should speed up the configuration step. You can set the CMake variable QT_CONFIGURE_TIME_SYNC_HEADERS to ON to use the previous behavior, though. The old behavior is also preserved if cmake/configure is run from inside an IDE - Qt Creator, Visual Studio Code, and CLion are currently detected. Task-number: QTBUG-111163 Task-number: QTBUG-109792 Pick-to: 6.6 Change-Id: Ib61bda9546e58492be874a8591c37e100313d02c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix CMP0099 impact - disallow propagating internal linker optionsAlexey Edelev2023-06-161-0/+1
| | | | | | | | | | | | | | | | | | | CMP0099 changes the way of LINK_ONLY genex works. With CMP0099 set to OLD LINK_ONLY genex only links the exact library binary/archive without propagating other interface options from the target. This feature was exploited by PlatformXInternal targets to avoid propagating of their linker options. Nowadays when CMP0099 is forced to NEW by Qt scripts, including user-facing, we cannot rely on LINK_ONLY genex. Introduce _qt_is_internal_target property that is set for all Qt executables and explicitly limits the propagation of the linker options from PlatformXInternal targets. Pick-to: 6.5 6.6 Fixes: QTBUG-113641 Change-Id: I3a0ecddb65886e435073feb24c1b47035130ba70 Reviewed-by: Alexandru Croitor (OOO) <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* WASM: fix wrong parameter passed to CMake functionYuhang Zhao2023-05-241-1/+1
| | | | | | | | The function needs TRUE/FALSE, not NO_EXCEPTIONS. Change-Id: I3e173e26fafc02996577466afd09e85351a0380f Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* CMake: Fully rebuild dirty configure-time executablesJoerg Bornemann2023-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: "ninja clean" does not fully clean the build directories of configure-time executables (e.g. syncqt). This can lead to problems when building with compiler and linker launchers: on configure time, the launchers are not used (compare CMake issue #20762). After a "ninja clean", the executable might be removed but the object files are still there. This leads to a situation where the object files have been created without the compiler launcher but are linked with the linker launcher. We encountered a situation however, where the linker launcher requires the usage of the compiler launcher. The configure-time executable has a ${target}_build custom command that runs "cmake --build" and creates a timestamp file to track when to build the target. To circumvent the problem of stale object files we add the "--clean-first" argument to that target to fully rebuild configure-time executables if the timestamp file is out of date. The performance this imposes is negligible, because 1. Those configure-time executables are seldom out of date. 2. They are supposed to be "tiny executables with system dependencies only" anyway. Pick-to: 6.5 Change-Id: I701f9089f5ad941ffdf235aeccc3119b68c4e3e3 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Fix multi-thread GNU make buildAlexey Edelev2023-04-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Add the timestamp file creation for configure-time executables. GNU make treats the custom command artifacts as 'dirty' when one of the expected outputs is missing. It displays the following disclaimer Deleting primary custom command output ... because another output ... does not exist. which leads to the configure-time executable rebuild. The removal and rebuild is not in sync with the dependency lookup for other targets(thanks to GNU make) so targets that depend on the configure-time executables simply miss the dependency at build time. This happens to syncqt and '_sync_headers' targets. So creating the timestamp file at configure time indicates to GNU make that there is no need of removing the syncqt executable and the build process doesn't fail because of missing dependency. Fixes: QTBUG-112018 Fixes: QTBUG-111163 Pick-to: 6.5 Change-Id: I6c1e8cae522104cf50d0376fa2b5653a6770f9ca Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Replace STREQUAL cases with variable checksAmir Masoud Abdol2023-04-041-3/+3
| | | | | | | | | | | | | As I was investigating the NO_UNITY_BUILD_SOURCES issue, I realized that we don't need to pass these quoted, especially now that we have moved to `cmake_parse_arguments(PARSE_ARGV`, and we can check their existence just by checking the `arg_*`, and that should be sufficient. I also left a warning that we are aware of this. Pick-to: 6.5 Change-Id: I4d939e80dc4671ea3ae9dc61516279f69ba2c5a5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Improvement to NO_UNITY_BUILD_SOURCES, and fix related bugsAmir Masoud Abdol2023-04-031-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix an issue with passing NO_UNITY_BUILD_SOURCESAmir Masoud Abdol2023-03-151-2/+8
| | | | | | | | | | Amend 31518f1a4e3c4a7c77ae2e008e903a849ba75dd6 Amend 360293623094a31586981206e59c92aa6235163d Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ibb2fd881c02b6496f06b8b623fa6009358755a26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add some utilities for UNITY_BUILDAmir Masoud Abdol2023-02-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | - 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>
* Remove the extra quote, now that we use cmake_parse_arguments(PARSE_ARGVAmir Masoud Abdol2023-01-231-4/+4
| | | | | | | | | | | | | | | The extra quote enforces the arguments to be string, and stops the COMMAND_EXPAND_LISTS within QtDbusHelpers.cmake::qt_create_qdbusxml2cpp_command from expanding it as a list. Fixes: QTBUG-110459 Fixes: QTBUG-110450 Task-number: QTBUG-99238 Change-Id: Ifddd6570c7bf8f2d1757f275d9445ce2924a93f1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Retire the qt_parse_all_argumentsAmir Masoud Abdol2023-01-181-3/+3
| | | | | | | | | | | 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>
* Change the RUNTIME_OUTPUT_DIRECTORY for configure-time executablesAlexey Edelev2023-01-051-7/+9
| | | | | | | | | | | | | | | Set the RUNTIME_OUTPUT_DIRECTORY for configure-time executables so executable will be located inside the QT_BUILD_DIR. This allows to re-build syncqt and make sure ithat ts binary is replaced and located in the libexec directory. Comment on how to rebuild syncqt. Configure-time tools reserve the original tool name for the imported executable. To re-build syncqt use 'syncqt_build' target. Task-number: QTBUG-109792 Change-Id: Id7d912b1d75d18d82cb2a69fbd62b89440120d78 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Check if configure-time executable need to be recompiledAlexey Edelev2022-09-281-1/+17
| | | | | | | | | | | Respect source files that belong to configure-time executable when reconfiguring Qt. Amends: ac74b60c9c1101288eb2c558420ba69f675a2ee2 Task-number: QTBUG-87480 Change-Id: I7e42ffe8b1b79686c0cf93a02101f0b8e6be0bea Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Replace the syncqt.pl script with syncqt toolAlexey Edelev2022-09-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Use PARSE_ARGV signature to process arguments instead of escapingAlexey Edelev2022-09-211-1/+2
| | | | | | | | | | | | | Use PARSE_ARGV signature of the cmake_parse_arguments function to avoid escaping of semicolons when passing arguments to the qt_internal_add_configure_time_tool and qt_internal_add_configure_time_executable function. Amends ac74b60c9c1101288eb2c558420ba69f675a2ee2 Task-number: QTBUG-87480 Change-Id: I343abbd75107e56aaccab6e388db8dbda0525af3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Set NO_EXCEPTIONS on executables on wasmMikolaj Boc2022-09-191-1/+6
| | | | | | | | This reflects the true state of exceptions on WASM, which are always disabled (DISABLE_EXCEPTION_CATCHING is always set with 1). Change-Id: I7b681846159caf61f291f78a7b4ddf5260dc341f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add function to add and compile executables at configure timeAlexey Edelev2022-09-131-0/+163
| | | | | | | | | | qt_internal_add_configure_time_executable compiles the executable at configure time and exposes it to the CMake source tree. This is useful when need to run a small C++ program at configure time. Task-number: QTBUG-87480 Change-Id: I031efe797c8afa0721d75b46d4f36f67276bf46e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add wasm target helpers in a finalizer when adding executableMikolaj Boc2022-09-021-1/+0
| | | | | | | | This way it is able to pick up all of the properties assigned to it before finalization. Change-Id: I9da635f8620859a669c4e4d589fff56a3ce42ab9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Plug the WASM batched test runner into the build systemMikolaj Boc2022-08-311-5/+5
| | | | | | | | The new batched test runner is now used for running the tests instead of the wasm shell, which runs for single test cases. Change-Id: I7b7e6dd7993ba7937124c5843356b6891301b893 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Change the license of all CMakeLists.txt and *.cmake files to BSDLucie Gérard2022-08-231-1/+1
| | | | | | | Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* wasm: allow apps to override EXPORT_RUNTIME_METHODSLorn Potter2022-08-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Developers can add to Emscripten's EXPORT_RUNTIME_METHODS by defining their own using: QT_WASM_EXTRA_EXPORTED_METHODS Which will add on to Qt's default exported runtime methods of UTF16ToString,stringToUTF16 for cmake: set_target_properties(<target> PROPERTIES QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap") or set(QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap") for qmake: QT_WASM_EXTRA_EXPORTED_METHODS = ccall,cwrap Done-with: Mikolaj Boc Fixes: QTBUG-104882 Pick-to: 6.4 Change-Id: I9678bdb7b077aaa8527057212ea4e161c0be0b60 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add license headers to cmake filesLucie Gérard2022-08-031-0/+3
| | | | | | | | | | | | CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Deprecate _add_app/executable/test/tool PUBLIC_LIBRARIES optionAlexandru Croitor2022-07-291-2/+11
| | | | | | | | | | | | | | | | | | | | | | | Warn projects not to use it because PUBLIC_LIBRARIES don't make sense for executable targets and it also led to some issues in the internal functions where some of them did not expect to receive PUBLIC_LIBRARIES. To ensure builds don't needlessly break, treat PUBLIC_LIBRARIES values as regular LIBRARIES. In the future we might add an error instead. Using PUBLIC_LIBRARIES in qt_internal_add_app, etc, accidentally worked because the option name and the values following it were parsed as values of the "previous" option, like SOURCES or INCLUDE_DIRECTORIES or LIBRARIES, and when those got passed through to qt_internal_extend_target, things magically worked. We have a lot of projects using PUBLIC_LIBRARIES, mostly due to the way qmake pro files were written and how pro2cmake converted them. We'll have to clean up each repo. Change-Id: I69e09d34afdf98f0d47c08d324643fc986f8131c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* cmake: Link static plugins even in shared Qt buildsTor Arne Vestbø2022-07-251-70/+69
| | | | | | | | | | | | | | | | It's perfectly possible to create static plugins in an otherwise shared Qt build, but the logic to import these plugins into applications was assuming a fully static Qt build. We now handle this more granularly. This works for in-source tools and tests as well, which don't go through the same CMake machinery for plugins as user projects do. The only case that does not currently work is in-source examples, as they don't share any of the plugin machinery with neither Qt internal tools/tests or user project, but that's a bigger architectural issue that goes beyond this change. Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix typosKai Köhne2022-06-131-1/+1
| | | | | | | | Found by codespell Pick-to: 6.4 Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-08 09:14:23 +0000