summaryrefslogtreecommitdiffstats
path: root/cmake/QtPublicPluginHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Add newline after importAndré Klitzing2024-02-211-1/+1
| | | | | | | | | | | This avoids -Wnewline-eof for clang compilers. error: no newline at end of file [-Werror,-Wnewline-eof] Q_IMPORT_PLUGIN(Governikus_AnimationsPlugin) Pick-to: 6.7 6.6 6.5 Change-Id: I8de21f1f27cd177211ebf70fac0e01292cfa410c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix directory scoping issue for qt6_generate_deploy_scriptJoerg Bornemann2023-02-091-3/+20
| | | | | | | | | | | | | | | | | | | | | | Consider a Qt target created in a subdirectory and a call to qt6_generate_deploy_app_script(target) in the parent directory. Once qt6_generate_deploy_script (called by qt6_generate_deploy_app_script) is run, the target has already been finalized. However, qt6_generate_deploy_script needs to run before finalization, because: - qt6_generate_deploy_script marks the target as to be deployed - the finalizer generates plugins information only if the target was marked to be deployed Fix this in qt6_generate_deploy_script by checking whether the target was already finalized. In that case, generate the plugin deployment information right away. Pick-to: 6.5 Fixes: QTBUG-109741 Change-Id: Idf60f9e21f038c1a33843177d9299230857ee70b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add Linux support to qt_deploy_runtime_dependenciesJoerg Bornemann2022-09-151-9/+63
| | | | | | | | | | | | | | | | | | | | | | Before this change, qt_deploy_runtime_dependencies supported Windows and macOS only. We add a generic deployment method implemented in cmake-language with file(GET_RUNTIME_DEPENDENCIES). This deployment method is now enabled for shared builds on Linux. The file(GRD) command requires that the EXECUTABLE argument points to the executable in the build directory. Only libraries in Qt's installation directory are considered for deployment. This includes Qt's own libraries and also things like libicu*.so we're shipping with the installer. Unlike macdeployqt and windeployqt, the generic qt_deploy_runtime_dependencies does not yet support deploying translations. We will catch up on this in a later commit. Change-Id: Iea23abcdba774d4c1885c8d2c243eb3e48fb7fae Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Change the license of all CMakeLists.txt and *.cmake files to BSDLucie Gérard2022-08-231-1/+1
| | | | | | | Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Add license headers to cmake filesLucie Gérard2022-08-031-0/+3
| | | | | | | | | | | | CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Change __qt_internal_include_plugin_packages to be a macroAlexandru Croitor2022-07-251-25/+28
| | | | | | | | | | | | | | | | | | | The __qt_internal_include_plugin_packages function includes PluginConfig.cmake files which in turn might look for dependencies with find_dependency. The dependencies that were found not have their _FOUND variables set in the calling scope, which could cause multiple lookups of the same dependency packages. Change the function to be macro, so that all relevant _FOUND variables are set and no unnecessary package lookups are done. As a result, no need to set the QT_ALL_PLUGINS_FOUND_BY_FIND_PACKAGE variable using set(PARENT_SCOPE) Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Iba0fc83d9e58651f095e7b70d1ed19f064c4e577 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* cmake: Link static plugins even in shared Qt buildsTor Arne Vestbø2022-07-251-9/+16
| | | | | | | | | | | | | | | | It's perfectly possible to create static plugins in an otherwise shared Qt build, but the logic to import these plugins into applications was assuming a fully static Qt build. We now handle this more granularly. This works for in-source tools and tests as well, which don't go through the same CMake machinery for plugins as user projects do. The only case that does not currently work is in-source examples, as they don't share any of the plugin machinery with neither Qt internal tools/tests or user project, but that's a bigger architectural issue that goes beyond this change. Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Create and include plugin packages in shared buildsAlexandru Croitor2022-07-051-3/+6
| | | | | | | | | | | | | | | | | | | | | | Previously QtModulePlugins.cmake files were only created and included in static library Qt builds. Having the targets available in shared library builds would be useful for custom project deployment purposes. One could query the location of the plugins or use various generator expressions referencing their location. Ensure we always generate and include the QtModulePlugins.cmake files regardless of the build type. Allow opting out of including the files by setting QT_SKIP_AUTO_PLUGIN_INCLUSION to ON, just like we allow for Qml plugins with QT_SKIP_AUTO_QML_PLUGIN_INCLUSION. Pick-to: 6.4 Fixes: QTBUG-94066 Change-Id: I69a5dc17762a8e43265578fc33b82b5c4b7a1f5c Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Move plugin package inclusion logic into a common functionAlexandru Croitor2022-07-051-0/+65
| | | | | | | | | | Don't duplicate the logic of plugin package inclusion for each Qt module. Instead move it into QtPublicPluginHelpers.cmake. Pick-to: 6.4 Task-number: QTBUG-94066 Change-Id: I5e1f5176a0e754ed56a792c97865752529462617 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Avoid implicit linking of plugin init library if finalizers were calledAlexey Edelev2021-09-081-0/+2
| | | | | | | | | | | Propagating of plugin init libraries should take into account plugin finalizers to avoid duplicating of object files in a linker line. Pick-to: 6.2 Fixes: QTBUG-96062 Change-Id: I48feac94b08a7eb08d84134e9e9ae6e7214f5bdd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix 'Cannot find source file' error with older CMakesAlexandru Croitor2021-09-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Configuring a static plugin init library with CMake versions earlier than 3.18.0 fails at generation phase with CMake Error at Qt6CoreMacros.cmake:2071 (add_library): Cannot find source file: example/plugins/basictools/pnp_basictools_init.cpp Call Stack (most recent call first): qtbase/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:1998 (_qt_internal_add_library) qtbase/lib/cmake/Qt6/QtPublicPluginHelpers.cmake:243 (qt6_add_library) qtbase/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:1967 (__qt_internal_add_static_plugin_init_object_library) qtbase/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:1989 (qt6_add_plugin) qtbase/plugins/basictools/CMakeLists.txt:1 (qt_add_plugin) Marking the generated file as GENERATED explicitly solves the issue. Similar to e2c6f2ba7ed72195d12e9882c174e59a53317097 Fixes: QTBUG-96197 Pick-to: 6.2 Change-Id: If730a1fcbe6910d6041eb6eba03d6e45a025c424 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Use __qt_internal_propagate_object_library for static pluginsAlexandru Croitor2021-08-101-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Address TODO and use the new helper __qt_internal_propagate_object_library function instead of target_sources when linking static plugin initializers via usage requirements. Note that to work correctly this depends on using the target_link_options object library linking approach, which means a minimum CMake version of 3.17, which is already the case for static Qt usage. With CMake 3.21, it will use target_link_libraries approach instead. With CMake version 3.16 or lower, currently, this won't work correctly on Linux if there are dependencies wrapped in genexes because the __qt_internal_propagate_object_library call will try to use the still-by-default-enabled 'object_libraries' finalizer mode via __qt_internal_collect_dependency_object_libraries and that stops the usage of the target_sources approach to link the object files directly. This isn't a big deal though, because we already require CMake 3.20 as the minimum. It might be a bigger deal if we will need any of this functionality to work with 3.16 in shared Qt builds where the user project tries to create and link against custom static plugins. But that's already likely to be a can of worms even without this specific edge case. Amends a37957df5c1d3d8624fae2222734a127ec340a72 Amends 91c65dd80cdd2de666448c14202c0c63718152b6 Uses 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Task-number: QTBUG-92933 Change-Id: I8710e79eee265d820f65c8ccc3d0bd0c0ee6eccd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Remove qt6_enable_object_libraries_finalizer_modeAlexandru Croitor2021-08-101-19/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qt6_enable_object_libraries_finalizer_mode is not needed anymore now that static Qt builds require CMake 3.21 and thus CMake takes care of placing object library object files at the beginning of the link line. Rename qt6_enable_import_plugins_finalizer_mode to a more generic qt6_set_finalizer_mode that can enable or disable multiple different modes. For now the only available mode is "static_plugins" which handles the behavior of the old function name. The mode can be enabled by calling qt6_set_finalizer_mode(${target} ENABLE MODES "static_plugins") Note that the function is re-tagged as being in Technical Preview. Ideally we would not need it at all. But we need to provide some workaround for the limitations of linking Qt static plugins in CMake on Linux-y platforms that use bfd ld or ld.gold. The workaround does not work well with dependencies wrapped in generator expressions which is why we can't confidently advertise it as a proper solution. Our hope is that this can be fixed in future upstream CMake versions and the function can be removed. See 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 for details. Adjust the tests due to the renamed and removed functions. Amends 19e789bace887105badae83c0a79429bbf8e8221 Amends cdbb390c4a9b8d53cfcfd0884e6720423ce5e126 Amends a25027eecb3829a65543d0e8ab00c74e1b1a21c5 Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Amends a3c430f390b379d874916d4c9ff02af5323af1bd Pick-to: 6.2 Fixes: QTBUG-95169 Task-number: QTBUG-95601 Task-number: QTBUG-95603 Change-Id: I51b85f776ec29fc04fed1a637eba7d1f60609e69 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Avoid to call _qt_internal_set_up_static_runtime_library() twiceLi Xinwei2021-08-031-2/+1
| | | | | | Pick-to: 6.2 Change-Id: I28985470b3e0b88befbbd2d62a027670d7d6c822 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Use correct MSVC runtime library for Qt object librariesAlexandru Croitor2021-07-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | If Qt was configured with -static-runtime which implies MultiThreaded -MT flag, the plugin initializer object libraries were still compiled with the default -MD flag. When an application linked to Qt, that caused linking to fail with mismatched symbol errors between the application symbols and the plugin initializer object library symbols. Make sure to set the MSVC_RUNTIME_LIBRARY property on both plugin initializer and resource object libraries, depending on the value of QT_FEATURE_static_runtime. We did set the property for resources added by qt_internal_add_resource, but not for the resource created by the public qt6_add_resources counterpart. Pick-to: 6.2 Fixes: QTBUG-95043 Change-Id: Ia543cd0241db94a12080be2655ad420fe9ad3f24 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Export info if an object lib target is a plugin initializerAlexandru Croitor2021-06-171-0/+5
| | | | | | | | | | | | Needed for qtdeclarative so we can filter out which object library should go into which export set, because qt_internal_add_qml_module can create both a backing library export set and a plugin export set. The plugin initializer object lib should go to the plugin export set. Pick-to: 6.2 Task-number: QTBUG-92933 Change-Id: I0fce131eff75a0b3090ac0fbb2a12ecfcba5e38d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Add TODO to apply generalized object library linking approachAlexandru Croitor2021-06-171-0/+3
| | | | | | Pick-to: 6.2 Change-Id: I1ea368e81d8b055ef353a0f021f188b45588c937 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Set the plugin class name for qml pluginsAlexandru Croitor2021-06-171-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | 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: Revise plugin finalizer mode usageAlexandru Croitor2021-05-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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: Introduce finalizer mode handling of static pluginsAlexandru Croitor2021-05-201-2/+180
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-25/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Don't do plugin initialization for static librariesAlexandru Croitor2021-05-171-0/+7
| | | | | | | | | | | | | | | | | | | | Q_IMPORT_PLUGIN generates a global static symbol that initializes a plugin. If this symbol is added to a static library and the library is then linked to an executable, the linker decides that the symbol is unused (because nothing references it) and discards it. This means there's no point to compile the Q_IMPORT_PLUGIN containing files into static libraries. Change the generator expression we use for plugin propagation via associated modules to not compile and link the plugin initialization object file into a static library. Pick-to: 6.1 Task-number: QTBUG-80863 Change-Id: Ide32c0124c1e313c352a72280ce32ce9fbe8fff1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Hide qt plugin static import source files in a dot folderAlexandru Croitor2021-05-111-1/+1
| | | | | | | | | To keep the build directory tidier. Task-number: QTBUG-92933 Change-Id: I27213185a78b292bda7ae34bbc8161d4b5583872 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Refactor handling of static pluginsAlexandru Croitor2021-05-111-0/+156
Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-26 08:16:53 +0000