summaryrefslogtreecommitdiffstats
path: root/src/corelib/Qt6CoreMacros.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Collect the apk dependencies regardless of targetAlexey Edelev2022-01-041-1/+1
| | | | | | | | | | | | | | | | | | | | _qt_internal_collect_target_apk_dependencies function is common for all targets, but its signature was telling that it's target-specific. This also causes an issue when we had more than one target in tree that produce apk, since only first target got the property after respective finalizer was executed. This change generalize the function and uses _qt_internal_apk_dependencies target to store the extra library directories from the build tree. _qt_internal_add_android_deployment_list_property signature is also changed to support reading values from multiple lists of multiple targets. Amends d20f4ae706559fb7de8db9dd4845f7ce3936061a Pick-to: 6.3 Change-Id: I5b40fa96a0eb73348c0029e2b13c63a9465cb520 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Replace ANDROID_ABI argument with the QT_ANDROID_ABI target propertyAlexey Edelev2022-01-031-104/+4
| | | | | | | | | | | | | | | | | | | | | | This change tries to make the API more user friendly and prevent wrong use of multi-abi API. ANDROID_ABI argument of qt6_add_executable was position-depend and needed to be placed after the executable 'sources'. Using the target property we solve this problem and provide more consistent and common way to enable multi-abi build for the single target. This meanwhile also requires to execute multi-abi build configuration in the finalizer, since the property might be set at any point. Also the priority of the QT_ANDROID_ABI target property now is higher than the priority of the QT_ANDROID_BUILD_ALL_ABIS variable. So target will only build packages with the ABIs specified in QT_ANDROID_ABI property if both are set. Pick-to: 6.3 Task-number: QTBUG-88841 Change-Id: I3515297ed267974498913c59619433dc234ec217 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Mark the new deployment API as being in Technical PreviewAlexandru Croitor2021-12-091-0/+4
| | | | | | | | Amends 22c92f39670d0376478cc2e73a17307508f86692 Task-number: QTBUG-98545 Change-Id: Ifaa7e4884f0eb1caa6d3d4906a2701f8fa5e43c2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Fall back to include() method for finalizers with CMake 3.17 or earlierCraig Scott2021-12-081-5/+9
| | | | | | | | | | | | | | | | Functionality is being added in other repos which require finalizers to be run for non-static builds. That means we now need to ensure finalizers always run even with CMake versions before cmake_language() was added. The fallback method of writing to a file and including it is slower, but that's better than missing important functionality altogether. Task-number: QTBUG-98545 Pick-to: 6.2 Change-Id: Ic8668c91c26d0c30de084b1b803032088c10fcf4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add CMake deployment supportCraig Scott2021-12-081-0/+315
| | | | | | | Task-number: QTBUG-98545 Change-Id: I581c1173cdfc92c09fd2cf0bbe7ec6bc8d52b868 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix dependency chain that collects the metatype json filesAlexey Edelev2021-12-021-1/+8
| | | | | | | | | | | | | | | | | | | | | cmake_automoc_parser has the logic preventing the run of moc with the --collect-json parameter if metatype json files are not changed. This logic only verify if the file list is changed but not their content. This change adds a timestamp file that contains the last metatype json file timestamp that was modified during the last cmake_automoc_parser run. The logic still prevents of running 'moc --collect-json' when the list of metatype json files is not changed, but also checks if their content is no changed. Another approach it to generate the depfile that can be utilized by CMake in add_custom_command as DEPFILE argument. But this concept only works from the second build attempt because of an issue related to dyndep. Pick-to: 6.2 Fixes: QTBUG-98532 Change-Id: I713f8bfa9ae769cefe0beac0b7fa19750b00a765 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Change the external projects approach for multi-abi buildsAlexey Edelev2021-12-021-17/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of generating external projects that build the project tree for each target, this creates a single project for each ABI that have the common for all targets configure steps. Each executable target then adds additional build step to each ABI-specific external project, that builds and copies dependencies to the "main" project build tree. To resolve dependencies from the build tree, when building multi-abi apk instead of scanning the build directories of external projects for dependencies, it makes sense to run androiddeployqt for each ABI-specific external project to copy all necessary libraries. This is done by adding --copy-dependencies-only flag to androiddeployqt that only copies the apk dependencies, but avoids creating apk and all the essential steps. The ABI-specific external project now handles the deploying of the build artifacts to the end-point apk deployment directory and the "main" project assembles the apk using collected artifacts. The ABI-specific external project uses the qt_internal_${target}_copy_apk_dependencies target to run androiddeployqt with the introduced --copy-dependencies-only flag. TODO: Build steps that build and copy the ABI-specific apk dependencies are non-skipable and will run each time top-level build is triggered. This behavior should be fixed by adding dependencies to the generated by androiddeployqt DEPFILES for each ABI in the top-level build. Task-number: QTBUG-88841 Tash-number: QTBUG-94714 Change-Id: Id442a9fbd589f58b70f4204c5215645056b379a2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Use config from the main ABI when building ABI-specific external projectAlexey Edelev2021-12-011-0/+9
| | | | | | | | | | ABI-specific external projects should use the same config as the one is used by the "main" ABI. Task-number: QTBUG-88841 Change-Id: If7a1834d9a3f238f6dadd05323ccc0cf8552128c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Make sure that all plugin targets are built before deploying to AndroidAlexey Edelev2021-11-051-0/+7
| | | | | | | | | | | | | | | | | | | We need to make sure that all plugin targets are built and present on the file system before running androiddeployqt. This especially important when building executables that depend on qml modules that are built in the project tree. This adds meta target that collects all the plugin targets as dependencies and adds this meta target as the dependency for the custom target that executes androiddeployqt. TODO: We should also take into account MODULE libraries that were added using the CMake add_library call, but since qt6_finalize_project is not a part of 6.2 API, this will be added in follow up commit. Pick-to: 6.2 Task-number: QTBUG-94714 Task-number: QTBUG-88841 Change-Id: I4b4596eb8ed364dbe80e2cfb0ce31cec32e7c03f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Suppress rc.exe default outputKai Köhne2021-11-041-2/+10
| | | | | | | | | | | | | | Hide output like Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384 Copyright (C) Microsoft Corporation. All rights reserved. when building the auto-generated .rc files. Pick-to: 6.2 Fixes: QTBUG-97729 Change-Id: Id0c32c8015ec2ac0b47b3add52d5c0f8a7a1c203 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove WIN32 and MACOSX_BUNDLE arguments when building Android binaryAlexey Edelev2021-10-201-1/+1
| | | | | | | | | | This fixes the regression introduced in Android multiabi changes. Amends 0a02d845559e4fd9d1bd72942c5118f3bb1307bf Task-number: QTBUG-88841 Change-Id: I09e129361eb760cdc14c2302e821ce4fcbf117c3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix adding generated resources on iOS with CMake and XcodeMike Achtelik2021-10-121-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When adding resources generated via a custom command, the project fails to configure when targeting iOS with CMake and Xcode with the error: CMake Error in src/CMakeLists.txt: The custom command generating src/.qsb/TestShader.frag.qsb is attached to multiple targets: TestApp_other_files TestApp but none of these is a common dependency of the other(s). This is not allowed by the Xcode "new build system". This happens e.g. when using qt6_add_shaders, which adds a custom command to generate the qsb files. Or by simply adding resources via qt6_add_resources, which depend on a custom command. The problem is that qt6_add_resources also adds the resource to a second "fake" target ${target}_other_files via _qt_internal_process_resource and _qt_internal_expose_source_file_to_ide. See c7d1874cd16ce86dfbab319e44fe3a387378fdff. Since these targets do not have a common dependency CMake fails to configure the project. So lets fix it similar to change 1bd0a5ce02352a600367beb5a5421c8f8332e1fe and let the ${target}_other_files depend in the main ${target}. Pick-to: 6.2 Task-number: QTBUG-95763 Change-Id: Iecdb40993a91da8bfbf6553892f9b0722d2e886c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* corelib: Fix typos in source code commentsJonas Kvinge2021-10-121-3/+3
| | | | | | Pick-to: 6.2 Change-Id: Ic78afb67143112468c6f84677ac88f27a74b53aa Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Add basic android multi-abi support for CMake projectsAlexey Edelev2021-10-051-2/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use CMake external project to crosscompile android libraries for mutliple android ABIs at the same time. The idea behind is to use pre-compiled Qt for each android ABI in external projects, compile libraries and then utilize results of compilation in common androiddeployqt call. By default multi-abi build uses the main ABI that qt toolchain file belongs to. The list of the autodetected Qt for Android ABIs is stored in QT_DEFAULT_ANDROID_ABIS cache variable. Users may change the set of the Android ABIs project-wide using QT_ANDROID_ABIS CMake variable or for the specific target by adding the ANDROID_ABIS argument when calling qt6_add_executable. To enable build for the autodetected ABIs user may set the QT_ANDROID_BUILD_ALL_ABIS option to TRUE. By default build procedure is looking for the respective android_<abi> folders to run per-abi build. If user's Qt for Android folder structure is different then one is created by Qt installer, path to the each Qt for Android might be overwritten using QT_PATH_ANDROID_ABI_<abi> CMake variable. Note: This only adds support for the multi-abi build of user's applications. TODO: This commit limits projects to not have in-tree library dependencies. That means that executable targets may have dependencies only from Qt directories or android sysroots. See QTBUG-94714 for details. [ChangeLog][Android][Platform Specific Changes] Added basic support for multi-abi builds of user projects. Task-number: QTBUG-88841 Change-Id: I3239ffe61e6b437e170c8decc5c36a9e774ed0fb Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Add docs for qt_extract_metatypes()Craig Scott2021-09-241-20/+7
| | | | | | | | | | | Also tidy up the inline TODO comments to reduce duplication and address some minor inconsistencies. Task-number: QTBUG-95712 Pick-to: 6.2 6.2.0 Change-Id: Ic0d27f3c0a356fd311bba95de967faaea05e0f0a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add docs for qt_set_finalizer_mode()Craig Scott2021-09-241-20/+0
| | | | | | | | | Task-number: QTBUG-95712 Pick-to: 6.2 6.2.0 Change-Id: Ie7b9282cfc6a27415db5e623a66317c9681c3991 Reviewed-by: Luca Di Sera <luca.disera@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add docs for qt_add_plugin()Craig Scott2021-09-231-4/+2
| | | | | | | | Task-number: QTBUG-95712 Pick-to: 6.2 6.2.0 Change-Id: Ifdc10c7714e91f6211a52bd5c46b3140485bbb43 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Add docs for qt_allow_non_utf8_sources()Craig Scott2021-09-211-3/+0
| | | | | | | Task-number: QTBUG-95712 Pick-to: 6.2 6.2.0 Change-Id: Ie09785ced5b2bf8098ccff3467f32244f32f9195 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add docs for qt_disable_unicode_defines()Craig Scott2021-09-211-1/+0
| | | | | | | Task-number: QTBUG-95712 Pick-to: 6.2 6.2.0 Change-Id: I37a50d9e8a62c7d9c30014692d99ffe2eb9b90fb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add option in qt6_wrap_cpp to output a metatypes json fileAlexandru Croitor2021-09-181-5/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | At the moment only the Qt internal qt_manual_moc function allows manually running moc and generating a metatypes json file. There is no such functionality available in the public qt6_wrap_cpp and qt6_generate_moc functions. Change qt6_wrap_cpp to accept a new internal option called __QT_INTERNAL_OUTPUT_MOC_JSON_FILES to allow creating and retrieving the associated json file with metatypes information. This is needed to fix qtremoteobjects CMake API which needs to run moc manually and process the metatypes json file. The option is internal because we don't want to introduce new API in 6.2.0. Task-number: QTBUG-95832 Change-Id: Ic8dd27fc960c3f8dea8c101dfc028db45494953d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 90e7d6db1bb44de3629ec2b70df26fbafe4294fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Ensure _qt_is_android_executable is set for internal executables tooCraig Scott2021-09-171-1/+1
| | | | | | | | | | | | | | | | | The _qt_is_android_executable property is normally set by the _qt_internal_create_executable() command. But various other internal commands don't route through that and go through qt_internal_add_executable() instead. The former is used only by the public API, the latter only by the internal API. Refactor both so that the internal one calls the public one. This ensures all targets receive the same base settings, including the _qt_is_android_executable property. Fixes: QTBUG-96085 Pick-to: 6.2 Change-Id: I157356872c9d942d7be5f1abbbcbac97961b1f40 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Allow finalizers to be delayed to later in the same directory scopeCraig Scott2021-09-161-0/+27
| | | | | | | | | | | | | | | | | | | | Deferred CMake calls are executed in the order they are created. Sometimes, a deferred call created after a call to qt_add_executable() or qt_add_library() needs to be executed before target finalization. For example, a file may be written using a deferred write, but the finalizers might need that file to exist. Provide an internal _qt_internal_delay_finalization_until_after() command that can be called to let finalization know it has to defer to later. Target finalizers will check an internal property for IDs recorded by that command and will re-defer itself if it detects that any of those haven't run yet. Task-number: QTBUG-96290 Pick-to: 6.2 Change-Id: Ia791e99339bab351eff0d675a552393e524490e8 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Support deploying of libraries from a build tree when building android apkAlexey Edelev2021-09-091-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | If the project consists of an executable and multiple libraries that are linked to the executable, currently you need to specify them manually using QT_ANDROID_EXTRA_LIBS target property. This automates deploying of the libraries that are a part of the project build tree. _qt_internal_collect_target_apk_dependencies collects all the known non-imported shared libraries from the project build tree. When running androiddeployqt we specify extra library directories that point to the collected library locations in build tree, to help androiddeployqt resolve shared libraries that are build as a part of the project. The described procedure is running automatically if CMake version is greater than or equal to 3.18 is. For the CMake versions less than 3.18 users need to call a new public qt_finalize_project function at the end of project's top-level CMakeLists.txt Task-number: QTBUG-94714 Change-Id: I400ca4e49e940cfc25ae90d65372e79825bee55a Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Remove inline docs for qt_import_plugins() to avoid duplicationCraig Scott2021-09-101-19/+0
| | | | | | | | | | | | | | | Don't maintain two copies of the docs for qt_import_plugins() in separate places. Remove the inline docs because they are not the canonical ones that the user docs contain. Also remove the TODO and qml plugins. Those are now handled by a separate command, qt_import_qml_plugins(). Add a "see also" link to assist in discoverability. Task-number: QTBUG-95712 Pick-to: 6.2 6.2.0 Change-Id: I3bb872f77a1b57fd5f2f4fe1355625c47e44a351 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Collect QT_QML_ROOT_PATH based from the project resourcesAlexey Edelev2021-09-091-0/+6
| | | | | | | | | | | | Use the _qt_internal_collect_qml_root_paths function to collect qml files from the resources. The function is called only if Qml module is found. Pick-to: 6.2 Task-number: QTBUG-93340 Change-Id: I2b5f51e3d7fb8aa82f46e88b2aac5e52bf0930d5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Clean up duplicated code blockCraig Scott2021-09-081-3/+0
| | | | | | | | | | | | | Two separate changes addressed the OUTPUT_TARGETS variable not being set in the calling scope of _qt_internal_process_resource() for a particular code path, but they did so at different places. Remove one of them, since we don't need both. Pick-to: 6.2 Change-Id: Ibc1052e886ec73a99231ada3b7a1bb9e7a873cc4 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Fix dependencies on sources generated in a different scope to targetCraig Scott2021-09-081-6/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | In certain situations, a file generated by add_custom_command(OUTPUT) may be added as a source to a target defined in a different directory scope. That makes its GENERATED source property not visible to the target for CMake versions before 3.20. For 3.20 and later, policy CMP0118 can make the generated state of a source file global, but that policy is under the control of the user project, since its value at the end of the target's directory scope is what is used. Therefore we can force that global visibility using CMP0118. With CMake 3.18 or later, we can set source properties in arbitrary scopes, which allows us to force visibility in the scopes we need it. Use that for all CMake versions 3.18 and later to make the source file properties visible to the target. Making the generated state of a source file visible to the target isn't enough on its own. In the scope that the file is generated, there must be a target that depends on the file or else CMake won't set up the necessary dependencies to ensure that generation happens before the target tries to use it. Add targets in the generated file's own scope where we currently might not do that. Task-number: QTBUG-95200 Pick-to: 6.2 Change-Id: Ic1dfca1a193041de01d7f903b79473b9d47f1d1d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix cases of output variables not being passed back to calling scopeCraig Scott2021-09-061-2/+26
| | | | | | | | | | | | | | | | | | | | | Some versionless wrappers were not passing back output variables to their calling scope. Ensure they always are. Fix qt6_extract_metatypes() to set its output variable in the parent scope (it was previously setting it erroneously in the local scope). Some functions had code paths that would not set output variables. This would allow situations where if the variables had an initial value set by a higher up parent scope, the output variable would still have that value in the caller's scope upon return. That could be misleading, so fix these code paths to explicitly set the output variable to an empty string instead. Task-number: QTBUG-96121 Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: I291775813f025cabdccd4372ac077cdfd3ec090e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Revert "Ensure versionless wrappers do not introduce a new variable scope"Craig Scott2021-09-061-36/+41
| | | | | | | | | | | | | This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Clean up output target handling left behind by earlier changesCraig Scott2021-09-021-8/+6
| | | | | | | | | | | | | | | | | | Previous work removed the no-longer-used code path that could add targets from qml compiler features. The variable that code path would populate was not fully cleaned up in that removal. Clean it up now and move the variables related to output target handling closer to the only remaining area where they could be generated. Also ensure that we set the variable named by OUTPUT_TARGETS even if isBinary ends up being true. We should explicitly set that variable to an empty string in that case. Amends 363df5cd709762c3c014132c1670fdd715233620 Pick-to: 6.2 Change-Id: I17de9788b390aac9a7aedb29ab9bdfee99c305af Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Ensure versionless wrappers do not introduce a new variable scopeCraig Scott2021-08-311-41/+36
| | | | | | | | | | | | | | Using function instead of macro prevented the wrappers from being able to pass back any variables set in the wrapped function. In some cases, these variables were being explicitly passed back to the caller, but that isn't needed if you just make each wrapper a macro. This also makes things more future-proof because any newly introduced output variables will work without having to update the wrappers. Task-number: QTBUG-96121 Pick-to: 6.2 Change-Id: Ic4486de668694c06b47e466587b2cdcb969ea047 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix automatic iOS bundle id extractionAlexandru Croitor2021-08-241-1/+1
| | | | | | | | | | | | | | | | | | If no Xcode preferences file was found, _qt_internal_get_ios_bundle_identifier_prefix accidentally assigned the error output of running PlistBuddy to the bundle id property. That resulted in a bundle id called '${team_id}.Doesn't Exist, Will Create: /Users/qt/Library/Preferences/com.apple.dt.Xcode.plist\n.app' Check that the error variable is empty before assigning. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.1 6.2 Task-number: QTBUG-95838 Change-Id: I3a7241528590ae3e9986cfa1f3e91ac983ef54f6 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Create plugin initializers for static user pluginsAlexandru Croitor2021-08-241-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we only created object library static plugin initializers for Qt plugins only, not user-project plugins. The reason was that if a user tried to install the plugin target via an export set, CMake would error out saying that the _init library is not part of the same export set. Introduce an OUTPUT_TARGETS option that would allow projects to get the name of the generated _init target, so they can install it if needed. This was already done for qt6_add_qml_module, so we just introduce the same option for qt6_add_plugin. Now user static plugins will have an _init target created, which will be propagated to consumers whenever the consumers link against the plugin itself. We also need an internal option to disable this propagation, because it's handled a bit differently for Qt plugins which can be linked either via finalizers or via usage requirements. Amends 91c65dd80cdd2de666448c14202c0c63718152b6 As a result of the implementation change, cleanup example projects to ensure that they build successfully (the important part is specifying the CLASS_NAME). Only plugandpaint works properly with both shared and static Qt builds. echoplugin works with a shared Qt build, but not a static one due to some assumptions in the C++ code about shared plugins. styleplugin doesn't seem to work properly neither with shared Qt builds nor static Qt builds, at least on macOS. But it builds fine. For some reason even if the plugin is found, the style is not applied. Amends 4caac1feea025b0ad496141e8f16ab88c04c2caa Pick-to: 6.2 Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: I6f631cda9566229b7a63992b23d7d7fa50303eeb Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't install metatypes files for user projectsAlexandru Croitor2021-08-191-13/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Set a placeholder bundle version for iOS appsAlexandru Croitor2021-08-171-0/+26
| | | | | | | | | | | | | | | Without a bundle version and short version string string, the iOS simulator will refuse to launch the app. Set a placeholder "0.0.1" version for both fields if they were not set by the project. Allow opt-out via a QT_NO_SET_XCODE_BUNDLE_VERSION variable. Pick-to: 6.2 Fixes: QTBUG-95836 Task-number: QTBUG-95838 Change-Id: I3e959766c7fa13f23ad12882f8bd14cd45e7096c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Remove qt6_enable_object_libraries_finalizer_modeAlexandru Croitor2021-08-101-30/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qt6_enable_object_libraries_finalizer_mode is not needed anymore now that static Qt builds require CMake 3.21 and thus CMake takes care of placing object library object files at the beginning of the link line. Rename qt6_enable_import_plugins_finalizer_mode to a more generic qt6_set_finalizer_mode that can enable or disable multiple different modes. For now the only available mode is "static_plugins" which handles the behavior of the old function name. The mode can be enabled by calling qt6_set_finalizer_mode(${target} ENABLE MODES "static_plugins") Note that the function is re-tagged as being in Technical Preview. Ideally we would not need it at all. But we need to provide some workaround for the limitations of linking Qt static plugins in CMake on Linux-y platforms that use bfd ld or ld.gold. The workaround does not work well with dependencies wrapped in generator expressions which is why we can't confidently advertise it as a proper solution. Our hope is that this can be fixed in future upstream CMake versions and the function can be removed. See 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 for details. Adjust the tests due to the renamed and removed functions. Amends 19e789bace887105badae83c0a79429bbf8e8221 Amends cdbb390c4a9b8d53cfcfd0884e6720423ce5e126 Amends a25027eecb3829a65543d0e8ab00c74e1b1a21c5 Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Amends a3c430f390b379d874916d4c9ff02af5323af1bd Pick-to: 6.2 Fixes: QTBUG-95169 Task-number: QTBUG-95601 Task-number: QTBUG-95603 Change-Id: I51b85f776ec29fc04fed1a637eba7d1f60609e69 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Rename qt6_add_plugin TYPE option to PLUGIN_TYPEAlexandru Croitor2021-08-061-2/+20
| | | | | | | | | | | | | The intention is to remove TYPE as a keyword completely before 6.2.0 release, but in case if that's not possible due to the large amount of repositories and examples, just print a deprecation warning for now and handle both TYPE and PLUGIN_TYPE. Task-number: QTBUG-95170 Pick-to: 6.2 Change-Id: If0c18345483b9254b0fc21120229fcc2a2fbfbf5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Make qt6_wasm_add_target_helpers an internal functionJoerg Bornemann2021-08-041-1/+1
| | | | | | | | | This function is called by qt_add_executable. There is no need to expose it as public function. Fixes: QTBUG-95172 Change-Id: I85a1d906ecda42458e226db225e47c1d348a72f1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Use correct MSVC runtime library for targets created by qt_add_*()Li Xinwei2021-08-031-0/+3
| | | | | | | | | | | Use _qt_internal_set_up_static_runtime_library() to set correct MSVC runtime library for targets created by qt_add_executable(), qt_add_library(), qt_add_plugin() and qt_add_big_resources(), to bring convenience to user projects. Pick-to: 6.2 Change-Id: Ia49f1e90989c464820824be3e1eef3df1351cdcf Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix Windows -debug-and-release builds with CMake 3.21.0Alexandru Croitor2021-07-221-5/+19
| | | | | | | | | | | | | | | | | | | | | CMake 3.21.0 introduced a regression where per-config sources can't be specified for object libs when building Qt with Ninja Multi-Config and cross-config mode on. We hit that in our Windows resource compiler handling. To work around the issue, pass the config-specific sources directly to the target rather than via an object library, when using CMake 3.20 or later. The original issue of not being able to do that has been fixed in 3.20. Amends ba6175eb731927f2489cdd7d899616a9889aba67 Amends a1ccedeb440216dce87fad01746935a89fd8715e Amends 657fa0462d552110e2ba14bcac46275e6066993f Pick-to: 6.2 Fixes: QTBUG-95229 Change-Id: Idea6d5bcc54b3124c66c45538c2e06e92f288f5f Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Don't create ${target}_qml_files target any moreCraig Scott2021-07-191-8/+3
| | | | | | | | | | | | | | The qml files should now always be added via dedicated functions provided by the qtdeclarative repo. Those functions take care of adding the files to targets so that they will show up in IDE file lists, so we should not add them to a separate target as well. This will also remove one unnecessary build target, which will reduce visual noise in some IDEs. Pick-to: 6.2 Change-Id: I79bf1ea8fb8a2f15643e052d50ac582a91bdff1a Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Handle single- and multi-config differences more robustlyCraig Scott2021-07-171-6/+7
| | | | | | | | | | | | | Projects sometimes set both CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE regardless of what CMake generator they are using. They shouldn't, but it is common enough that we should protect against it. The GENERATOR_IS_MULTI_CONFIG global property is the only robust way to know which type of generator we are using, so switch to that for how we detect this. Pick-to: 6.2 Change-Id: If5d6568da0d2adb3275bbaf9a7d3bd3e033dc636 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Clean up and simplify qt6_extract_metatypes implementationAlexandru Croitor2021-07-161-72/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix qt6_extract_metatypes json file generation ruleAlexandru Croitor2021-07-161-39/+23
| | | | | | | | | | | | | | | | | | | | | | | | Change the copying of ${CMAKE_CURRENT_BINARY_DIR}/${target}_metatypes.json to ${prefix}/lib/metatypes/${target}_metatypes.json to happen as part of the command generating the file, rather than copying the file as part of a separate custom target or POST_BUILD event. This ensures that the custom commands in qt6_qml_type_registration that use those files as dependencies will cause them to be generated before the qml type registration happens, thus eliminating errors like Error 5 while parsing qtbase/lib/metatypes/qt6quick_metatypes.json: illegal value Pick-to: 6.1 6.2 Fixes: QTBUG-94942 Change-Id: Idddd73786d1a622984965c60ac9b4c3bc2c13ab5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Remove code paths no longer used after QML CMake API refactoringCraig Scott2021-07-131-33/+10
| | | | | | | | | | | | | QT6_ADD_RESOURCE_DECLARATIVE_EXTENSIONS is never defined now. All qml files are expected to be added via dedicated functions provided by the qtdeclarative repo rather than being given to qt_add_resources() directly. Pick-to: 6.2 Change-Id: I44feca84a2e3d4ef8ecc0140f88625ff192bfdfd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* CMake: Use correct MSVC runtime library for Qt object librariesAlexandru Croitor2021-07-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | If Qt was configured with -static-runtime which implies MultiThreaded -MT flag, the plugin initializer object libraries were still compiled with the default -MD flag. When an application linked to Qt, that caused linking to fail with mismatched symbol errors between the application symbols and the plugin initializer object library symbols. Make sure to set the MSVC_RUNTIME_LIBRARY property on both plugin initializer and resource object libraries, depending on the value of QT_FEATURE_static_runtime. We did set the property for resources added by qt_internal_add_resource, but not for the resource created by the public qt6_add_resources counterpart. Pick-to: 6.2 Fixes: QTBUG-95043 Change-Id: Ia543cd0241db94a12080be2655ad420fe9ad3f24 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix qt6_extract_metatypes to work with VS GeneratorsAlexandru Croitor2021-07-051-0/+26
| | | | | | | | | | | | | | | | CMake has an optimization where it skips creation of a ${target}_autogen target and instead uses PRE_BUILD events for AUTOMOC. That breaks qt6_extract_metatypes which expects the autogen target to always exist. Disable the optimization by generating a dummy header file and adding it as a source to the target. Pick-to: 6.2 Fixes: QTBUG-94944 Change-Id: Ic3d923cc6d3a149fea8c5c7b111576b64d19f608 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Use target_link_options to propagate object librariesAlexey Edelev2021-07-021-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Do not apply not acceptable properties to the imported object librariesAlexey Edelev2021-06-211-5/+10
| | | | | | | | | | | | | If __qt_internal_propagate_object_library is used to propagate an imported object library we assume that the library is already compiled and no need to apply properties that may affect compiling and further linking of the target. Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I2bd03264e286439fbed9067fa2c0a5c4a0097856 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Move the linking logic of the object libraries to a common functionAlexey Edelev2021-06-181-75/+113
| | | | | | | | | | | | | | | | | | | The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-27 10:02:26 +0000