protoc has a few "plugins" that are built-in to the binary, but if one wants to add support for a custom language or custom output (as these bindings do), protoc can be extended to call a program of the form protoc-gen-PLUGIN_NAME, and that plugin is triggered when running protoc --PLUGIN_NAME_out=. protoc expects the plugin to write a Protobuf message on stdout, and in turn writes files to the file system. The problem with this invocation is it can be nightmarish to set up a debugger properly because the plugin is not run directly, but is instead forked from another process. And because protoc also slurps stdout, the plugin must be careful to only log using stderr.
However, fitting into a plugin isn't strictly necessary; an alternative approach (which is what this PR swithces to):
use protoc to dump out FileDescriptorSetProto to the filesystem
run a bespoke command (that can be started from a debugger!) that:
a. takes that FileDescriptorSetProto as input
b. processes them as needed
c. writes to the file system
There isn't a ton of benefit in fitting into protoc's plugin API for anyone except those that are deeply familiar with how protoc works, and even then I'm not sure it's worth it. Being able to run the code generator as a simpler invocation from a debugger, set breakpoints and watches, etc. seems far more valuable.
This approach also makes the Makefile simpler because a single output is produced from the .proto munging steps--just the singular FileDescriptorSet proto output, which contains the full set of information from all files.
This also updates the bindings to use Daml 2.8.1 protobuf files.
protochas a few "plugins" that are built-in to the binary, but if one wants to add support for a custom language or custom output (as these bindings do),protoccan be extended to call a program of the formprotoc-gen-PLUGIN_NAME, and that plugin is triggered when runningprotoc --PLUGIN_NAME_out=.protocexpects the plugin to write a Protobuf message on stdout, and in turn writes files to the file system. The problem with this invocation is it can be nightmarish to set up a debugger properly because the plugin is not run directly, but is instead forked from another process. And becauseprotocalso slurps stdout, the plugin must be careful to only log using stderr.However, fitting into a plugin isn't strictly necessary; an alternative approach (which is what this PR swithces to):
protocto dump outFileDescriptorSetPrototo the filesystemFileDescriptorSetProtoas input b. processes them as needed c. writes to the file systemThere isn't a ton of benefit in fitting into
protoc's plugin API for anyone except those that are deeply familiar with howprotocworks, and even then I'm not sure it's worth it. Being able to run the code generator as a simpler invocation from a debugger, set breakpoints and watches, etc. seems far more valuable.This approach also makes the
Makefilesimpler because a single output is produced from the.protomunging steps--just the singularFileDescriptorSetproto output, which contains the full set of information from all files.This also updates the bindings to use Daml 2.8.1 protobuf files.