Create Task
Maniphest T4969

fix qml module lookup
Open, NormalPublic
Actions

Description

Failing here

http://build.neon.kde.org/job/xenial_unstable_neon-packaging_kirigami2/

basically import_paths need to be extended to construct more permutations. one for each part of the path to include the version

e.g. new stuff paths
QtQuick.2/Controls/Material - QtQuick/Controls.2/Material - QtQuick.2.0/Controls/Material - QtQuick/Controls.2.0/Material

IRC log

<sitter> [13:09:35] the import_paths are the patterns it has looked in
<sitter> [13:09:42] which yield no result https://contents.neon.kde.org/v1/find/archive.neon.kde.org/user/dists/xenial?q=*QtQuick/Controls/Material.2*
<sitter> [13:09:53] as QtQuick/Controls.2/Material should have been a pattern
<sitter> [13:10:04] how or why that is a legit path is beyond me at the moment though
<Riddell> [13:10:26] it might have changed in qt 5.8?
<sitter> [13:11:19] maybe it was always supported. the docs aren't terribly precise
<sitter> [13:11:21] http://doc.qt.io/qt-5/qtqml-modules-identifiedmodules.html
<sitter> [13:11:39] It is possible to store different versions of a module in subdirectories of its own. For example, a version 2.1 of a module could be located under com/mycompany/mymodule.2/qmldir or com/mycompany/mymodule.2.1/qmldir. The engine will automatically load the module which matches best.
<sitter> [13:11:56] that last sentence is why it is a bit fishy
<sitter> [13:12:31] but I'd assume to make this material path work the import_paths simply need to be extended with permuations where the versions are injected in every part of the path
<sitter> [13:13:20] so QtQuick.2/Controls/Material - QtQuick/Controls.2/Material - QtQuick.2.0/Controls/Material - QtQuick/Controls.2.0/Material
<sitter> [13:14:30] Riddell: ci-tooling/lib/qml/module.rb is where these paths are constructed in import_paths
<sitter> [13:15:09] that each_index in there is what needs extending. and probably moving into own method as it would blow up the method substantially

Related Objects

sitter created this task.Dec 23 2016, 12:15 PM
sitter mentioned this in T4882: package kirigami2.
jriddell added a subscriber: jriddell.Oct 3 2018, 10:46 AM

harald "there's a qt dev helper that does what we need"

sitter added a comment.EditedMar 13 2019, 1:36 PM

To add: the helper is called qmlimportscanner and generates a json blob of all modules inside a dir e.g. qmlimportscanner -rootPath . it may be compiled with qmlplugindump which introspects modules (which is more than we need unfortunately) e.g. qmlplugindump Qt.labs.folderlistmodexl 2.0.

if a module is not found for dumping, there is no dump and we know that the module is missing.

oh, and an additional problem with this is kind of that we need to actually install Qt to conduct the test. may or may not turn out a problem

sitter added a comment.EditedMar 19 2019, 9:50 AM

Oh and since qml dependencies are spreading throughout the stack now it may actually be a good idea to reinvent the system and implement it as substvars ${qml:Depends}. To that end inspecting all modules installed by a package would be useful, alas, doing that technically has Qt tech but it's not available for external use! Namely qtcreator has a thing called (IIRC) qmljs which is meant to import models of all datatypes in modules, kdevelop has a fork of it as well. Unfortunately since it is not available from the outside it's probably still easier to have custom "finding" logic.

Update: qmljs simply seems to look for qmldirs and then parses them to determine what is available. Perhaps, and this is a big perhaps, we should just write our own parser and do the same (seeing as qmljs is internal and not a program we can call). It'd probably solve the problem at hand as we'd no longer rely on inferring meaning form the paths and AFAIK all modules need to have a qmldir so it'd indeed detect all modules then.

sitter lowered the priority of this task from High to Normal.Mar 29 2019, 11:00 AM