[CMake and run time dependencies] Re: Do not split QML packages

[Carl Schwan]

On Tue, Aug 15, 2023, at 2:16 PM, Sandro Knauß wrote:
> Hey,
> 
> > The policy may have seemed a good idea back then when it was introduced, but
> > in my opinion the right thing to do [after it has been the cause of so many
> > issues that could have been avoided] would be to reconsider it and ideally
> > reach the conclusion of not splitting up QML packages into a multitude of
> > small-QML packages.
> 
> The base problem, is that there is no proper way to detect QML dependencies.  
> All distribution needs to manage them manually or have some of basic scripting 
> to detect those dependencies. Keep in mind that build depdendecies != binary 
> dependencies.

While technically not correct, marking the qml modules as build dependencies has
been very helpful for preventing this sort of issues, by creating explicit compile
failures when a new qml dependency is added. Since I started adding these for
Kirigami Addons and other QML libraries, I didn't get any report coming from Fedora
users (which was previously also a source of frustration).

> 
> It won't help at all to have only one qml package per repo.
> 
> I install kirigami-addons-dev (that will install all the qml packages) as 
> build dependency, this doesn't automatically make the binary depend on any qml 
> package. So this list must managed by hand (independently if all qml is 
> shipped in one or multiple packages). Okay it is easier to just add one 
> package, but in the end it is error prune to do this all by hand. And a 
> standardized automatic way would help a lot.

If this can help, it wouldn't be difficult to maintain a list of import names for each app
and store it as a file in the repository and ensure with a CI script that the list is keep
up to date. E.g. something generated with your grep script or something similar. I have:

grep -hre '^import org.kde' -e '^import Qt' src | sed 's/import //' | sed 's/as .*$//' | sed 's/ [[:digit:]]*\.[[:digit:]]*//' | sort | uniq

We could even use qmldom for this but that might bit over-engineered. But in any case,
it would put the responsibility of keeping the list of dependencies up to date on the
app developers and then we can blame ourselves and not distros when something is
missing ;)

Cheers,
Carl