[Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION

[Lisandro Damián Nicanor Pérez Meyer]

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.

> And there's no infrastructure yet to split loading static / shared plugin Config files.

Nor I think it will be needed, at least in the current status quo.

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

But only at runtime, not build time (with the direct-dependency exception I mentioned above, but again, that's expected and handled).

Yes, there _might_ be some project that requires finding the plugin... if there is one they can easily switch the variable on on that specific case. But on a distro they will still need to add the package with the required plugin(s) as a build dependency, and normally that's just enough.

As another data point: we in Debian/Ubuntu have been removing plugins' CMake files for Qt 5 without a single issue neither for Qt nor all the rest of the  huge set of applications/libraries using it.

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

No worries at all, I can always patch qtbase/cmake/QtPlugins.cmake.in and qtbase/cmake/QtPostProcessHelpers.cmake to invert the default state on our builds. That will really help us **a lot** because:

- Neither Qt nor anything that builds on Qt will need to install plugins "just because they are referenced by CMake". This is a huge use case, because it really brings down the amount of packages required to be installed in order to build stuff.
- We will not be forced to remove the plugins' CMake files, as at that point they become irrelevant. Even better, if someone at some point really needs them they can still use it (but again, I fail to see how because they will need to add the build dependency to the packaging non the less).

Knowing that, at least for the moment, my assumptions on plugins are OK and that the behavior can be brought back on a per-case base it is more than enough. If at some point it is deemed necessary to avoid the patch and centralize it somehow, the better.

Thanks for your time!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230703/441dca3b/attachment.sig>