Sorry if this is a bit of a newbie question, but I'm new to both
protobuffers and scons. What's the easiest way to get .proto files to
compile to .pb.cc and .pb.h files? I know you guys use scons at
google, so I'm hoping that there's a cut-and-paste solution - but if
now, can someone recommend
If you want something that's likely to work with other languages, I'd just
implement RPC over HTTP. Assuming you have HTTP support in R already it
should be pretty straightforward. Otherwise you'll have to look very
carefully at the third-party RPC implementations to figure out which ones
are
Wanted to hear the community thoughts on adding another option to
support java_implement_interface.
I think it would be very beneficial to be able to have the protoc
generate code
that would be implementing some signature interfaces in the Java
world.
Unlike Python or Ruby, where if the method
The main problem with this is logistical: By declaring that a protobuf
class should implement a Java interface, you are making protoc-generated
code depend on hand-written, app-specific code. This means that the build
system must support declaring such dependencies, and that the .proto files
Sorry, forgot to mention. I am using Java. This started failing after
having to regenerate the code since one of the dependent classes changed.
Here is the exception details.
java.lang.IllegalArgumentException: Invalid embedded descriptor
for Assertion.proto
message
Is it possible that you passed a different --proto_path when you were
compiling Issuer.proto, Subject.proto, or Conditions.proto than you did when
compiling Assertion.proto? You need to make sure you pass the same
proto_path in all cases. (The default proto_path is the current directory,
so if
BTW, I don't know what could cause a stack trace to be null. Are you
catching the exception somewhere and then replacing the stack trace?
On Mon, Nov 23, 2009 at 6:55 PM, Kenton Varda ken...@google.com wrote:
Is it possible that you passed a different --proto_path when you were
compiling
Sorry, I thought I had read in an interview somewhere that you guys
were using scons internally. And I actually can get scons to run
protoc, I'm just having trouble getting it to read the .proto files
from the right source directories and write the .pb.cc and .pb.h files
to the right build
Google's build system requires all dependencies to be explicitly declared
and enforces this. This is needed in order for the system to scale to very
large code trees: when we want to compile a particular program or test, we
want to compile only the things it depends on, not the whole tree. The
For some reason this thread got forked: here is the second copy:
http://groups.google.com/group/protobuf/browse_thread/thread/c4efd9f017d0b014?hl=entvc=2
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to
Kenton,
Those are all good points, I agree with you that this kinda coupling
could be dangerous and cause trouble if mismanaged.
I'm trying to think of a way to keep this protoc safe but at the same
time provide the kind of functionality the interface declaration would
bring.
Problem is that
11 matches
Mail list logo
