summaryrefslogtreecommitdiffstats
path: root/src/corelib/Qt6CoreMacros.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Improve Xcode projects for single SDK builds on Apple platformsTor Arne Vestbø2024-04-191-0/+15
| | | | | | | | | | | | | Xcode expects the base SDK to always be the device SDK, so we can't pass CMAKE_OSX_SYSROOT on directly. We use the Xcode SUPPORTED_PLATFORMS setting to inform Xcode about which targets we can actually build and run for. The logic is only triggered for single-arch Qt builds. Change-Id: I0012e220cb415fcc5995672ffd60b25ef7eeb4e7 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Add preliminary support for Qt for visionOSTor Arne Vestbø2024-04-181-4/+8
| | | | | | | | | | | | | | | | | | | | | | Qt already runs on Vision Pro as "Designed for iPad", using Qt for iOS. This change enables building Qt for visionOS directly, which opens the door to visionOS specific APIs and use-cases such as volumes and immersive spaces. The platform removes some APIs we depend on, notably UIScreen, so some code paths have been disabled or mocked to get something up and running. As our current window management approach on UIKit platforms depends on UIWindow and UIScreen there is currently no way to bring up QWindows. This will improve once we refactor our window management to use window scenes. To configure for visionOS, pass -platform macx-visionos-clang, and optionally add -sdk xrsimulator to build for the simulator. Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Add _qt_internal_get_i18n_catalogs_for_modulesJoerg Bornemann2024-04-171-1/+36
| | | | | | | | | | | | | This function finds the translations that belong to the Qt modules that are used by the project. "Used by the project" means just all modules that are pulled in via find_package for now. This code was in Qt6CoreDeploySupport.cmake before. Now, we can call it in other places too like Qt6LinguistToolsMacros.cmake. Task-number: QTBUG-110444 Change-Id: I338d54d93cf285190b1430608b32334692ae4c07 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Extract metatype information as part of library finalizationAndrei Golubev2024-04-171-0/+11
| | | | | | | | | | | | | | | | | | | | | | Make qt_finalize_target call qt6_extract_metatypes() on any library targets if the finalization is deferred and the target uses automoc. This makes sure the metatype information is always available when necessary (e.g. in QML's foreign types setting). [ChangeLog][CMake][Important Behavior Changes] With CMake 3.19 or later qt_extract_metatypes() is automatically called during target finalization for libraries that use automoc now. This has no effect if you've already manually called qt_extract_metatypes() before, but it does make sure that the metatypes are also generated if you haven't. Task-number: QTBUG-121199 Fixes: QTBUG-101143 Fixes: QTBUG-99051 Change-Id: If72ce5887a9cd71a4c15e9509b2eaab5af271adf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Revert "CMake: Improve Xcode projects for single SDK builds on Apple platforms"Tor Arne Vestbø2024-04-161-11/+0
| | | | | | | | | This reverts commit 5898e0e4f14d1e6d0b0fc09e122346d817cb821a. Likely broke a CMake deployment test in qtdeclarative. Change-Id: I90c8343f0657845dd514e573b7333f441b70cc9e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Revert "CMake: Fix *-metatypes.json creation, take III"Joerg Bornemann2024-04-161-1/+1
| | | | | | | | | | | | | This reverts commit 654f3c5634ac9efc2257177351c8dea7c8d8875a. That commit enabled a work-around for CMake upstream issue #19005 for Visual Studio project generators. It turns out that this is not actually needed, and that the work-around causes unnecessary rebuilds. Fixes: QTBUG-121046 Pick-to: 6.5 6.6 6.7 Change-Id: Ie502e2df999a204ab09d28322017be3c7ed8ebc5 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Improve Xcode projects for single SDK builds on Apple platformsTor Arne Vestbø2024-04-091-0/+11
| | | | | | | | | | | Xcode expects the base SDK to always be the device SDK, so we can't pass CMAKE_OSX_SYSROOT on directly. We use the Xcode SUPPORTED_PLATFORMS setting to inform Xcode about which targets we can actually build and run for. Change-Id: Ib46e81e946bc89f62d1e700422b37166c3d55009 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Move various rcc generated files into .qt subdirectoryAlexandru Croitor2024-03-221-5/+5
| | | | | | | | | | | | | So we have a single central location for all generated files. [ChangeLog][Build System] Generated resource files (and supporting files) will now be placed into the .qt/rcc subdirectory of a project build dir. The location is an implementation detail that might still change in the future, so it should not be relied upon. Pick-to: 6.7 Change-Id: Id21df22cac832b618e98c25e0e134f4cf70ed9bd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Consider NO_UNSUPPORTED_PLATFORM_ERROR for non-bundle mac appsAlexandru Croitor2024-03-221-16/+22
| | | | | | | | | | | | | | | | | | | | | | | Currently if qt6_generate_deploy_app_script is called on an executable target that does not have the MACOSX_BUNDLE property set, it will error out with a message about not supporting non-bundle apps. This error is shown even if NO_UNSUPPORTED_PLATFORM_ERROR is passed as an option which looks like an oversight. Change the code not to show the error if NO_UNSUPPORTED_PLATFORM_ERROR is passed. This means user projects can call qt6_generate_deploy_app_script for non-bundle apps without having to wrap the code in a if(NOT APPLE) check, and deployment will simply not run for that target on macOS. [ChangeLog][Build System] The qt6_generate_deploy_app_script NO_UNSUPPORTED_PLATFORM_ERROR option will now have an effect when calling the API on non-bundle macOS executable targets. Pick-to: 6.7 Change-Id: I932d6bfa2d3c7e2aaf8be967fea1f682eacf0112 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Add option to allow skipping app deployment when building in CIAlexandru Croitor2024-03-191-1/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We would like to add deployment api calls to all our examples. Doing that in the CI, where we build all examples, would mean running the deployment tools for each example. This takes time and space. Add the option to skip running deployment code by setting the QT_INTERNAL_SKIP_DEPLOYMENT variable. This can be set per-directory or at the root directory. In that case we will generate an install script that does nothing. With this option, we can ensure we run deployment for a few examples, but skip it for the rest. Also skip running the deployment api for non-prefix builds, because it only partially works. In such a case, show a warning. The warning can be hidden by setting the QT_INTERNAL_HIDE_NO_OP_DEPLOYMENT_WARNING variable. This might be revisited in the future. The newly introduced helper functions are also meant to be used in qtdeclarative. qtbase only uses one of them, because currently it does not contain POST_BUILD deployment logic. Pick-to: 6.7 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Task-number: QTBUG-102057 Change-Id: If5a4102137e9dfc4a8bfde7b26d511ed1700340e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Evaluate genexes for extra deploy file pathsAlexandru Croitor2024-03-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Since d08fa86e63448377dde4297bc94680a9d7daaaeb we add extra deploy files with target file information. The file paths contain a $<CONFIG> genex to handle multi-config builds. These were not evaluated in the DeploySupport file content. Add a TARGET_GENEX_EVAL genex around the TARGET_PROPERTY genex, to ensure they do get evaluated. This avoids an error like: include could not find requested file: C:/Users/qt/work/qt/qtbase_build/.qt/QtDeployTargets-$.cmake Amends d08fa86e63448377dde4297bc94680a9d7daaaeb Pick-to: 6.7 Task-number: QTBUG-117948 Task-number: QTBUG-118153 Change-Id: Ia3898c31d80b82bdb25fe733fc73b45c6d689ed0 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Check for qtpaths6.exe existence during windows deploymentAlexandru Croitor2024-03-151-1/+24
| | | | | | | | | | | | | | | | A qt installation might not contain the non-versioned the qtpaths.exe installed, but keep the versioned qtpaths6.exe. Try to use the versioned version before the non-versioned one. If none exists, show a warning at deployment time. Amends 571201603acc731330c9af42a3aca9cda41d38fd Pick-to: 6.5 6.6 6.7 Fixes: QTBUG-122664 Task-number: QTBUG-119619 Change-Id: I23caf9ed3c7928fbab9657b0c0c64517dfc7d68e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Warn when examples are not added via qt_internal_add_exampleAlexandru Croitor2024-03-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To ensure examples can be built as ExternalProjects, the example subdirectories need to be added via qt_internal_add_example rather than just add_subdirectory. qt_internal_add_example is also needed for correct installation of example sources. To catch examples that are still not added via qt_internal_add_example, set a QT_WARN_ABOUT_EXAMPLE_ADD_SUBDIRECTORY variable at the top of the examples/CMakeLists.txt directory scope and show a warning in qt_add_executable whenever that variable is TRUE. Calls of qt_internal_add_example will set the variable to FALSE, making sure the warning is not shown for properly added examples. This is limited to developer builds and can be opted out of via the QT_NO_WARN_ABOUT_EXAMPLE_ADD_SUBDIRECTORY_WARNING variable. qt_add_executable is used as the 'hook' for showing the error, because that is the most likely function to be used in examples. We don't use qt_standard_project_setup in all projects yet, so we don't want to use that one. Task-number: QTBUG-90820 Task-number: QTBUG-123096 Change-Id: I7a0b0b2cc60c70903db03b56c06494c127a62420 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Bring back renamed parameters for qt_standard_project_setupJoerg Bornemann2024-02-231-0/+10
| | | | | | | | | | | | | Resurrect the parameters I18N_LANGUAGES and I18N_NATIVE_LANGUAGE for now to allow integration of renaming changes that are a result of the Qt 6.7 CMake API review. Also, unblock dependency updates in qttools. These parameters will be removed once all dependencies have been updated throughout the repos. Fixes: QTBUG-122691 Change-Id: Id0bfba50c7b168c61457ddf02b89e3d2c785e02b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Default QT_I18N_SOURCE_LANGUAGE to "en"Joerg Bornemann2024-02-211-1/+4
| | | | | | | Pick-to: 6.7 Task-number: QTBUG-122396 Change-Id: I36c76211529e685aa1c85a7fb1b15667ad479185 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Rename I18N_*LANGUAGES variables and parametersJoerg Bornemann2024-02-211-6/+7
| | | | | | | | | ...according to the Qt 6.7 CMake API review. Pick-to: 6.7 Task-number: QTBUG-122396 Change-Id: I42012e346325ff05d63fa4dac44276eef15320fe Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix AUTORCC_OPTIONS INTERFACE_LIBRARY error with CMake 3.16Alexandru Croitor2024-02-151-1/+4
| | | | | | | | | | | | | | | Make sure not to set the AUTORCC_OPTIONS property on INTERFACE_LIBRARY targets, because it's not allowed with CMake versions lower than 3.18. Amends 329dbfcc78d067d26b5a4dd99f4284900fd68f2c Pick-to: 6.5 6.6 6.7 Fixes: QTBUG-122266 Task-number: QTBUG-106466 Task-number: QTBUG-101353 Task-number: QTBUG-121948 Change-Id: I9ab606c0b11e2b4f8689e0bde9c001f59c81fa42 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix undefined symbol: qt_resourceFeatureZstd issueAlexandru Croitor2024-02-071-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When cross-compiling, host rcc might generate zstd compressed resources, even though the target might not support zstd decompression. To avoid that, we made sure to disable zstd compression when using cmake api like qt_add_resources if the target platform does not support it. We did not do it for CMAKE_AUTORCC though. In such a situation, the linker would fail with: error: undefined symbol: qt_resourceFeatureZstd Add the --no-zstd option to AUTORCC_OPTIONS for targets that are created by Qt CMake public API like qt_add_executable and qt_add_library if the target platform does not support zstd decompression (check via the QT_FEATURE_zstd variable). This in turn applies to our own qt_internal_add_ API as well. Allow opting out via the QT_NO_AUTORCC_ZSTD CMake variable. [ChangeLog][Build System] Targets created with qt_add_executable and qt_add_library will now add the --no-zstd option to AUTORCC_OPTIONS when the target platform does not support zstd decompression. You can opt out via the QT_NO_AUTORCC_ZSTD cmake variable. Pick-to: 6.5 6.6 6.7 Fixes: QTBUG-121948 Task-number: QTBUG-106466 Task-number: QTBUG-101353 Change-Id: Ibdcfecd9a4b1e206479a3f4588b1b624dd91e122 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix *-metatypes.json creation, take IIIJoerg Bornemann2024-02-021-1/+1
| | | | | | | | | | Use the work-around for CMake issue #19005 for Makefile generators and Visual Studio projects. Pick-to: 6.7 6.6 6.5 Fixes: QTBUG-120317 Change-Id: I3d15f23937133a5dd4d1c2a88af0fc34d5608a77 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Introduce QTP0003 which controls the BUILD_SHARED_LIBS impact on user projectsAlexey Edelev2024-02-011-3/+24
| | | | | | | | | | | | | | | | | | | Since 6.7 we consider the BUILD_SHARED_LIBS when creating libraries using Qt CMake API. This change may affect the user projects that rely on the old strategy of selecting the default library type. To preserve the old behavior this change introduces the QTP0003 policy that allows user to control whether the BUILD_SHARED_LIBS should or shouldn't be considered in library creation process. The policy doesn't affect Qt repos, we assume that we want the NEW behavior by default. Fixes: QTBUG-121707 Pick-to: 6.7 Change-Id: I4bcfbd8966839731624e3f7ef9e0d6bb2782ac50 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
* Revert "CMake: Fix *-metatypes.json creation for non-Ninja generators"Alexandru Croitor2024-02-011-1/+1
| | | | | | | | | | | | | | This reverts commit ab6950acab5f799e5b3f097a87300e7c1dd1cf04. Reason for revert: It breaks test_qml_app_deployment test in qtdeclarative for iOS and Xcode Pick-to: 6.6 6.5 Fixes: QTBUG-121729 Task-number: QTBUG-120317 Change-Id: I356882a97f63534aa17133a4fbbb1db90295dfba Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 6aed870919feb565955d6d40e23337d98ff10e7a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix *-metatypes.json creation for non-Ninja generatorsJoerg Bornemann2024-01-261-1/+1
| | | | | | | | | | | | | | | This amends commit db9009721a11f482b601a228eb6d0e1658d997b0, which fixed the *-metatypes.json creation for Makefile generators. User feedback and the comments in the underlying CMake issue #19005 suggest that all non-Ninja generators are affected. Fix this by activating the work-around for all non-Ninja generators. Pick-to: 6.5 6.6 6.7 Fixes: QTBUG-120317 Change-Id: I537ff7be9c658b7053f7f5df6cbced460be43270 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* qt6_wrap_cpp: Add .moc generationOrkun Tokdemir2024-01-191-2/+47
| | | | | | | | | | | | | | | | | | | | | | | | When a `.moc` file is included in a source file and that source passed to `qt_wrap_cpp`, Users should add the generated `.moc`s path to the target's include path. Since we don't share anything about the output path of generated files by `qt_wrap_cpp`, it makes sense to add in inside `qt_wrap_cpp`. And also, the generated `.moc` file is added to target's source to complete the dependency graph. Otherwise, Users need to get output variable and pass it to target's sources. * Update docs * Add test [ChangeLog][Build System] qt_wrap_cpp will accept .cpp files from now on. When .cpp a file is passed to qt_wrap_cpp, TARGET parameter becomes required. Generated .moc files are added to target's sources inside qt_wrap_cpp. That's why the output parameter will not contain generated .moc files. Fixes: QTBUG-113402 Change-Id: I54dd2b1ff8e5c9ba457b1eb4f73b0a8190d9c659 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Improve folder structure for Xcode and Visual Studio projectsTor Arne Vestbø2024-01-181-0/+62
| | | | | | | | | | | | | | CMake has a built in file extension list for "Source Files", that does not include qml files. We can't extend that file list with a regex, so we need to add qml files individually as a finalization action. We also stuff generated files (both auto-gen as well as other generated files) into a separate source folder, to focus the project on the user's files. Pick-to: 6.7 Change-Id: Ic9a4d9daad088b1874bcf81e75c776537f3ff531 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Set AUTOGEN_BETTER_GRAPH_MULTI_CONFIGOrkun Tokdemir2024-01-171-3/+12
| | | | | | | | | | Since https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8919 is merged, `qtbase` should be updated accordingly. If `CMake` is equal or greater than `3.29`. `timestamp_$<CONFIG>` is used instead of `timestamp`. This commit reimplements 8041bfba47305352627d910930e52da496904c17 which is reverted with 4b1d96ea1b16e3eef2222de78677a4d99a87940f Change-Id: I335e3855c1a11c404202ae7b74f0c356b8fe53bd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
* cmake: Explicitly generate Xcode schemes for executables and libsTor Arne Vestbø2024-01-161-0/+14
| | | | | | | | | | | | | | | | | | Otherwise, Xcode will auto-generate schemes for all targets, including internal targets such as foo_autogen and build-only targets such as ZERO_CHECK and ALL_BUILD, choosing one of them at random when opening the project for the first time. If multiple targets get a scheme they will be sorted alphabetically. We could prioritize them by generating a xcschememanagement.plist file, but that would require teaching CMake about that feature. This aligns the CMake behavior with qmake, where we also generate schemes explicitly. Pick-to: 6.7 6.6 6.5 Change-Id: I3756fced37a4ff7792370da10fc49169cc271ae8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Mark auto-generated rcc files as generatedTor Arne Vestbø2024-01-161-0/+1
| | | | | | | | | Allows us to hide them in a separate folder in Xcode and Visual Studio projects. Pick-to: 6.7 Change-Id: I5ce7884ce50198c3b0c9654bb188f38a8a679be0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix *-metatypes.json creation for all makefile generatorsJoerg Bornemann2024-01-161-1/+1
| | | | | | | | | | | | | | | | | When using one of the non-Unix makefile generators ("NMake Makfiles JOM" or "MinGW Makefiles") then it possible to trigger an error when running qmltyperegistrar: ..._metatypes.json: illegal value We create the metatypes JSON file initially empty and then "fill" it with a custom command. This command is not triggered when using Makefile generators. See CMake upstream issue #19005. Our work-around for that issue was only triggered for the generator "Unix Makefiles". Now, it's triggered for all makefile generators. Fixes: QTBUG-120317 Change-Id: I329cb0d3e9ba0997d618821e7bcbc20284561419 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Disable AUTOGEN for resource object targetsAlexey Edelev2024-01-081-0/+5
| | | | | | | | | | | | | | | | It looks like resource object targets don't need AUTOMOC as well as other AUTOGEN tools. The only source file skips autogen explicitly, but AUTOMOC requirement is added to the resource object targets anyway. This disables all AUTOGEN related properties explicitly for all resource object targets. The problem occurs when building top-level Qt with the static library that uses resources in tree. Pick-to: 6.2 6.5 6.6 6.7 Change-Id: I5c968a3e34c881e7fbc5589626ab02b3b1e53968 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Add QT_DEPLOY_LIBEXEC_DIRJoerg Bornemann2023-12-181-0/+3
| | | | | | | | | | | | | [ChangeLog][CMake] Added the deployment variable QT_DEPLOY_LIBEXEC_DIR. This variable can be used in CMake deployment scripts to install helper binaries of a project. In particular, this directory is going to be used for deploying the QtWebEngineProcess executable. Pick-to: 6.7 Task-number: QTBUG-119077 Change-Id: Ia2502af696c53943ad13e3944c8debf2dfd8daee Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Prepare deployment of projects using QtWebEngineJoerg Bornemann2023-12-181-0/+2
| | | | | | | | | | | | | Store the locations of INSTALL_DATA and INSTALL_LIBEXECS in .qt/QtDeploySupport.cmake which is generated for every project. This information will be used to locate the helper binary and resources of QtWebEngine. Pick-to: 6.5 6.6 6.7 Task-number: QTBUG-119077 Change-Id: I2fb6f9b31fd1dcd872365d020c8ac71db426fdec Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Deploy correct arch files when cross-compiling to arm WindowsAlexandru Croitor2023-12-171-0/+15
| | | | | | | | | | | | | | | | | | When cross-compiling a user project from x86_64 to arm64 MSVC Windows target, during deployment we need to deploy arm libraries. By default because we use an x86_64 windeployqt, it always deploys x86_64 libraries. Make sure to pass the path to the target WoA qtpaths.bat file to windeployqt, so it deploys arm libraries. Pick-to: 6.5 6.6 6.7 Fixes: QTBUG-119619 Change-Id: Ib3b5498ae906726d1f9e0919333c102898b48ea9 Reviewed-by: 🌴 Alexey Edelev 🌴 <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* CMake: Add a way to pass additional arguments to win/macdeployqtJoerg Bornemann2023-12-071-0/+1
| | | | | | | | | | | | | | [ChangeLog][CMake] Added the DEPLOY_TOOL_OPTIONS argument to the functions qt_generate_deploy_app_script and qt_deploy_runtime_dependencies. It doesn't make sense to map every option of the deployment tools to arguments in our CMake deployment API. Allow the user to specify extra arguments to windeployqt or macdeployqt. Task-number: QTBUG-116551 Change-Id: I4cc67ab03f19101b695281e8c80f8af825bab7f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix generation of target deployment informationJoerg Bornemann2023-12-071-0/+1
| | | | | | | | | | | | | | | | The _qt_internal_write_target_deploy_info function doesn't clear its result variable, which is why we had left-over elements in the targets variable. Some of these left-overs have a target type that's not compatible with TARGET_RUNTIME_DLLS, leading to the CMake error: Objects of target "lib1" referenced but is not one of the allowed target types (EXECUTABLE, SHARED, MODULE).". Fix this by clearing the targets variable initially. Fixes: QTBUG-119792 Change-Id: I921aa2f0af72638ed0ed7434450a43c66c1fc9f1 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Generate deployment information for each deployable targetJoerg Bornemann2023-12-041-0/+32
| | | | | | | | | | | | | | | | | | When using CMake 3.19 or newer, we generate a .qt/QtDeployTargets.cmake file per project. This contains the following information for each deployable target: 1. The full path to the produced artifact. This will allow us to avoid the file name heuristics when deploying QML plugins. 2. The DLLs that are needed at runtime, when using CMake 3.21 or newer on Windows. This will allow us to deploy QML module backing libraries and runtime DLLs of to-be-deployed targets. Task-number: QTBUG-117948 Task-number: QTBUG-118153 Change-Id: I8a670e44f62a872f1a21174e947d87ccb8191073 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Revert "CMake: Update timestamp file for `Multi-Config` and `Cross-Config` ↵Orkun Tokdemir2023-10-161-17/+3
| | | | | | | | | | | | builds" Since https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8878 is reverted, the related change in `qtbase` also should be reverted. This reverts commit 8041bfba47305352627d910930e52da496904c17 and 7a87149c25e04f5f1cbb786fd3b8f78e94574551 Change-Id: Iae42755ffc7b2c97e9cda4c211319df767a421b0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Update timestamp file for `multi-Config` buildsOrkun Tokdemir2023-10-131-1/+1
| | | | | | | | | | | | | | | | | | | Since https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8840 is merged, the timestamp file for {target}_json_file.txt should be updated for `multi-config` builds too. A possible error message before this commit when `qt6_extract_metatypes()` is called with a newer or equal version than `3.28` `CMake` and `Ninja Multi-Config`. ``` ninja: error: 'src/corelib/Core_autogen/timestamp', needed by 'src/corelib/meta_types/Core_json_file_list.txt', missing and no known rule to make it ``` Amends 8042bfba47305352627d910930e52da496904c17 Pick-to: 6.2 6.5 6.6 Change-Id: Ib404bd058d5f4c75501fb714c2ad9608d6852822 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Update timestamp file for `Cross-Config` buildsOrkun Tokdemir2023-09-281-3/+17
| | | | | | | | | | | | | | | | Since https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8564 is merged, the timestamp file for {target}_json_file.txt should be updated for `Cross-Config` builds. The actual error message before this commit when CMake 3.28 is used: ``` ninja: error: 'src/corelib/Core_autogen/timestamp', needed by 'src/corelib/meta_types/Core_json_file_list.txt', missing and no known rule to make it ``` Pick-to: 6.2 6.5 6.5.3 6.6 6.6.0 Change-Id: Ib544b18b67d2d4722f3801b1f46a0e0e18e59d48 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Store info about the debug build in QtDeploySupport.cmakeJoerg Bornemann2023-09-261-0/+14
| | | | | | | | | | | | | | Application deployment must know whether the Qt installation is a debug_and_release build - or more generally, a multi-config build with a debug configuration. Store the following information in QtDeploySupport.cmake that's read at installation time: - whether Qt was built multi-config with a debug configuration - the postfix for debug libraries Task-number: QTBUG-109444 Pick-to: 6.5 6.6 Change-Id: I96a2120ba1a2b03125661cc829498653e37dfb0f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Add I18N_NATIVE_LANGUAGE keyword to qt_standard_project_setupJoerg Bornemann2023-09-211-0/+4
| | | | | | | | | | | | | | [ChangeLog][CMake] Added variable QT_I18N_NATIVE_LANGUAGE to specify the native language that is used in the source code for translatable strings. [ChangeLog][CMake] Added keyword I18N_NATIVE_LANGUAGE to qt_standard_project_setup to conveniently set QT_I18N_NATIVE_LANGUAGE. Task-number: QTBUG-115845 Change-Id: I079256507685afe5eccda78beffff819292494bf Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add I18N_LANGUAGES keyword to qt_standard_project_setupJoerg Bornemann2023-09-191-1/+8
| | | | | | | | | | | | | | | | | | | | | | [ChangeLog][CMake] Added variable QT_I18N_LANGUAGES to specify the languages that are used for i18n in the project. [ChangeLog][CMake] Added keyword I18N_LANGUAGES to qt_standard_project_setup to conveniently set QT_I18N_LANGUAGES. The call qt_standard_project_setup(I18N_LANGUAGES hi ho) sets the variable QT_I18N_LANGUAGES. The target finalizers use this variable to set up CFBundleLocalizations on Apple platforms. qt_add_translations will be extended to read QT_I18N_LANGUAGES as well to determine the names of .ts files if TS_FILES is not given. Fixes: QTBUG-116716 Change-Id: I76f0753d10efb9c32947d9239e43382c9d85eb51 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
* CMake: Enable depfile for Makefiles generatorsOrkun Tokdemir2023-09-131-2/+9
| | | | | | | Since https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8570 introduces AUTOMOC to use depfile with the Makefile generators, the depfile usage can be enabled for them in qtbase. Change-Id: Ie18460fd2c4703ad75eb88662445ebe961d4e895 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* _qt_internal_create_moc_command: Fix genex parseOrkun Tokdemir2023-08-171-2/+13
| | | | | | | | | The function was replacing the `>` character in generator expressions coming from `add_compile_definitions`. This was creating generator expression syntax errors. Discard generator expressions from character replacing. Add tests for the three cases. Fixes: QTBUG-111717 Change-Id: I694d2908738085fdf15112834f20183a9f393422 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Place resources into static libraries, not object librariesAlexandru Croitor2023-08-141-3/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Take 2. Re-land previously reverted commit, due to not handling resource names that are not valid c++ identifiers. Now we sanitize the resource names just like rcc does by replacing non-alphanumeric characters with underscores. Original commit message. During the Qt 5 -> Qt 6 and qmake -> CMake porting time frame, it was decided to keep resources in an object file (object library), rather than putting them directly into a static library when doing a static Qt build, so that the build system can take care of linking the object file directly into the executable and thus not forcing project developers to manually initialize resources with the Q_INIT_RESOURCE() macro in project code. This worked for most qmake and cmake projects, but it created difficulties for other build systems, in the sense that these projects would have to manually link to the resource object files, otherwise they would get link time errors about undefined resource symbols, assuming they kept the Q_INIT_RESOURCE() calls. If the project code didn't contain Q_INIT_RESOURCE calls, the situation would be even worse, the linker would not error out, and the missing resources would only be discovered at runtime. It's also an issue in CMake projects that try to link to the library files directly instead of using the library target names, which means the object files would not be automatically linked in. Many projects try to do that because we don't yet offer a convenient way to install libraries and reuse them in other projects (the SDK case), so projects end up shipping only the libraries, without the resource object files. We can improve the situation by moving the resources back into their associated static libraries, and only keeping a static initializer as a separate object file / object library, which references the actual resource initializer symbol, to ensure it does not get discarded during linking. This way, projects that link using targets get no behavior difference, whereas projects linking to static libraries directly can still successfully build as long as their sources have all the necessary Q_INIT_RESOURCE calls. To ensure the resource symbols do not get discarded, we use a few new private macros. We declare the resource init symbols we want to keep as extern symbols and then assign the symbol addresses to volatile variables. This prevents discarding the symbols with the compilers / linkers we care about. It comes at the cost of an additional static initializer per resource, but we would get the same + a bigger performance hit if we just used Q_INIT_RESOURCE twice (once in the object lib and once in project code), which internally needs to traverse a linked list of all resources to check if a resource was initialized or not. For GHS / Integrity, we also need to use a GHS-specific pragma to keep the symbols, which we currently use in qtdeclarative to ensure qml plugin symbols are not discarded. The same macros will be used in a qtdeclarative change to prevent discarding of resources when linking to static qml plugins. A cmake-based test case is added to verify that linking to static libraries directly, without linking to the resource initializer object libraries, works fine as long as the project code calls Q_INIT_RESOURCE for the relevant resource. This reverts commit bc88bb34caf1185a25eda77ee022843c0ca988b0. Fixes: QTBUG-91448 Task-number: QTBUG-110243 Change-Id: Idce69db0cf79d3e32916750bfa61774ced977a7e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Revert "CMake: Place resources into static libraries, not object libraries"Alexandru Croitor2023-08-091-39/+3
| | | | | | | | | | This reverts commit ce8874fc3b0bab2066080315c8774b30c038862c. Reason for revert: Doesn't handle resource names that are invalid identifiers Change-Id: Idf24bd9797284ce9de382a8e233d56c799a09099 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Consider BUILD_SHARED_LIBS when adding libraries using _qt_internal_add_libraryAlexey Edelev2023-08-041-1/+1
| | | | | | | | | | | | | | | | | It does look safe to consider the value of BUILD_SHARED_LIBS in _qt_internal_add_library. Current behavior might confuse users that specify BUILD_SHARED_LIBS explicitly but get the library types according to Qt build type. [ChangeLog][CMake] qt6_add_library now considers the value of the BUILD_SHARED_LIBS variable. If the variable is DEFINED it has higher priority than the library type detecting logic in qt6_add_library when adding the library targets. Change-Id: I1c40e887c4e481424a596c870a8ff2784b08fcbb Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Place resources into static libraries, not object librariesAlexandru Croitor2023-08-041-3/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the Qt 5 -> Qt 6 and qmake -> CMake porting time frame, it was decided to keep resources in an object file (object library), rather than putting them directly into a static library when doing a static Qt build, so that the build system can take care of linking the object file directly into the executable and thus not forcing project developers to manually initialize resources with the Q_INIT_RESOURCE() macro in project code. This worked for most qmake and cmake projects, but it created difficulties for other build systems, in the sense that these projects would have to manually link to the resource object files, otherwise they would get link time errors about undefined resource symbols, assuming they kept the Q_INIT_RESOURCE() calls. If the project code didn't contain Q_INIT_RESOURCE calls, the situation would be even worse, the linker would not error out, and the missing resources would only be discovered at runtime. It's also an issue in CMake projects that try to link to the library files directly instead of using the library target names, which means the object files would not be automatically linked in. Many projects try to do that because we don't yet offer a convenient way to install libraries and reuse them in other projects (the SDK case), so projects end up shipping only the libraries, without the resource object files. We can improve the situation by moving the resources back into their associated static libraries, and only keeping a static initializer as a separate object file / object library, which references the actual resource initializer symbol, to ensure it does not get discarded during linking. This way, projects that link using targets get no behavior difference, whereas projects linking to static libraries directly can still successfully build as long as their sources have all the necessary Q_INIT_RESOURCE calls. To ensure the resource symbols do not get discarded, we use a few new private macros. We declare the resource init symbols we want to keep as extern symbols and then assign the symbol addresses to volatile variables. This prevents discarding the symbols with the compilers / linkers we care about. It comes at the cost of an additional static initializer per resource, but we would get the same + a bigger performance hit if we just used Q_INIT_RESOURCE twice (once in the object lib and once in project code), which internally needs to traverse a linked list of all resources to check if a resource was initialized or not. For GHS / Integrity, we also need to use a GHS-specific pragma to keep the symbols, which we currently use in qtdeclarative to ensure qml plugin symbols are not discarded. The same macros will be used in a qtdeclarative change to prevent discarding of resources when linking to static qml plugins. A cmake-based test case is added to verify that linking to static libraries directly, without linking to the resource initializer object libraries, works fine as long as the project code calls Q_INIT_RESOURCE for the relevant resource. Fixes: QTBUG-91448 Task-number: QTBUG-110243 Change-Id: I39c325aac91e36d53c3576a39f881949c3b21e3f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Fix installed metatypes not being propagated to other reposAlexandru Croitor2023-07-241-3/+1
| | | | | | | | | | | | | | | | | | | | | The install-time code path that's supposed to propagate and install the metatypes files was never executed, because of a wrong PARENT_SCOPE assignment and because the code was overriding the meta type file name retrieved from a property with an empty non-existent argument. This caused build failures in qtdeclarative when qmlcachegen generated invalid cpp code without having access to the qtbase foreign types. This only happened in prefix builds. Use the appropriate variable for the PARENT_SCOPE assignment and remove the incorrect file name assignment. Amends c45c32af32e5b7501065f294de67a5e6a3d1f62a Task-number: QTBUG-115152 Change-Id: I120d53d44382a1ac6f62792ec1620add3e7b136c Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
* CMake: Fix error in qt_generate_deploy_app_scriptJoerg Bornemann2023-07-131-1/+6
| | | | | | | | | | | | | | | | ...when using a Qt cross-built for embedded Linux and NO_UNSUPPORTED_PLATFORM_ERROR set. Attempting to install such a project will now give the following output: -- Skipping runtime deployment steps. Support for installing runtime dependencies is not implemented for this target platform (Linux, shared Qt libs, cross-compiled). Pick-to: 6.5 6.6 Fixes: QTBUG-114069 Change-Id: Idd2af2135d2ca3cc0e5eeafb7701e891f8a0cc25 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Expose metatypes internal functions for further use in qmlAlexandru Croitor2023-07-121-36/+172
| | | | | | | | | | | | | Extract the code that propagates metatypes files into separate functions, so that they can be used in the qml api to propagate a qml module backing library's metatype file to its associated plugin. It's a bit messy due to the tech debt around installation, but the behavior of the code in qtbase should not change. Task-number: QTBUG-115152 Change-Id: I85dfcc4c76e9c41239dc0380920e68a3a6400815 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-07 02:55:52 +0000