Skip to content
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

Merged
merged 20 commits into from
Aug 20, 2013
Merged

Compiler support for libprotoc <= 2.5.0 #109

merged 20 commits into from
Aug 20, 2013

Conversation

localshred
Copy link
Contributor

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.

@localshred
Copy link
Contributor Author

/cc @abrandoned @liveh2o @devin-c

@localshred
Copy link
Contributor Author

Bump.

@quixoten
Copy link
Contributor

I pulled this down, but I could not get specs to run.

@quixoten
Copy link
Contributor

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.

@localshred
Copy link
Contributor Author

I agree the template route would be nice, haven't attempted it but it does seem difficult to get right (e.g. readable).

@abrandoned
Copy link
Contributor

let's give it a try :shipit:

@liveh2o
Copy link
Contributor

liveh2o commented Aug 19, 2013

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.
localshred added a commit that referenced this pull request Aug 20, 2013
Compiler support for libprotoc <= 2.5.0
@localshred localshred merged commit e3085af into master Aug 20, 2013
@localshred localshred deleted the code_generator branch August 20, 2013 17:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants