In Java, the dependencies you mentioned are provided by Gradle. We
<https://github.com/thesamet/protoc-plugin-in-java/blob/d4e6da3cb7782aefa4d71dc93af7854079f1e07a/build.gradle#L15>
.
<https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.descriptor>
by libprotobuf, which you can build yourself of the sources.
The plugin is going to be an executable (.EXE on Windows) file.
Post by Michael PowellSo...
You've got a magic set of imports (in Java).
import com.google.protobuf.DescriptorProtos;
import com.google.protobuf.Descriptors;
import com.google.protobuf.compiler.PluginProtos.CodeGeneratorResponse;
import com.google.protobuf.compiler.PluginProtos.CodeGeneratorRequest;
Where do you get these from?
Or Assemblies or NuGet Package References in .NET / C#, or
source/libraries, ostensibly, for C/C++.
This is the question I have in getting started.
The nearest assumption I could derive is that I start with protoc.exe
(Windows) and the bundled .proto files, "compile" those to target
plugin language, and build them with the project?
Again, as a what? .DLL? .EXE?
Post by Nadav SametHi Rahul and Michael,
I put together a basic example of a protoc plugin in Java that generates
text files: https://github.com/thesamet/protoc-plugin-in-java
Post by Nadav SametThe plugin itself is an executable that gets executed by protoc, it can
be written in any language. In this instance, the plugin is written in
Java, so we use gradle to generate a shell script (or bat file for windows)
that protoc will execute to run our plugin inside a JVM. The exact
instructions to run it are in the provided README.md
Post by Nadav SametPost by Michael PowellPost by Nadav SametMichael,
A protoc plugin is a program that receives a serialized
CodeGeneratorRequest message via its stdin, and writes a
CodeGeneratorResponse to its stdout.
Post by Nadav SametPost by Michael PowellPost by Nadav SametYou asked where the CodeGeneratorRequest comes from. The answer is
that the message is defined here. Assuming your plugin is named
Post by Nadav SametPost by Michael PowellPost by Nadav Sametprotoc --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.
Post by Nadav SametPost by Michael PowellPost by Nadav SametPlugins 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.
Post by Nadav SametPost by Michael PowellI 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.
Post by Nadav SametPost by Michael PowellAm I accurate in assuming I run those through protoc itself to my
target language, in this case I suppose C++?
Post by Nadav SametPost by Michael PowellOn Windows, what form does the plugin need to take? DLL? Executable
file?
Post by Nadav SametPost by Michael PowellThese are the sort of nibblets I think that would make it more evident
where to pick up and run with it.
Post by Nadav SametPost by Michael PowellExamples 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.
Post by Nadav SametPost by Michael PowellCheers, thank you!
Post by Nadav SametOn Thursday, November 1, 2018 at 6:14:54 PM UTC-7, Michael Powell
Post by Michael PowellHello,
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.
Post by Nadav SametPost by Michael PowellTo unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
--
-Nadav
--
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
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.