summaryrefslogtreecommitdiffstats
path: root/src/corelib/Qt6CoreMacros.cmake
Commit message (Collapse)AuthorAgeFilesLines
...
* 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. Pick-to: 6.2 Task-number: QTBUG-92933 Change-Id: I46417471a7d8b49651e6821f7b28e7a9d44c2557 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* 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. Pick-to: 6.2 Task-number: QTBUG-88763 Change-Id: Ica5bc55670a17a28c0022f78c126a3a8a8ffdeb5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* 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 Pick-to: 6.2 Task-number: QTBUG-88763 Change-Id: I90dfcf86f53a3c8e48a813435f7400db232b21f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Mention resource name on which rcc is runAlexandru Croitor2021-06-161-1/+1
| | | | | | Pick-to: 6.2 Change-Id: I12189d7bf3fbe8544ae4c3478166515ea2759bec Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Change some custom commands to mention the target nameAlexandru Croitor2021-06-161-3/+3
| | | | | | Pick-to: 6.2 Change-Id: I3a198c87ba2d71306478809095083694b65c7086 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Check the impact of static link order for user projectsAlexey Edelev2021-06-161-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 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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. Pick-to: 6.2 Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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>
* CMake: Disable static plugin imports for non-executable targetsAlexandru Croitor2020-12-081-1/+8
| | | | | | | | | | | | | | There is no point in generating cpp files containing Q_IMPORT_PLUGIN() macro calls for non-executable targets like modules, plugins and object libraries in a static Qt build. It causes unnecessary compiling of 10+ files for each of those targets. In a static Qt build, plugin imports should only be done for executables, tools and applications. Pick-to: 6.0 Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Improve long paths handling for static buildsAlexey Edelev2020-12-031-1/+8
| | | | | | | | | | | | Use number-based naming of object libraries produced for generated resources. This reduces path length of subdirectories for object library targets. Amends 08eb485a006dc2baca42eb280ae60e9f0fc00dff Pick-to: 6.0 Change-Id: I1a449290e8a9b969601a1cc1abc6fdcfc0cd9454 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow WIN32 and MACOSX_BUNDLE arguments for qt6_add_executableCristian Adam2020-12-011-0/+1
| | | | | | | | | | | | | | | qt6_add_executable will forward all arguments to add_executable, which works fine on Windows and macOS in regards of WIN32 and MACOSX_BUNDLE arguments. On Android however add_library is being used, and those arguments need to be removed otherwise they will be consided as source files. Pick-to: 6.0 Fixes: QTBUG-88926 Change-Id: Id22fdf91d58d9053eaad2d3c080ea72060d928c0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix resource object file paths in prl files for prefix buildsAlexandru Croitor2020-11-301-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, the prl files always assumed that resource object files are installed into $qt_prefix/lib when doing a prefix build. That was true for qt_internal_add_resource calls, but not for qt6_add_qml_module and qt6_target_qml_files. Change qt_internal_record_rcc_object_files to take a new required INSTALL_LOCATION argument. The argument takes a path relative to CMAKE_INSTALL_PREFIX. Modify __qt_propagate_generated_resource to save the relative path of the generated resource source file, which will be used in the computation of the final resource object file location. This is needed because the Qml resource functions place the source files in a different directory layout, e.g. .rcc vs .qmlcache Modify qt_generate_prl_file to prepend $$[QT_INSTALL_PREFIX]/ instead of $$[QT_INSTALL_LIBS]/ for the resource install paths. A follow up patch is done in qtdeclarative to pass the new INSTALL_LOCATION argument from the Qml CMake functions. Amends f9dcade5e795a631b9a2d93c855aa8198d58e24e Task-number: QTBUG-87702 Task-number: QTBUG-88425 Change-Id: Id17bb517b4cb5d00911bfd10a728ba4e0d44871b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 54d0ca93bca78f8fd31b6761f078e7a96283f183) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Change generated resources namingAlexey Edelev2020-11-241-1/+1
| | | | | | | | | | Align generated resources .qrc file naming to qmake naming. Update tests. Fixes: QTBUG-88581 Pick-to: 6.0 Change-Id: Id8a2f91f23c257e5b8bd371748c2151ec54a6418 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix resource_name variable name in __qt_propagate_generated_resourceAlexey Edelev2020-11-201-2/+2
| | | | | | | | | __qt_propagate_generated_resource used resourceName variable from parent scope instead of one passed to function. Pick-to: 6.0.0 6.0 Change-Id: I18ce8a9f9c01bcfdbab532def55af4e2780d7753 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Rename the qt resource properties to be internalAlexandru Croitor2020-11-191-1/+1
| | | | | | | | | Use lowercase underscored property names. This ensures they will continue to work even for INTERFACE libraries if it ever comes to that. Change-Id: I5281070f25c1eb9f591c79af8b7fa6169c7c0fb7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Add support for -binary option for generated resourcesAlexey Edelev2020-11-121-20/+48
| | | | | | | | | | | | | | | | | Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Remove indirection via Startup target for EntryPointTor Arne Vestbø2020-11-121-99/+0
| | | | | | | | | | | | | The EntryPoint interface target now contains all the logic for what flags and optional static libraries to add when the entrypoint is enabled. The target property QT_NO_ENTRYPOINT can be used to disable the entrypoint. Change-Id: I9b14ff729366cd6307789c969ebd4b2ca19de77d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Potentially use INSTALL_LIBDIR in qt6_extract_metatypesAlexandru Croitor2020-11-111-2/+7
| | | | | | | | | The INSTALL_LIBDIR value is only set when doing a Qt build. Use it when available, otherwise default to a more 'hardcoded' value. Change-Id: I96b7b8094c699de59ffaff00cd677d8322c474c3 Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Fix genex syntax error for iOS entrypointTor Arne Vestbø2020-11-101-1/+1
| | | | | Change-Id: I09f8870b937b7effd547071530636c314d242a16 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-25 19:50:07 +0000