Re: Strange Eclipse compiler error.
Hi, I found the culprit and it is not Protobuf. Our project uses groovy, and as such I installed the Groovy Eclipse plugin which incidently contains an Eclipse JDT patch. Removing this patch makes everything compile normally. I filed a bug on the groovy bug tracker. Sorry for the noise, On Thu, 2009-09-10 at 16:53 -0700, Kenton Varda wrote: Doesn't make any sense to me. Let me know if you find a solution. On Mon, Sep 7, 2009 at 8:16 AM, Brice Figureau brice +...@daysofwonder.com wrote: Hmm, more information on the issue below: On Mon, 2009-09-07 at 16:52 +0200, Brice Figureau wrote: I'm using eclipse (3.5) on a large project using protobuf v2.1.0, and I'm encountering tons of strange Eclipse java compiler error on every protobuf java generated code. All the errors looks like this one: The method mergeFrom(Message) is ambiguous for the type GeneratedMessage.BuilderBot.PBBot.Builder I created a new java eclipse project and added only the generated java files, and they do compile fine, so the issue is certainly the compilation of the combination of those generated files and my other java files... But I'd appreciate any help... -- Brice Figureau My Blog: http://www.masterzen.fr/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
RE: protoc feature question
http://www.zeroc.com/vsplugin.html From: Kenton Varda [mailto:ken...@google.com] Sent: Friday, September 11, 2009 12:18 PM To: George Georgiev Cc: Protocol Buffers Subject: Re: protoc feature question Is there precedent for other tools like protoc providing this kind of behavior? I've never heard of such a thing. E.g. GCC does not check if the .cc file is newer than the .o file before compiling. On Fri, Sep 11, 2009 at 8:41 AM, George Georgiev georgi.georg...@citrix.commailto:georgi.georg...@citrix.com wrote: Just one more thing. I forgot to mention that the output is just one side of the coin. What about of the dependencies. If I have a proto file that includes another proto file now I need to extend the makefile to handle this too. What about if the dependencies are more complex and dynamic. My personal opinion is that the best place to handle all this is the protoc itself. -G From: protobuf@googlegroups.commailto:protobuf@googlegroups.com [mailto:protobuf@googlegroups.commailto:protobuf@googlegroups.com] On Behalf Of George Georgiev Sent: Thursday, September 10, 2009 6:19 PM To: Kenton Varda; Protocol Buffers Subject: RE: protoc feature question That seems reasonable to me. If you changed the package of any of your other Java files it would mean moving source code around which would certainly require updating the makefile. for me too, but some colleagues find this as extra pain Another idea is to have protoc output the .java files into a temporary directory, and then jar up that whole directory, and consider the .jar to be the output of the operation. That way you have just one output and it's the same regardless of the content of the .proto files. this means I will need to rebuild the whole jar file if any of the proto files is changed It looks like my use case isn't usual, but the way I'm using protobufs involves permanent updates of the proto files. Anyway, I could live with it as is. Thanks, George From: Kenton Varda [mailto:ken...@google.commailto:ken...@google.com] Sent: Thursday, September 10, 2009 5:45 PM To: George Georgiev; Protocol Buffers Subject: Re: protoc feature question On Thu, Sep 10, 2009 at 4:59 PM, George Georgiev georgi.georg...@citrix.commailto:georgi.georg...@citrix.com wrote: So you suggest if I change the java package in a proto file, I to update the makefile too? That seems reasonable to me. If you changed the package of any of your other Java files it would mean moving source code around which would certainly require updating the makefile. Another idea is to have protoc output the .java files into a temporary directory, and then jar up that whole directory, and consider the .jar to be the output of the operation. That way you have just one output and it's the same regardless of the content of the .proto files. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: protoc feature question
On Fri, Sep 11, 2009 at 1:51 PM, Monty Taylor mord...@inaugust.com wrote: Well, the build-if-newer is handled by either Make or VisualStudio, not by the compiler in either case. Right, the link is to a build system plugin. I'm all for build system plugins for protocol buffers but those wouldn't involve changing protoc. As for the dependencies ... gcc _does_ have options (-MD -MP -MF) to spit out depends that it determines from following include files in Makefile format. I'd definitely accept adding an option like that to protoc, if someone sends me a patch, though this is pretty different from what George was asking for. So I would be in favor of protoc including support for the second. I have no interest (and actually a negative interest) in protoc handling the first thing - that's a job for a build system) Sounds like we're in agreement here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: Out of sources cross-compiling
Good call. I've committed this as rev 226. Thanks. On Fri, Sep 11, 2009 at 7:21 AM, pierreK pierre.keste...@cea.fr wrote: Hello, [I'm using protobuf-2.2.0] I would to suggest a minor modification to the file src/Makefile.am Currently an out-of-source build works only for native build. When trying to do a cross-compilation, it works inside the sources (i.e. executing the configure script inside the source tree), but not doing it out of the source tree (i.e. executing something like ../ protobuf-2.2.0/configure --with-protoc=/usr/local/bin/protoc -- host=powerpc-linux --prefix=/opt/powerpc-linux). When cross-compiling, it is convenient to have one source tree and several build directories (one per target). Doing the out of source cross-compiling, when I type make, I get the following error (associated to building unittest_proto_middleman defined in src/Makefile.am) : /usr/local/bin/protoc -I../../protobuf-2.2.0-orig/src --cpp_out=. google/protobuf/unittest.proto ... ... google/protobuf/unittest.proto: No such file or directory make: *** [unittest_proto_middleman] Erreur 1 This is due to the fact that this target has 2 versions depending on conditional USE_EXTERNAL_PROTOC. To avoid this minor problem, I suggest to change this rule so that $ (protoc_input) is fully expanded --- Makefile.am.orig +++ Makefile.am @@ -234,7 +234,7 @@ if USE_EXTERNAL_PROTOC unittest_proto_middleman: $(protoc_inputs) - $(PROTOC) -I$(srcdir) --cpp_out=. $(protoc_inputs) + $(PROTOC) -I$(srcdir) --cpp_out=. $^ touch unittest_proto_middleman else Pierre Kestener. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: RPM Spec File
Hmm, now I'm confused. They imply that libprotobuf should be linked with both -pthread *and* -lpthread, as the latter registers libpthread as some sort of auto-loaded dependency, I guess. The internet does not provide very much useful info on what the real best practice is. On Wed, Sep 9, 2009 at 3:40 PM, Kevin Deldycke ke...@deldycke.com wrote: On Wed, Aug 19, 2009 at 20:35, Kenton Vardaken...@google.com wrote: Well, I haven't observed this problem on other platforms or distros. What happens if you write a very basic program that uses pthread_once, then try to compile it with -pthread (but not -lpthread)? If this doesn't work, I suspect something is wrong with the way GCC was built for your distribution. FYI, I've just reported the issue in Mandriva's bug tracker: https://qa.mandriva.com/show_bug.cgi?id=53578 -- Kevin Deldycke • blog: http://kevin.deldycke.com • band: http://coolcavemen.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
RE: protoc feature question
Sorry guys. Yes, I asked for something else. My bad. How exactly this will handle the problem with the different output files? From: Kenton Varda [mailto:ken...@google.com] Sent: Friday, September 11, 2009 2:59 PM To: Monty Taylor Cc: George Georgiev; Protocol Buffers Subject: Re: protoc feature question On Fri, Sep 11, 2009 at 1:51 PM, Monty Taylor mord...@inaugust.commailto:mord...@inaugust.com wrote: Well, the build-if-newer is handled by either Make or VisualStudio, not by the compiler in either case. Right, the link is to a build system plugin. I'm all for build system plugins for protocol buffers but those wouldn't involve changing protoc. As for the dependencies ... gcc _does_ have options (-MD -MP -MF) to spit out depends that it determines from following include files in Makefile format. I'd definitely accept adding an option like that to protoc, if someone sends me a patch, though this is pretty different from what George was asking for. So I would be in favor of protoc including support for the second. I have no interest (and actually a negative interest) in protoc handling the first thing - that's a job for a build system) Sounds like we're in agreement here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: protoc feature question
On Fri, Sep 11, 2009 at 3:25 PM, George Georgiev georgi.georg...@citrix.com wrote: How exactly this will handle the problem with the different output files? It won't -- like I said, it's not what you were asking for. We're still saying that your issue is the responsibility of the build system. Sorry. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
RE: protoc feature question
javac doesn't produce a java file - what you mean it will put it in its package subfolder? -Original Message- From: henner.zel...@googlemail.com [mailto:henner.zel...@googlemail.com] On Behalf Of Henner Zeller Sent: Friday, September 11, 2009 4:34 PM To: George Georgiev Cc: Kenton Varda; Monty Taylor; Protocol Buffers Subject: Re: protoc feature question On Fri, Sep 11, 2009 at 4:22 PM, George Georgiev georgi.georg...@citrix.com wrote: I think that protoc already has a compromise with pure compiler functionality - namely placing the java class in the package subfolder. javac does the same: compile a java file and it will put it in its package subfolder. But javac as well lets the build system handle the dependencies. -h --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: protoc feature question
On Fri, Sep 11, 2009 at 4:22 PM, George Georgiev georgi.georg...@citrix.com wrote: I think that protoc already has a compromise with pure compiler functionality - namely placing the java class in the package subfolder. Since you have so strong fillings not to make another compromise you probably will consider to remove the pervious one, or at least to make it optional? protoc outputs multiple files -- e.g. if you give it multiple inputs or if you use the java_multiple_files option. So the output location has to be a directory. And anyway, it's Java that imposes the rules about directory layout. I have been considering adding an option to output to a .jar file instead of a directory. This would get you a trivially-predictable output while still following Java's rules about directory layout. BTW, this may not be helpful to you, but the Java code generator is already capable of generating a separate file containing a list of outputs by invoking it like: protoc my.proto --java_out=output_list_file=list.txt:path/to/outdir This will place a file list.txt into the output directory (path/to/outdir) which is a simple text file listing the names of the other files generated, one per line. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
