-
Suggestion
-
Resolution: Unresolved
-
P2: Important
-
None
-
None
Problem
The tests at QTBUG-137199 show that different QML tools receive different import paths.
This is confusing: Even if the developer fixes all qmllint warnings, it's still possible that qmlsc/qmlcachegen are unable to find a module, causing the project to miss out on achievable optimizations.
Suggestion
Import paths are currently stored in *.rsp files and passed to qmllint. Could the *.rsp import paths be refactored out and shared between all build-time tools (qmllint, qmlsc/qmlcachegen, and qmltc)? This could simplify maintenance and reduce the risk of future divergence.
Detailed discussion
ulherman commented in QTBUG-137199 that
One thing to consider with qmltc and qmlsc is that they generate code based on what they detect. They can only do so if they can be very certain that the same modules they see at compile time will also be there at run time. Otherwise you get crashes.
I contend that we should use the lowest common denominator (the "safest" list of paths) for all tools. If we're being strict with qmlsc/qmltc to avoid importing the "wrong" module from the "wrong" path, then we should apply the same standards to qmllint.
- relates to
-
QTBUG-141555 Implement a common mechanism for passing import paths to qmllint and qmlls
-
- Reported
-
- resulted from
-
QTBUG-141242 QML file that imports the module it belongs to results in "Failed to import" qmlls warning
-
- In Progress
-
- split from
-
QTBUG-137199 Minimize discrepancies in QML import paths between different QML tools, out-of-the-box
-
- Reported
-
| For Gerrit Dashboard: QTBUG-141554 | ||||||
|---|---|---|---|---|---|---|
| # | Subject | Branch | Project | Status | CR | V |
| 687517,1 | cmake: use qmllint's import path for qmlimportscanner | dev | qt/qtdeclarative | Status: ABANDONED | 0 | 0 |