> On 3. Jul 2023, at 15:29, Lisandro Damián Nicanor Pérez Meyer > <perezme...@gmail.com> wrote: > > Hi! > > El lunes, 3 de julio de 2023 05:26:11 -03 Alexandru Croitor escribió: >>> On 30. Jun 2023, at 20:04, Lisandro Damián Nicanor Pérez Meyer >>> <perezme...@gmail.com> wrote: > [snip] >>> I recently noted the CMake variables QT_SKIP_AUTO_PLUGIN_INCLUSION and >>> QT_SKIP_AUTO_QML_PLUGIN_INCLUSION, which default to undefined. >>> >>> If I understand correctly the CMake file for searching for plugins are >>> there because: >>> >>> - One needs to find them when doing a static build in order to add them to >>> the final static object. >>> - One might use it to find the plugins and copy them when bundling >>> applications. >> >> That's right. >> >> For static plugins, the loading of plugin Config files and the availability >> of the cmake targets is needed for final linking purposes and also at >> configure time for running qmlimportscanner, and other qml tooling. >> For shared plugins, the targets are needed for deployment / bundling >> purposes (so runtime deps). >> >> One particular case which I'm not sure if it's used right now, but was >> brought up in various (private) discussions, is creating static qt plugins >> in a shared qt build. >> In a more recent discussion, it was about providing a static plugin >> containing just image assets. > > Perfect, so my understanding was more or less correct. So far none of the > above are use cases expected for a distro build. > >> Depending on what the plugin is linked to in the end, for example a qt tool >> in another repo, the plugin target would need to exist at build time, and >> thus the config files loaded. >> In this case, even a distro would have to load the file. > > And that would be a runtime dependency the tool has on the plugin, which is > just OK. If done properly that plugin will be installed due to packaging > dependencies. >
I don't think that's a runtime dependency, it's a build time dependency, hence the Config files need to be loaded. To summarize the hypothetical case: qtbase is shared Qt build, so libQt6Gui.so, etc qtbase/src/plugins/icons/libqicons.a is a static qt plugin, even though Qt is a shared build. It belongs to the Gui module. qttools/src/tools/designer is an app. It needs to link to libqicons.a at build time. The qttools/src/tools/designer/CMakeLists.txt will refer to it via a CMake Target name e.g Qt6::QIconsPlugin, hence the Qt6IconsPluginConfig.cmake package needs to be found and loaded. That would usually be done automatically via the find_package(Qt6 COMPONENTS Gui) call because the default is to load all plugin config files. I suppose if the automatic loading is disabled, we can be explicit and add a find_package(Qt6 COMPONENTS IconsPlugin) in qttools/src/tools/designer/CMakeLists.txt and it would still work in your distro case. So TLDR, should be safe for your to disable the automatic loading of plugins during a shared Qt distro build atm. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
