Details
-
Technical task
-
Resolution: Unresolved
-
P2: Important
-
01d84ffc7 (dev)
Description
= done
= to be done
qmltc must be integrated into the QML's CMake API:
- The output of qmltc is .h and .cpp files that represent the compiled code
- Executables: these files become part of the binary, allowing to #include the header file and build/link the definitions in the cpp file as part of the normal C++ compilation
- Shared libraries: on top of just becoming a part of the binary, extra things are required
- .h files become part of the "public includes" (CMake thing)
- two case to consider here!
- .h files generated by qmltc and
- .h files written by the users!
- should both be handled in the same way?
- two case to consider here!
- generated code must be exported thus Q__EXPORT macro is required for each generated class. most likely, every binary would need own *independent export macro (to avoid collisions)
- CMake-specific "flags" (a.k.a. target properties) might be required to distinguish qmltc-processed libraries from all others
- .h files become part of the "public includes" (CMake thing)
- Static libraries: similar to shared libraries. Might require additional care but, in general, rules are the same.
- Applicable to all: qmldir of the qmltc-processed target must be available to qmltc (otherwise, type information may be missing)
- QML module interaction
- linking a user project against a QML module automatically requires the usage of that module's qmldir AND C++ include directories (if there are C++ bits exposed to QML)
- qml files (source code) of the module must be available to qmltc, meaning:
- source code has to be available
- (optional) list of compiled QML files (e.g. in a CMake target property)
- for better user experience we might want to only deal with QML modules that are qmltc-processed ("there's an explicit flag that qmltc had compiled parts of that module OR the module's QML files are not used by qmltc")
-
-
- or at least reject modules that contain .qml files if the module was not compiled by qmltc
-
- The CMake API of qmltc must either be embedded into qt_add_qml_module() or rely on that function's meta information
- there's an implicit dependency on qmldir generation
Attachments
Issue Links
- depends on
-
QTBUG-102188 Distringuish qmltc-compiled QML modules from non-compiled ones in qmldir
- Reported
- is required for
-
QTBUG-122233 Type compiler unable to use components from imported modules
- Reported
-
QTBUG-119121 [qmltc] A QML file which imports qtquick.controls2 does not compile
- Closed
-
QTBUG-121592 Attached ScrollBar and ScrollIndicator fail when using QML Type Compiler
- Closed
- relates to
-
QTBUG-105538 qmltc evolution collection task
- Open
-
QTBUG-109295 qmltc: support qml modules (static + shared ones)
- Reported
-
QTBUG-96041 Support language/engine features sufficient for the prototype
- Closed
- mentioned in
-
Page Loading...
Gerrit Reviews
For Gerrit Dashboard: QTBUG-96040 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
371595,8 | qmltc: add cmake api and simplest file writer | dev | qt/qtdeclarative | Status: MERGED | +2 | 0 |
377485,8 | qmltc: support user-specified namespaces in the generated code | dev | qt/qtdeclarative | Status: MERGED | +2 | 0 |
379323,5 | qt6_target_compile_qml_to_cpp: improve QT_QMLTC_FILE_BASENAME handling | dev | qt/qtdeclarative | Status: MERGED | +2 | 0 |
381052,5 | qmltc: Be aware of macOS frameworks when running manual MOC | dev | qt/qtdeclarative | Status: MERGED | +2 | 0 |
450418,18 | qmltc: export generated classes | dev | qt/qtdeclarative | Status: MERGED | +2 | 0 |