On Saturday, November 10, 2018 at 5:33:11 PM UTC-5, Nadav Samet wrote:
>
> Michael,
>
> A protoc plugin is a program that receives a serialized 
> CodeGeneratorRequest message via its stdin, and writes a 
> CodeGeneratorResponse to its stdout.
>
> You asked where the CodeGeneratorRequest comes from. The answer is that 
> the message is defined here 
> <https://github.com/protocolbuffers/protobuf/blob/446e34ffc71ad458c21c60529cbcdc1de74e4c3d/src/google/protobuf/compiler/plugin.proto#L67>.
>  
> Assuming your plugin is named protoc-gen-boilerplate, then when you invoke 
> protoc like this:
> protoc --boilerplate_out=outdir file1.proto [...]
>
> Then protoc would parse the proto files, prepare a CodeGeneratorRequest 
> and pipe it into your plugin. That request object contains a representation 
> of all the files you passed in the command line as well as the files their 
> transitively import. Your plugin should parse the request and print out a 
> serialized CodeGeneratorResponse. Unless you set an error message, protoc 
> would create the files you specified in your response. The plugin can be 
> written in any language, but if you use some of the supported languages (at 
> least C++, Python and Java, but probably others), you'll find a method 
> named something like DescriptorPool.BuildFile which would convert a 
> FileDescriptorProto to an higher-level object (FileDescriptor) which is 
> easier to work with.
>
> Plugins are pretty simple to write (look online for examples). I would 
> advise not writing a parser for proto files manually, since you'll be 
> chasing a moving target - over time language features get added albeit not 
> very often. It would also be hard to match the language spec perfectly.
>

I guess I am not sure quite where to begin. I've downloaded the protoc 
compiler, which itself has a set of proto files, but no target language 
level generated code.

Am I accurate in assuming I run those through protoc itself to my target 
language, in this case I suppose C++?

On Windows, what form does the plugin need to take? DLL? Executable file?

These are the sort of nibblets I think that would make it more evident 
where to pick up and run with it.

Examples of this appear to be few and far between, if at all.

Absent examples, I am working on a Boost Spirit Qi parser in the meantime, 
which the learning curve is not a plateau, I can agree there. It's not 
terrible to work through, and I end up with an AST that I know forwards and 
backwards without too much extra effort once the rules have done their 
synthetic magic.

Cheers, thank you!

On Thursday, November 1, 2018 at 6:14:54 PM UTC-7, Michael Powell wrote:
>
>> Hello, 
>>
>> I'm a bit confused. I thought I was grasping it earlier, then I 
>> thought I wasn't ... What is the starting point developing a protoc 
>> plugin? 
>>
>> What I want to accomplish is processing a .proto (v2) and generating 
>> some C# boilerplate code for it. I'm not generating a proto adapter 
>> itself, per se, but C# DSL that would be used to support it. 
>>
>> The starting point for me would seem to be receiving the compiler 
>> request, but that itself is a .proto, which leaves me a bit confused. 
>> Where do you obtain that from? Or are you starting by compiling those 
>> .protos from the bits bundled with the protoc.exe compiler? 
>>
>> What I want is to just have the descriptors drawn from the target 
>> .proto(s) themselves. That's it. A full-on plugin seems like a little 
>> bit of overkill. 
>>
>> Suggestions? 
>>
>> Thanks so much! 
>>
>> Best regards, 
>>
>> Michael Powell 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Reply via email to