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)
    • 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
  • 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 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")
• 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