[Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION

[Alexandru Croitor]

> On 30. Jun 2023, at 20:04, Lisandro Damián Nicanor Pérez Meyer <perezmeyer at gmail.com> wrote:
> 
> Hi!

Hi

> 
> 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.

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 there's no infrastructure yet to split loading static / shared plugin Config files.

> 
> Turns out that both the above use cases make no sense in Qt distro builds like Debian, **especially** when compiling (in other words, they are not build time dependencies, just run time dependencies).
> 
> So I would __love__ to make those two variables enforced by qtbase itself. Granted, I could just patch out the required files in qtbase/cmake/ and check if the variable is defined. If it is, use it, else switch it to ON. But before going that route I would love to see if there is a more elegant, upstream-provided or upstream-guided way of doing it, like "send us a patch to do exactly that an we will take it". In this case please how I should achieve that, taking into account that I want this to be an opt-out, not an opt-in as currently is.

In the context of distros, while it might not make sense to load the plugin config files during a shared library qt build  (aside from the more involved use case above), those are still needed for end user-projects.

So we can't skip including the files by default, the decision whether to load the files depends on the intent / where the config files need to be used.

A possible approach could be to detect if we are doing a qt build, in which case QT_SKIP_AUTO_PLUGIN_INCLUSION would be considered TRUE.
Because find_package calls are done very early in every cml.txt, we usually detect that it's done for a qt build by checking for the existence of QT_REPO_MODULE_VERSION in .cmake.conf files that are included before the find_package.

Also, because i don't feel safe doing this for all qt builds (there might be other reasons the qt build might want to know about plugin targets in the future, outside the context of distro builds), i would protect such logic behind a new option, something like QT_BUILDING_DISTRO.

But at that point if distros have to set that, it's the same as setting QT_SKIP_AUTO_PLUGIN_INCLUSION to TRUE themselves.

And the only gain would be centralising distro-specific behaviors by keeping such logic behind a QT_BUILDING_DISTRO check directly in qt code.

Not sure if this is all worth it.