> 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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development