[Development] Extending moc to generate easily accessible metatype descriptions
ulf.hermann at qt.io
Tue Sep 17 08:55:03 CEST 2019
> Well, unfortunetely, even moc doesn't know about all the metatypes.
> Many types don't need registration, and moc is not always aware of the
> Q_DECLARE_METATYPE declaration (but it actually should still work for
> most types)
> There are also all the custom QMetaObject (thinking of stuff like DBus,
> ActiveQt or other language bindings, or the ones created by Verdigris)
We can add something like the QML_FOREIGN declarations introduced in
https://codereview.qt-project.org/c/qt/qtdeclarative/+/248475 on the
metaobject level. A dummy struct with some macros that would tell moc
"there is a metaobject you cannot see and it has these properties".
Or we can live with the fact that we don't have all metatypes in the
json files. If you want your types to appear there you have to follow
> But this post-processing of the .json files is not necessarily something
> for moc. It could be in a separate tool. (But I realize that you can
> just add the option to the moc binary to avoid creating another small
> tool just for that.)
Yes, I can move it into an extra tool if necessary, but as that is still
part of some kind of "meta object compilation" and it's not a lot of
code, I would actually prefer to keep it inside moc.
> The question is also how does it fits in the build system? How do you
> know which .json to collect and at what stage do you do that?
moc already creates a number of files called moc_<foo>.cpp. The build
system has to deal with that already. Now it also creates files
moc_<foo>.cpp.json. The handling of those should be equivalent on a
build system level. The way it's done in qmake right now is that we
create a fake rule for the json file that depends on the moc rule but
doesn't do anything by itself. It just declares that it "creates" the
json file. I'm sure you can phrase something similar in other build systems.
> Is this going to add some burden for people using custom build systems?
You can either ignore it and live without automatic generation of
qmltypes files (and automatic registration of QML types, see
https://codereview.qt-project.org/c/qt/qtdeclarative/+/271876 for a
rough sketch), or you can adapt your build system. So, either you keep
the burden you already have, or you replace it with a different and
hopefully smaller one. The trade-off depends on the properties of your
> And how mandatory will it be? Is it ok if this does not work?
If it doesn't work you have to write your qmltypes files manually or use
qmlplugindump (although I would like to deprecate the latter, eventually).
> Also I would need to find a solution for Verdigris. (Was thinking about
> generating the json at compile time in a constexpr string put in a
> specific section of the binary, but how does it ends up in a qmltypes
That sounds like a good idea. We can probably write a qmltyperegistrar
variant that pulls its input from some ELF section instead of a separate
More information about the Development