> On 30. Jun 2023, at 20:04, Lisandro Damián Nicanor Pérez Meyer 
> <perezme...@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.

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

Reply via email to