-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compiler support for libprotoc <= 2.5.0 #109
Conversation
…require service/client code
…rty plugin interface via stdin/out
…fields where the message is not defined in the given file
Bump. |
I pulled this down, but I could not get specs to run. |
I'm curious what you think about using erb templates for generating the code. If creating a new compiler was simply a matter of providing a new set of erb templates, that would be sweet, but it may not be possible. |
I agree the template route would be nice, haven't attempted it but it does seem difficult to get right (e.g. readable). |
let's give it a try |
Code generator passing specs
I'd love to see this rolled as I only installed the latest protobuf compiler when I rebuilt my laptop and I'm anxious to start compiling again! You don't even want know how many things I'm going to be compiling once this rolls out. It's going to be epic! |
…1.9) This paves the way for having inf, -inf, nan default values for float/double fields.
…elds Also adds test/default.proto test file to inspect the generated code visually.
Compiler support for libprotoc <= 2.5.0
Replaces the C++ generator with protoc-gen-ruby.
Per the Protobuf Language Guide recommendation, I've rewritten the
generator to be plugin-based. That is, a ruby program that reads from
STDIN a CodeGeneratorRequest message and writes to STDOUT a
CodeGeneratorResponse message.
This makes the generator more flexible since we can utilize ruby to
generate the correct ruby classes for a given proto. And we like ruby.
This has the ultimate benefit that we will be able to support new
versions of libprotoc much easier since it simply involves updating the
plugin.pb and descriptor.pb files on a new release. Obviously we'd want
to evolve the message DSL to support new released features, but at the
very least this change makes it so that the the compiler doesn't care
which version of libprotoc you have installed on your machine. It Just
Works™.
There is parity between the old and new compiler in terms of compilation
output (other than whitespace diffs). I'm looking for feedback on the
composition of the classes that perform the generation. I'm not married
to it but it was an attempt to make a more flexible system for generating
output classes. Ultimately I'd like to design a DSL for generating output
files such that you could use this gem but supply your own output
generators, which would allow you to generate ActiveRecord models, etc.
Feedback, please.