After Meeting C++ 2022 I got inspired to start a new experiment to get QML_ELEMENT support for Verdigris. #83
QML_ELEMENT and friends macros were introduced with Qt 5.15 . Why do we need it?
lifts the need to do qmlRegisterType for each type.
allows tooling (like QtCreator) to build support for custom QML types.
We have two challenges that are solved somewhat with this PR:
Generate a metatypes.json by compiling just C++ code.
[x] Generate a string of proper JSON with C++20 code.
[x] This string is stored in a special binary section in the object files. (Works with MSVC and GCC/Clang)
Use the build system to call a tool to extract the JSON and use it for qttyperegistrar.
[x] Extract the JSON from the object files. (Works for MSVC and GCC on Linux)
[x] CMake projects can use an extra object library target as a source for the extractor, and inject into the Qt CMake functions, by providing the right target properties.
[x] Qbs projects require a patch to get something similar to object library which is then used as source for the extract tool and generates files tagged similar to those generated by the moc tool.
Extra benefits:
Added full CMake build system support.
Known Limitations/TODOs:
MacOS support is missing. Extractor tool may need to get support for mac specific object files.
The current approach for QML_ELEMENT won't work with templated objects.
Side note: This PR merges to the new develop branch. Which is basically what I proposed in #95.
After Meeting C++ 2022 I got inspired to start a new experiment to get QML_ELEMENT support for Verdigris. #83
QML_ELEMENTand friends macros were introduced with Qt 5.15 . Why do we need it?qmlRegisterTypefor each type.We have two challenges that are solved somewhat with this PR:
metatypes.jsonby compiling just C++ code.qttyperegistrar.moctool.Extra benefits:
Known Limitations/TODOs:
QML_ELEMENTwon't work with templated objects.Side note: This PR merges to the new
developbranch. Which is basically what I proposed in #95.