El lunes, 3 de julio de 2023 10:49:43 -03 Alexandru Croitor escribió: > > > 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.
Well, any static file (*.a) created as part of a shared lib build is considered a development file, thus packages into qt-<submodule>-dev. In this case qtbase, so qt6-base-dev, which will be installed for any submodule requiring to build with Qt, so the file will be present. Now the question is: is the CMake file used to only check for it's presence or will designer fail to load the static file? > 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. That would actually be ideal, because it decouples a _real_ build dependency with just the fact of checking a plugin is there. > So TLDR, should be safe for your to disable the automatic loading of plugins > during a shared Qt distro build atm. So far it has worked, but of course I'll have more feedback later on :-)
signature.asc
Description: This is a digitally signed message part.
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
