bloomberg
Migrate mqbcmd away from XSD code generation
Types for representing admin commands in BlazingMQ are generated from an XSD
file mqbcmd.xsd, which outputs mqbcmd_messages.h. There are a number of
issues with this approach for us:
-
The tool to do this code generation is not open-source, and so we are not able to accept patches that add or change admin commands.
-
Doxygen does not understand the documentation generated in
mqbcmd_messages.h, and any modifications we do will be overwritten the next time we regenerate the file.
Furthermore, unlike other places where we use XSD code generation in BlazingMQ,
which also suffer from the same downsides, we do not gain any major benefits of
it in mqbcmd, as we do not serialize or deserialize the admin commands in any
structured way.
All of this, coupled with how relatively small this XSD, make it a good candidate to convert to non-generated code. This may be as simple as removing the XSD, blessing the current generated types as the source of truth, and converting the existing documentation over.
This may be as simple as removing the XSD, blessing the current generated types as the source of truth, and converting the existing documentation over.
The schema autogeneration tool converts this: mqbcmd.xsd: 1161 lines
Into this: mqbcmd_messages.h: 54236 lines mqbcmd_messages.cpp: 30740 lines
.xsd file contains possibly the minimal representation of a protocol. It's convenient and fast to make changes. Also, we don't really need to think too much about functions/operators defined in autogenerated code, because we have expectations how it's done in general.
If we go away from code generation from .xsd, it's another story: we will have to consider and look after all trivial operator changes in protocol definition sources, we will have to make changes in a file of scale 54k/30k lines. Working directly with these files will not only be error-prone, but will also require a lot of effort to make changes at a huge scale. I think it will quickly become unbearable.
I think in terms of a long-term effort the best way is to write our own open-source converter. Alternatively, we can postpone this problem until we have a strong demand to solve it.
The graph shows the number of bytes directly from the include directives, not counting the includes from dependencies. If we have to introduce our custom code generator, we might split the generated components across different files, so we can include only the parts that are really needed