Simple Q_PLUGIN_METADATA support ?

[jcelerier]

Is there a way to have support for Q_PLUGIN_METADATA, even without the JSON parsing stuff ?
that is, only the part generated by a call such as

Q_PLUGIN_METADATA(IID "org.foo.my_plugin")

?

[jcelerier]

oh well, it seems that even this is converted to JSON anyways :)

https://github.com/qt/qtbase/blob/5.11/src/tools/moc/generator.cpp#L1559

is the JSON binary format used by qt defined somewhere ?

[ogoffart]

Well, there could be a way, but it won't be easy. The question is whether this is really worth it. Q_PLUGIN_METADATA is only used for the main plugin class. You really could use moc for this. This can even be placed in a separate .h file which is there only for moc to generate the data.

If one wanted really wanted to have the equivalent feature, the macro would probably be placed outside of the class, in the .cpp file.

We could have somehting like that

W_PLUGIN_METADATA("{ IID:'org.foo.my_plugin' , className:'MyClass' , MetaData: { foo:12 } }") 

And parse the json at compile time (I think there are already libraries out there that do that.)

But I guess it would be best not to parse json and have some kind of DSL

W_PLUGIN_METADATA( w_json::object {
   {"IID", "org.foo.my_plugin" },
   {"className", "MyClass" },
   {"MetaData", wjon::object { {"foo" , 12} } }
  });

Either way, we need do get a constexpr data scructure containing the "JSON" data that we need to stream in the metadata.
Then we need to generate the Qt's binary json representation. At compile time.
This itself might get difficult because there is no documentation of this. One need to read the source code of Qt to reverse engineer it. I also did that for mocng [ https://code.woboq.org/woboq/mocng/src/qbjs.cpp.html#_ZN4QBJS6StreamlsERKNS_5ValueE ] (Getting the representation of a double might be a challenge).

Over all, I think it is a lot of work and not really worth it.
If you write a plugin, you are probably better off using an extra code generator to generate this meta data.

[jcelerier]

This itself might get difficult because there is no documentation of this.

that's what I feared ! however, looking at your code in moc-ng it looks like constexpr-ing it should not be too hard. I'll stay with moc for these files for now :p