summaryrefslogtreecommitdiffstats
path: root/cmake/QtPluginHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix auto-linking of static plugins for non-QML in-tree testsAlexandru Croitor2021-04-221-13/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix condition evaluation in plugin's DEFAULT_IF optionAlexandru Croitor2021-04-121-6/+6
| | | | | | | | | | | | Expand the condition without an extra negation. This fixes incorrect condition evaluation for conditions not enclosed in parenthesis. Pick-to: 6.1 Change-Id: I4923059b6b199676058091c23d51c9368daaebd0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix duplicate symbol errors in Windows static super buildsAlexandru Croitor2021-04-121-18/+21
| | | | | | | | | | | | | | | | | | | | | | | | | qt_internal_add_executable has some special logic to link static plugins in order to avoid issues with link cycles on exported Qt module targets. This logic does not take into account if a plugin is a default plugin. On windows this caused duplicate symbol linking issues in static super builds, because both qwindows and qdirect2d define a subset of the same symbols. Make sure to only link to default static plugins. This will skip linking to qdirect2d because it's not a default qpa plugin and thus avoid linker issues. Amends 5807e1ae8168a5702ad0f6890d2b35223cfebdee Pick-to: 6.1 6.1.0 Fixes: QTBUG-92451 Change-Id: I56df2ce0201625088417de53038642518c1d3bbd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Skip adding externally added plugins to the plugin meta-setsAlexey Edelev2021-04-081-3/+7
| | | | | | | | Plugin meta-sets are not visible outside of the module build tree, so there is no point in adding dependencies for externally added plugins. Change-Id: Ica5b29b57c032f4fc9b128172aaa806392e9e581 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove use of qt_internal_module_info from qt_internal_add_pluginAlexey Edelev2021-04-071-3/+1
| | | | | | | | | | | Plugin targets don't fit the requirements of the module but use the function associated to the module. The purpose of using qt_internal_module_info is to get the path to the top-level include directory. So there is no point in breaking the encapsulation rules to get a well-known directory. Change-Id: If3d2a31d4ec186929e3d662a79a1ae9eac988d1a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* wasm: add cmake build supportLorn Potter2021-04-011-1/+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>
* Avoid using prohibited target property names with INTERFACE targetsCraig Scott2021-03-311-3/+3
| | | | | | | | | | | | | | | | | | | | CMake 3.19 removed the restrictions on allowable names for properties on INTERFACE targets. With earlier CMake versions (back to CMake 3.11), names for custom properties must begin with either a lowercase letter or an underscore. In 5807e1ae81 (Add plugins to Qt tools and executables for static builds, 2021-03-19), the names QT_REPO_PLUGIN_CLASS_NAMES and QT_REPO_PLUGINS were used, but in some cases, the targets on which they were being set are INTERFACE targets. Replace these with names that are supported with CMake 3.11 or later. Amends 5807e1ae8168a5702ad0f6890d2b35223cfebdee Task-number: QTBUG-91915 Pick-to: 6.1 Change-Id: Ife702a1fb339b190d46a8dafb380253219199ba6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Semi-handle non-current repo qt modules when creating pluginsAlexandru Croitor2021-03-311-12/+32
| | | | | | | | | | | | | | | | | | | | | | | | In the recent refactoring of qt_internal_add_plugin, a new target existence check was added when associating a plugin with a qt module. That check didn't account for a qualified qt module target name. This failed configuration of qtsvg which checked for the existence of a namespace-less 'Gui' in a per-repo build. Make sure to prepend the Qt namespace to the qt module name and also handle aliased target names. As a drive-by, add a TODO item to figure out how to link executables to plugins who's plugin type belong to a different repo, but both the executable and plugin are built in the current repo. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Fixes: QTBUG-92235 Change-Id: I1c0f83672ab00f4702be9bad9a66ccc35e82f5c8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix plugin SKIP_INSTALL optionAlexey Edelev2021-03-291-5/+14
| | | | | | | | | | If SKIP_INSTALL option is specified for the qt_internal_add_plugin function the install_directory variable become empty and finalizer unable to call qt_finalize_plugin, because of lack of the second argument. It makes sense to use the INSTALL_PATH single argument instead. Change-Id: I2d4b40c8cf812a834c0e045569b45a649d339508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Refactor qt_internal_add_plugin() and qt6_add_plugin()Craig Scott2021-03-291-51/+64
| | | | | | | | | | | | | | | | | | | | | | 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>
* Add plugins to Qt tools and executables for static buildsCraig Scott2021-03-231-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In static builds, we cannot allow any part of the main build to make a call to find_package(Qt6...) where such a call may load a Qt6*Plugins.cmake file. That would add additional dependencies to the main module targets, setting up a circular dependency in the set of *Config.cmake files which cannot be resolved. This scenario would be triggered by per-repo builds or user projects. But Qt's tools and other executables still need to load some plugins in static builds. Sometimes a platform plugin may be enough, other times we may want all supportable plugins (e.g. Qt Designer). Therefore, add all plugins we can identify as relevant for an executable that is part of the Qt build, but add them directly to the executable without affecting the linking relationships between the main module libraries. Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in top level builds because there should be no difference between per-repo and top level builds any more (as far as linking static plugins is concerned). Examples that build as part of the main build will still build successfully after this change, but they will not run if they require a platform plugin. Examples need to be moved out to a separate build where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS set to TRUE to be runnable (see QTBUG-90820). Fixes: QTBUG-91915 Pick-to: 6.1 Change-Id: I8088baddb54e394ca111b103313596d6743570ba Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix build of QTuioTouchPlugin with Makefile generator on macOSJoerg Bornemann2021-03-111-2/+8
| | | | | | | | | | | | | | | | | For each plugin, we create a custom target with it's OUTPUT_NAME such that one simply can do 'ninja qtuiotouchplugin' to build it. QTuiTouchPlugin has qtuiotouchplugin as OUTPUT_NAME, which is problematic with Makefile generators on case-insensitive file systems. See CMake upstream issue #21915 for details. Work around this issue by not creating the custom target in this situation. Pick-to: 6.1 Fixes: QTBUG-84342 Change-Id: Id9a6cf0a01c179d5c93da4146e393cf00153ac4f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qtdeclarative now directly handles more qml-specific logicCraig Scott2021-03-101-6/+0
| | | | | | | | | | | | | | | | | Associated changes in the qtdeclarative repo now ensure that arguments for qml plugins are handled on the calling side. This reduces the qml-specific logic needed in qtbase and gives qtdeclarative clearer control over qml build and install locations. As part of that work, the INSTALL_LOCATION keyword used in qt_internal_record_rcc_object_files() has been renamed to INSTALL_DIRECTORY to make it consistent with the keyword used for the same concept in other commands. Pick-to: 6.1 Change-Id: Iebd319899f63d79fbe15ce965b84ce324c28a508 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Make qt_get_module_for_plugin() internal and do what its name saysCraig Scott2021-03-021-12/+7
| | | | | | | | | | | | | | | | | | Contrary to its name, this command was also setting a target property. Since it was only called in one place and that caller can just as easily set the property instead, rename the command to make clear its internal nature and refactor it so that the caller is responsible for setting that property instead. Also make it an error rather than just a warning if the command is used for a target that doesn't belong to any module. Since this is now unambiguously an internal command, we should always expect the target to belong to a module. Pick-to: 6.1 Change-Id: I929a652ddd482653868fc9df887f38f4bc7f35d9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Don't give plugins PUBLIC usage requirementsCraig Scott2021-02-241-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | The pro2cmake.py conversion script faithfully reproduced the .pro files for the plugins, which specified the libraries as public. But in CMake, the implications of this are that public usage requirements should then be propagated to consumers. We don't expect any consumers, since a plugin is created as a MODULE library in CMake, so for Windows we don't even have an import library to link with. The only exception to this is for static builds where plugins are created as STATIC libraries instead, but only in certain controlled situations do we then link to plugins. Even then, usage requirements are not expected to propagate to the consumers, so these relationships should always be specified as private. This change warns on any PUBLIC usage requirements specified for a plugin. This check is disabled by default to avoid spamming CI builds for repos that haven't been fixed yet. The check can be enabled by a CMake cache option, which is intended for developers to use locally when fixing this issue in other repos (all plugins in qtbase should not trigger this warning as a result of changes in this commit). Task-number: QTBUG-90819 Pick-to: 6.1 Change-Id: I09f2c8da77db1193ad3370f85d367dfc6ab7b9a6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Clear non-relevant CMake compiler flagsAlexey Edelev2021-01-271-3/+2
| | | | | | | | | | | | | | | | Add internal function to cleanup compiler flags out of the CMAKE_xxx_FLAGS_xxx variables. Use introduced interface to clear the '/EHsc' flag for the MSVC compiler family. This adjusts the CMake behavior to the qmake one. Change the 'EXCEPTIONS' option handling in helper functions. Add ability to add enabling and disabling exception flags. Previously it was only possible to add disabling exception flags. Fixes: QTBUG-89952 Change-Id: I60d47660a97ae9b5a1d1f4107d352c9e97890144 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Disable static plugin imports for non-executable targetsAlexandru Croitor2020-12-081-1/+1
| | | | | | | | | | | | | | 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: Enable NEW policies by CMake version with a global defaultCraig Scott2020-12-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Generate less pri files and mark header modules as no_linkCristian Adam2020-11-201-5/+6
| | | | | | | | | | | Plugins will no longer get .pri files generated in non-static builds. Header modules are now marked in the .pri files as CONFIG += no_link. Pick-to: 6.0 6.0.0 Fixes: QTBUG-88221 Change-Id: I06e31fa970ad021261c43ca3acd88055cc4c9555 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add handling of PLUGIN_EXTENDS for generic pluginsAlexey Edelev2020-11-091-3/+2
| | | | | | | | | | Modify pro2cmake converter to add extra argument to qt_internal_add_plugin. DEFINE_IF FALSE is added to generic plugins those had "PLUGIN_EXTENDS = - " specified in .pro files. Fixes: QTBUG-87861 Change-Id: I9269df19a32a088f5261f50e7ffff6d29c3d605f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add version information to Qt plugin DLLsJoerg Bornemann2020-11-061-0/+4
| | | | | | | | | | Tools and library DLLs already have version information embedded. Add the missing _qt_internal_generate_win32_rc_file call for plugins. Fixes: QTBUG-87747 Change-Id: I619948f4066ce229d41e8b93f125751e1d28e26c Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake Build: Enable separate debug info for all target typesCristian Adam2020-11-041-0/+2
| | | | | | | | | | | | | Now all shared libraries and executables will get .debug files on the platforms that support FEATURE_separate_debug_info With the directory property _qt_skip_separate_debug_info certain targets can retain the debug symbols in the binary e.g. lupdate with MinGW 8.1.0 will cause objcopy / strip to fail. Fixes: QTBUG-87015 Change-Id: I03b106e68ef0a42011d1ba641e6f686b2e7b7fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Cleanup module and plugin define situationAlexandru Croitor2020-10-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QT.<module>.DEFINES assignment in pri files needs to take into account the module name when computing the define name. This is the MODULE value that qmake specifies. In CMake that would be the value of CONFIG_MODULE_NAME. Previously the value of the define was computed in qt_internal_module_info() without taking into account the module name. While qt_internal_module_info() ended being used also for plugins and other target types, the defines computed by it were meant to be used only for Qt modules. Thus remove the <result>_define assignment from qt_internal_module_info and move its computation directly into qt_internal_add_module, taking into account the value of CONFIG_MODULE_NAME. The only other use of module_define was in qt_internal_add_plugin but that was merely a long overdue copy-paste error, qmake doesn't propagate QT_FOO_LIB defines for plugins. As result, a define special case in testlib is not needed anymore, because the define is now computed properly. Finally, QT_FOO_LIB should not be used while building the Qt module itself, so instead of using PUBLIC_DEFINES option of qt_internal_extend_target, use target_compile_definitions(INTERFACE) directly. Change-Id: I4d44f7461bac2f0c09aec3e995d02dfe36e00883 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix target dependency cycle regarding qpa plugins in qtwaylandAlexandru Croitor2020-10-261-4/+16
| | | | | | | | | | | | | | | | | | | | | | | With the introduction of the new 'default_qpa_plugins' custom target, a target dependency cycle occurred in qtwayland: qtwaylandscanner -> default_qpa_plugins -> a wayland qpa plugin -> WaylandClient -> qtwaylandscanner The issue is twofold: - default_qpa_plugins accidentally depended on non-qpa plugins. - All qpa plugins were enabled by default, including the wayland ones. Fix the default_qpa_plugins target not to depend on regular non-qpa plugins. Also fix qpa plugins not to be enabled by default, but instead only choose one qpa plugin to be the default (via evaluating the DEFAULT_IF) condition. Amends df9c7456d11dfcf74c7399ba0981a3ba3d3f5117 Change-Id: I22cd2c72f6b75be54263fd21097258bd179e3616 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix deprecation defines not being set properlyAlexandru Croitor2020-10-231-1/+1
| | | | | | | | | Instead of propagating the deprecation wranings, we compiled all code with -Ddeprecations. Change-Id: I0233ddc85bdbdcb93d366073b2cea5d47bdbe52a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Add convenience custom targets to build Qt pluginsAlexandru Croitor2020-10-221-0/+8
| | | | | | | | | | | | | | Add 3 new convenience custom targets: 'qt_plugins', 'qpa_plugins' and 'qpa_default_plugins'. Additionally, if we detect that an internal executable / test links against Gui, add a dependency on the 'qpa_default_plugins' custom target, so that if a developer configures Qt for the first time and then calls ninja 'tst_foo_check', we ensure the test will launch successfully because the default QPA plugin will also be built. Change-Id: If6dd70844b5effdf8a293f65f8785855cc85b132 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Install PDB debug info for MSVC buildsAlexandru Croitor2020-10-061-0/+1
| | | | | | | | | | | | | | | Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix build of Release user projects against RelWithDebInfo QtJoerg Bornemann2020-09-251-0/+4
| | | | | | | | | | | | | | | | | | | | | Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake Build: Add support for -qtlibinfix configure parameterCristian Adam2020-09-231-1/+1
| | | | | | | | | Rename all libQt6*.so to libQt6*<infix>.so Task-number: QTBUG-85438 Change-Id: I4b91ffaaec7bea61454b0d3c794c77f2d0868d54 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Rename internal functions to contain qt_internalAlexandru Croitor2020-09-231-1/+1
| | | | | | | | | | Offer compatibility wrapper functions until we update all of the Qt repos to use the new names. Task-number: QTBUG-86815 Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Split QtBuild.cmake into smaller filesAlexandru Croitor2020-08-141-0/+308
QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-25 03:29:20 +0000