[Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION

[Alexandru Croitor]

> On 3. Jul 2023, at 15:29, Lisandro Damián Nicanor Pérez Meyer <perezmeyer at 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 <perezmeyer at 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.