[Development] Extending moc to generate easily accessible metatype descriptions

[Ulf Hermann]

> 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 
some conventions.

> 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 
build system.

> 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 
> then?)

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 
json file.

br,
Ulf