summaryrefslogtreecommitdiffstats
path: root/src/corelib/Qt6CoreMacros.cmake
Commit message (Collapse)AuthorAgeFilesLines
* 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 Fixes: QTBUG-95229 Change-Id: Idea6d5bcc54b3124c66c45538c2e06e92f288f5f Reviewed-by: Cristian Adam <cristian.adam@qt.io> (cherry picked from commit cd89b7b61976a5302a683998b60dc66c8bc3018d) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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. Change-Id: I79bf1ea8fb8a2f15643e052d50ac582a91bdff1a Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit a1229a5aa1fb8c7d7e7047ce4c1769d9dae00aec) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Handle single- and multi-config differences more robustlyCraig Scott2021-07-161-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. Change-Id: If5d6568da0d2adb3275bbaf9a7d3bd3e033dc636 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit b30ac93a3737628da118f2137d96c7773ea9e239) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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 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> (cherry picked from commit fb9cbd3b2a12dfcddb8ef66d39ed4475ff1d56a7) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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 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> (cherry picked from commit bcca14a1933de9f188950a9a2d3a450a0772d479) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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. 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> (cherry picked from commit 363df5cd709762c3c014132c1670fdd715233620) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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. 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> (cherry picked from commit 51ae235080df7f051e65883a90731685649f2957) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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. 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> (cherry picked from commit 785df612319d3023ad994f3153d42a067a1adaa9) Reviewed-by: Qt Cherry-pick Bot <cherrypick_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 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit e80b0107952272aa3382a84aeb6d11b6047d775e) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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 Change-Id: I2bd03264e286439fbed9067fa2c0a5c4a0097856 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit d49f19e66107f6f56271e32284ee952af598ff1b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 3329212815777e33dfb4697b748d10927d73f44c) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Set the plugin class name for qml pluginsAlexandru Croitor2021-06-171-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | This is needed for a change in qtdeclarative to allow building the Q_IMPORT_PLUGIN-containing object library initializer of a qml plugin. Show an error if the qml plugin has no class name, it's needed for plugin initialization so it's mandatory to have a class name. Show an error if a class name is not found when computing the import macro for a plugin (both for a regular qt plugin and a qml plugin). When querying for the class name of a target, query both a Qt6:: prefixed target as well as a non-prefixed one, with the Qt one taking precedence. This is to allow querying the class name of user project created qml plugins. Currently regular qt user plugins don't use the object library initializer approach. This will likely be revisited in the future. Task-number: QTBUG-92933 Change-Id: I46417471a7d8b49651e6821f7b28e7a9d44c2557 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 602d26c38f3767be9bec25302c93fc155c4dce59) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Rename qt6_finalize_ios_app to be internalAlexandru Croitor2021-06-171-3/+2
| | | | | | | | | | | | | For now, it's not meant to be called manually. It's called in qt_add_executable automatically for iOS. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Task-number: QTBUG-88763 Change-Id: I90dfcf86f53a3c8e48a813435f7400db232b21f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 51b8c81c84136d5e80a803b2248ed1d17ab43ef0) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Remove old add_qt_gui_executable APIAlexandru Croitor2021-06-171-6/+0
| | | | | | | | | | | Repos should have migrated by now and the function should not be advertised as a public one. Task-number: QTBUG-88763 Change-Id: Ica5bc55670a17a28c0022f78c126a3a8a8ffdeb5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 15c5f905072c28537586a070a5320201edeee316) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Check the impact of static link order for user projectsAlexey Edelev2021-06-171-16/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 5fb99e3860eb43f4bacacec7f4a4626cb0159b14)
* CMake: Mention resource name on which rcc is runAlexandru Croitor2021-06-161-1/+1
| | | | | | | Change-Id: I12189d7bf3fbe8544ae4c3478166515ea2759bec Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 906c84a9a3f71d333e8b0772f41aab5280ab5682) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Change some custom commands to mention the target nameAlexandru Croitor2021-06-161-3/+3
| | | | | | | Change-Id: I3a198c87ba2d71306478809095083694b65c7086 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 9297459900e5a44d4a9021e65f38345e04524566) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Add the check for linker capabilities to resolve circular dependenciesAlexey Edelev2021-06-101-1/+15
| | | | | | | | | | | | | | | 'ld' only capable to resolve circular dependencies by wrapping the suspected static libraries and objects using --start/end-group arguments. We want to detect if linker is 'ld' at configure time to decide how to link the resource objects if finalizers are not enabled. The qt_config_compile_test function is extended with an extra argument since it's required to pass custom cmake flags to the ld-related test. Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Remove legacy code path from qt_add_resourceJoerg Bornemann2021-06-071-37/+11
| | | | | | | | All repos use the updated version of qt_add_resource, and we can remove the legacy code path. Change-Id: I15ba64a08c3fad9712a5cf05715594b1ee755bfc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Bring back qt_finalize_executableKai Köhne2021-06-041-0/+5
| | | | | | | | | | qt_finalize_executable was renamed to qt_finalize_target in commit c4df673dd903. Anyhow, app wizards in Qt Creator 4.15 already use it, so let's keep it as an synonym API for the time being. Fixes: QTBUG-94156 Change-Id: I468443c80c027ac49a21208a9b15af1dbb4a5f84 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Rework resource finalizer approachAlexey Edelev2021-05-311-10/+9
| | | | | | | | | | | | | | | | In the previous implementation of the resource object finalizer, we used the name of the resource object library without namespaces when recording it in the resource libraries list. This causes an issue when we or users export resource targets. This approach marks resource object libraries with the exporting property instead of collecting resource targets when creating them. Amends 19e789bace887105badae83c0a79429bbf8e8221 Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Implement propagation of object files to the end-point executableAlexey Edelev2021-05-271-5/+44
| | | | | | | | | | | | | | | | | | | | This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Revise plugin finalizer mode usageAlexandru Croitor2021-05-271-13/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Only use plugin finalizer mode if qt_finalize_target is called at the end of the user project (which we can't really check, the user has to ensure that) or when qt_finalize_target is automatically defer-called by CMake 3.19+ (which is done by qt_add_executable). This removes the previous behavior of using the finalizer mode if qt_import_plugins is called. Instead the old regular mode is used if the above preconditions are not met. The removed behavior had ordering issues if qt_import_plugins was called before target_link_libraries. The dependency walking would be done before Qt dependencies were added and thus no plugins would be linked. Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Task-number: QTBUG-80863 Task-number: QTBUG-92933 Task-number: QTBUG-94030 Change-Id: I78702b653a35596f5581c2f4282b2336f0124e60 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix finalizers not being run for android executablesAlexandru Croitor2021-05-261-1/+4
| | | | | | | | | | | | Android executables are actually loadable modules, not executables. Instead of checking for the target type if it's a MODULE, be explicit and mark the target with a special qt property that we then use to decide whether the finalizer should run. Amends c4df673dd9034bc6dcd0871d27f13d8524ae829e Change-Id: I5330d80d39488cfda6ebe07e2a1883200a796be8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't apply invalid infixes to INTERFACE librariesAlexandru Croitor2021-05-261-1/+3
| | | | | | | | | | | | | | And object libraries. Setting properties like IMPORT_SUFFIX on them doesn't make sense and can cause configuration issues. Amends 1bd408d6f7eac7908c77a0129e0173c280fce55b Change-Id: Ie91d1fbc7ba130816854d50c5b00ef793e4bad1f Reviewed-by: Martin Storsjö <martin@martin.st> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Introduce a public qt_add_library functionAlexandru Croitor2021-05-251-18/+118
| | | | | | | | | | | | | | | | | | | | | | Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Support multiple equally named .qrc files in qt_add_big_resourcesJoerg Bornemann2021-05-221-0/+13
| | | | | | | | | | | It is now possible to call qt_add_big_resources with multiple .qrc files that are in different directories but have the same file name. Before, this resulted in target name conflict errors. Pick-to: 6.1 Fixes: QTBUG-93230 Change-Id: Ic3d9d6974a107163aeb7ada0b6f1fa113fb18de0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Enable UNICODE for all Qt targets and Qt consumers by defaultAlexey Edelev2021-05-211-0/+11
| | | | | | | | | | | | | | | | | | After discussion we decided to opt-out the UNICODE definintion behavior. To disable UNICODE in user projects the qt6_disable_unicode_defines function could be used. Amends 5b64e5950cf984abb7d47e0802bcb4b5a21e06fa [ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on WIN32 platforms by default for all cmake projects to reflect the qmake behavior. Use qt6_disable_unicode_defines function to disable the default unicode definitions. Pick-to: 6.1 Fixes: QTBUG-93895 Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix qt6_add_big_resourcesJoerg Bornemann2021-05-201-1/+1
| | | | | | | | | | | | | | | | | | The qt6_add_big_resources command was dysfunctional whenever AUTOMOC was enabled for a target. We passed multiple object files with the --temp argument of the second pass of rcc. We must pass exactly one. The spurious object file was the one that's created by AUTOMOC. Turn off all of AUTOGEN for the C++ source file that's generated in the first pass of rcc. Enable AUTOMOC for tests/auto/cmake/test_add_big_resource to cover this situation. Pick-to: 6.1 Fixes: QTBUG-85051 Change-Id: I6d2ce4953297db0751913456db0a4a126fe33f14 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Replace qt_finalize_executable with qt_finalize_targetAlexandru Croitor2021-05-201-13/+22
| | | | | | | | | | | | | | | | | | It's very likely that we'll have to run certain finalizer code for targets other than executables. Rename qt_finalize_executable to _qt_internal_finalize_executable so it's internal. Introduce a new function qt_finalize_target which will call the above internal one when the target is an executable. This should future proof the API so we have a hook to call code for any user CMake project that intends to use Qt CMake API. Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Introduce finalizer mode handling of static pluginsAlexandru Croitor2021-05-201-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Build plugin initializers as object libsAlexandru Croitor2021-05-181-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of compiling the plugin initializers as part of a user project, pre-compile them as object libraries while building Qt. The installed object libraries can then be used with target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) so that they are linked into the final executable or shared library via qt module usage requirement propagation. This reduces the build times of user projects. The link line placement of the object files should be correct for all linux-y linkers because the only dependency for the object files is Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that from empirical observations. As a consequence of the recent change not to link plugin initialization object files into static libraries, as well not having to compile the files in user projects, we can get rid of the _qt_internal_disable_static_default_plugins calls in various places. A side note. Consider a user static library (L) that links to a Qt static library (Gui) which provides plugins (platform plugins). If there is an executable (E) that links to (L), with no direct dependency to any other Qt module and the intention is that the executable will automatically get the platform plugin linked, then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage requirements are propagated successfully. This is a limitation of using target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which will propagate object files across static libraries only if qt_module is linked publicly. One could try to use target_link_libraries(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which preserves the linker arguments across static libs even if qt_module is linked privately, but unfortunately CMake will lose dependency information on Core, which means the object files might be placed in the wrong place on the link line. As far as I know this is a limitation of CMake that can't be worked around at the moment. Note this behavior was present before this change as well. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix BASE argument of qt_add_resourcesJoerg Bornemann2021-05-181-16/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BASE argument of qt_add_resources now denotes the root point of the alias of the file. Before, BASE was merely prepended to every file that got passed to qt_add_resources. Old behavior: qt_add_resources(app "images" PREFIX "/" BASE "../shared" FILES "images/button.png") Alias is "../shared/images/button.png", and pro2cmake generated QT_RESOURCE_ALIAS assignments to fix this. New behavior: qt_add_resources(app "images" PREFIX "/" BASE "../shared" FILES "../shared/images/button.png") The alias is "images/button.png". No extra QT_RESOURCE_ALIAS assignment is needed. The new behavior is in effect for user projects and for Qt repositories that define QT_USE_FIXED_QT_ADD_RESOURCE_BASE. Qt repositories will be ported one by one to this new behavior. Then the old code path can be removed. Pick-to: 6.1 Task-number: QTBUG-86726 Change-Id: Ib895edd4df8e97b54badadd9a1c34408beff131f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Walk link dependencies recursively to work out finalizersCraig Scott2021-05-111-7/+9
| | | | | | | | | | | | | | | When versionless targets are used, they are defined as INTERFACE IMPORTED targets. These will sit between the executable target created by qt6_add_executable() and the underlying Qt6::XXX module library where the finalizers are defined. We need to recurse through the link dependencies to ensure we pick up these finalizers. This will also ensure we pick up finalizers in deeper targets from transitive dependencies. Fixes: QTBUG-93387 Change-Id: If8524ebf0e75c8790858dd7e42aa1cf4ebdfd989 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Resurrect test_import_plugins cmake build testsAlexandru Croitor2021-05-111-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we run tests for static Qt builds in the CI, it makes sense to restore the CMake build tests that check that static plugin importing works correctly. Resurrect the previously commented out test_import_plugins project and port the mockplugins qmake projects to CMake. mockplugins is a CMake project that uses the internal Qt CMake API to build and install some Qt modules and plugins. test_import_plugins depends on that test (via a CMake fixture) to build public projects that use those plugins. The installation of the mockplugins modules pollutes the Qt install prefix, but in the CI that only happens on the test VM, which means the release packages are not affected. Locally on a developer machine the Qt install path will be polluted, but it's not that much of a big deal. We could try and address that in a future change by using the QT_ADDITIONAL_PACKAGES_PREFIX_PATH functionality added for Conan to allow the installation of Qt packages into a non-standard prefix. Task-number: QTBUG-87580 Task-number: QTBUG-92933 Change-Id: I0841064a60a5ffba5118640d3197527a38ba6c30 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add _qt_internal_wrap_tool_command to replace QT_TOOL_PATH_SETUP_COMMANDAlexey Edelev2021-04-301-0/+24
| | | | | | | | | | | | | | | | | | | QT_TOOL_PATH_SETUP_COMMAND is used in COMMAND list when call add_custom_command/add_custom_target. This is necessary to setup the necessary environment for the tool to run correctly. This approach is weak according to CMake documentation: "If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script." This change introduces the _qt_internal_wrap_tool_command function that uses a wrapping script that setups necessary environment for the tool and runs it in a single shell. The script is generated by the _qt_generate_tool_command_wrapper function. Change-Id: Id5270b91619b607a0c1e3a19b8c706edec43f388 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Compile resource objects of the static library using same optionsAlexey Edelev2021-04-271-0/+53
| | | | | | | | | | | | | | | | | Introduce the function that appends the specified properties of the one target to the another. It's possible to copy the standard property set that affects a compilation only or pass some specific properties that need to copy. You may also control the visibily of properties that need to copy by passing the PRIVATE_ONLY or INTERFACE_ONLY option. The function is used to compile the resource targets with the same property set as the main target. Also link the Qt::Platform interface library to collect platform specific properties. Pick-to: 6.1 Change-Id: I727fd0a4bc52c4f5128f28ce796d7a5f3005bb30 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Switch to target_sources approach for the static library resourcesAlexey Edelev2021-04-231-15/+10
| | | | | | | | | | | | | | | | | | | | | | Linking the object resource library to the static library still causes an issue if the static library contains symbols that are used in the resource library. The proposed approach creates the following linker chain: executable <- resource objects <- static library <- Qt::Core For the static qml plugins this means that the qmlcache_loader object file will state in the linker command line before the plugin library that implements '::qmlData' and '::aotBuiltFunctions' functions. We also need to keep the INTERFACE linking of the resource library to the targets that it belongs too, to collect all the dependencies that resouce library supposed to propagate to top-level targets. Pick-to: 6.1 Fixes: QTBUG-93002 Change-Id: Ice0aabb6817317724abeb3db3bb8a954905cfad1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Generate better Xcode iOS projectsAlexandru Croitor2021-04-191-0/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Fix linking order of the resource objectsAlexey Edelev2021-04-081-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | The generated object resource library depends on the Qt::Core library because uses the functions defined in qresource.cpp. Dummy linking of the Qt::Core to an object library has an effect only when the object library is linked directly to the executable as a target. If we link the object library as INTERFACE library we miss out all the objects that need to be linked to the executable. This behavior is explained here: https://bit.ly/3sFWKvI Thus, the only option to link the object library objects to the endpoint executable is to use TARGET_OBJECTS property in genex, as it's already done. But that means we are losing all profits that target actually has, especially linking the object library dependencies. The combination of both of the above methods does the job. The only thing that looks fragile so far is order. Currently, the order we use in the target_link_library call applies to the linker command line. This means the object library objects must always appear before the object library target. Change-Id: If1f0e35e0445d5e96a1f2249ab44114cd36630e9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Choose better defaults for qt_add_plugin STATIC/SHAREDAlexandru Croitor2021-04-071-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a recent behavior change where the public CMake API qt_add_plugin API took into account the value of BUILD_SHARED_LIBS to decide whether the plugin should be a static or shared library. Instead, use the following new behavior - If no explicit option STATIC / SHARED option is passed, default to whatever flavor Qt was built as. Aka if Qt was configured with -shared, qt_add_plugin defaults to creating shared plugins. If it's a -static Qt, create static plugins. - If an explicit STATIC / SHARED option is set, override the default computed value with the given value. As a result BUILD_SHARED_LIBS does not affect Qt plugins anymore. This is more in line with Qt expectations. Add SHARED as a new valid option to pass to qt_add_plugin (it wasn't before). Add tests to check for the above behavior. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Pick-to: 6.1 Fixes: QTBUG-92361 Task-number: QTBUG-88763 Change-Id: Iae806024ddd5cf10cfe58ddbcebd2818084b0bd7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* wasm: add cmake build supportLorn Potter2021-04-011-0/+3
| | | | | | | | | | | | | | | | A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add missing compile definitions to the resource object libraryAlexey Edelev2021-03-301-0/+3
| | | | | | | | | The resource object library must be compiled with the definitions specified in Qt::Core. Missing the required definitions causes linker problems when QT_NAMESPACE is defined. Change-Id: If0ca20604e251822279e0d4906c47b94d3b4ceb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Refactor qt_internal_add_plugin() and qt6_add_plugin()Craig Scott2021-03-291-20/+79
| | | | | | | | | | | | | | | | | | | | | | Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qt6_finalize_executable(): Enable finalizers to be set per-targetCraig Scott2021-02-241-0/+41
| | | | | | | | | | | | | | | | | | | | | Some plugins need to append additional processing to targets that use them. This is most commonly needed for static builds to identify additional plugins that need to be linked, but which cannot be determined automatically by CMake as part of its transitive dependency handling. Check for finalizers on directly linked targets as a way to help automate common scenarios. Because we need to lookup dependency targets and these may have visibility limited to the depender target's scope, we now formally document that finalizers should be called from the same scope as the one in which the target was created. This was loosely expected before, but is now made explicit. Task-number: QTBUG-90819 Task-number: QTBUG-86669 Pick-to: 6.1 Change-Id: I065a3f3a4ab6eeff6a98a655835427949e2fe0f1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Revert "Fix static build with tests"Joerg Bornemann2021-02-071-3/+2
| | | | | | | | | | | | | | | | | | | This reverts commit 74f549b4026710b484f17cd99dbafb074854bd11. Reason for revert: This breaks transitive dependencies. The object file we're adding with target_sources will not be propagated transitively. For example, qmltestrunner depends on QuickTest, and QuickTest depends on Quick. The 'qrc_scenegraph.cpp.o' object file will not be propagated to qmltestrunner if added with target_source(Quick INTERFACE ...). Fixes: QTBUG-90933 Pick-to: 6.0 Change-Id: I11269537ae75de14189f8b5f59094b467e2eee24 Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
* Fix static build with testsJoerg Bornemann2021-02-031-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | A static build of Qt with QT_BUILD_TESTS=ON would fail with errors like this: FAILED: tests/auto/corelib/io/qprocess/testProcessEcho2/testProcessEcho2 undefined reference to `qRegisterResourceData(...)' We create object libraries for resources. In this case, for the mimetypes of QtCore. For static builds we added the object files to INTERFACE_LINK_LIBRARIES of the Qt module the resource belongs to: target_link_libraries(Core INTERFACE "$<TARGET_OBJECTS:$<TARGET_NAME:${resource_target}>>") That is, however, a problem for projects that link only against QtCore, like testProcessEcho2 above. On the linker command line Qt6Core.a is before qrc_mimetypes.cpp.o and that doesn't work, because the latter needs symbols of the former. To have the resource object files before any other libraries on the linker's command line, we now treat them as source files. Pick-to: 6.0 Fixes: QTBUG-90582 Change-Id: Ia2786beb5f7c2eba194e8f00ae8785572df1cf6e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix qt_add_big_resources with namespace buildsAlexey Edelev2021-01-191-0/+1
| | | | | | | | | | | | Add INTERFACE_COMPILE_DEFINITIONS of Qt6::Core to generated rcc object libraries. This propagates QT_NAMESPACE definition to the object library. Fixes: QTBUG-85620 Change-Id: I252d1aaee7b19a49bc321fdd271a5d85a34bf67f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Don't rely on versionless commands or targets existingCraig Scott2020-12-211-3/+3
| | | | | | | | | | Commands like qt6_finalize_executable() should not rely on versionless commands or targets being available, since they can be disabled by a build option. Pick-to: 6.0 Change-Id: I6a9ab6a9b6a6b731590e5b8c43f73b518ed38e81 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Support deferred finalization for qt6_add_executable()Craig Scott2020-12-101-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some parts of qt6_add_executable() need to take into account certain target properties, but the target is created within the function. The caller doesn't get the opportunity to modify those properties before they are used. This change provides a way to defer those property-using steps until either the project explicitly calls a function to finalize the target or the end of the current directory scope is reached. Automatic deferral to end of scope is only supported for CMake 3.19+. With CMake 3.18 or earlier, deferring the finalization step has to be explicitly requested with the new MANUAL_FINALIZATION keyword. The caller is then responsible for also calling qt6_finalize_executable() later. When the keyword is given, automatic finalization is disabled even when using CMake 3.19+. Note that while this could be implemented without CMake 3.19 features, other work relating to qt6_import_qml_plugins() will require it so we may as well use this method now. Fixes: QTBUG-88840 Task-number: QTBUG-86669 Pick-to: 6.0 Change-Id: Ic3854672ba18cff5af2ffd7f63596aa3ac492f33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-14 22:11:39 +0000