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 :-)

Attachment: signature.asc
Description: This is a digitally signed message part.

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to