Re: [protobuf] python/setup.py
I'm a bit concerned about setting arbitrary proto compiler via environment variables. Protobuf runtime library requires exactly matching protoc generated classes to work. Separating the protoc and library potentially increased the risk of having incompatibility errors. Not sure if this would bring security issues though. Maybe you can write a wrapper script to symbol link the correct protoc in your environment. On Wed, Mar 23, 2011 at 8:36 AM, cmas...@chromium.org cmas...@chromium.org wrote: Hello! I'm a developer on Chromium OS, and we recently (today) started needing to build the protocol buffers with python support enabled in our cross-compilation environment. Passing --with-protoc to ./configure got me partway there, but then when it tried to run python setup.py build, it got intro trouble. Turns out there's logic in setup.py to go looking for the protoc that was just compiled. In a cross-compile situation, that won't work :-/ I've got a patch to allow the desired protoc to be overridden by an environment variable: diff -Naur protobuf-2.3.0-orig/python/setup.py protobuf-2.3.0/python/setup.py --- protobuf-2.3.0-orig/python/setup.py 2011-03-22 16:33:33.0 -0700 +++ protobuf-2.3.0/python/setup.py 2011-03-22 17:01:14.0 -0700 @@ -16,7 +16,9 @@ maintainer_email = protobuf@googlegroups.com # Find the Protocol Compiler. -if os.path.exists(../src/protoc): +if 'PROTOC' in os.environ and os.path.exists(os.environ['PROTOC']): + protoc = os.environ['PROTOC'] +elif os.path.exists(../src/protoc): protoc = ../src/protoc elif os.path.exists(../src/protoc.exe): protoc = ../src/protoc.exe Is such an approach acceptable? How would I go about getting this patch committed? Thanks! -- 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. -- 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: [protobuf] python/setup.py
OK, it turns out we will use whatever protoc in the PATH as a fail over. This change is probably fine then. Sent you a code review. Also add a warning message if the protoc is set via env variable. On Thu, Mar 24, 2011 at 5:48 PM, Pherl Liu liuj...@google.com wrote: I'm a bit concerned about setting arbitrary proto compiler via environment variables. Protobuf runtime library requires exactly matching protoc generated classes to work. Separating the protoc and library potentially increased the risk of having incompatibility errors. Not sure if this would bring security issues though. Maybe you can write a wrapper script to symbol link the correct protoc in your environment. On Wed, Mar 23, 2011 at 8:36 AM, cmas...@chromium.org cmas...@chromium.org wrote: Hello! I'm a developer on Chromium OS, and we recently (today) started needing to build the protocol buffers with python support enabled in our cross-compilation environment. Passing --with-protoc to ./configure got me partway there, but then when it tried to run python setup.py build, it got intro trouble. Turns out there's logic in setup.py to go looking for the protoc that was just compiled. In a cross-compile situation, that won't work :-/ I've got a patch to allow the desired protoc to be overridden by an environment variable: diff -Naur protobuf-2.3.0-orig/python/setup.py protobuf-2.3.0/python/setup.py --- protobuf-2.3.0-orig/python/setup.py 2011-03-22 16:33:33.0 -0700 +++ protobuf-2.3.0/python/setup.py 2011-03-22 17:01:14.0 -0700 @@ -16,7 +16,9 @@ maintainer_email = protobuf@googlegroups.com # Find the Protocol Compiler. -if os.path.exists(../src/protoc): +if 'PROTOC' in os.environ and os.path.exists(os.environ['PROTOC']): + protoc = os.environ['PROTOC'] +elif os.path.exists(../src/protoc): protoc = ../src/protoc elif os.path.exists(../src/protoc.exe): protoc = ../src/protoc.exe Is such an approach acceptable? How would I go about getting this patch committed? Thanks! -- 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. -- 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.
[protobuf] Re: Issue 272 in protobuf: protobuf-2.3.0 and greater don't cross-compile
Updates: Status: Accepted Owner: liuj...@google.com Comment #1 on issue 272 by liuj...@google.com: protobuf-2.3.0 and greater don't cross-compile http://code.google.com/p/protobuf/issues/detail?id=272 (No comment was entered for this change.) -- 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.
[protobuf] Re: Issue 271 in protobuf: RPATH on python native library is not set correctly
Comment #2 on issue 271 by ask...@gmail.com: RPATH on python native library is not set correctly http://code.google.com/p/protobuf/issues/detail?id=271 Even better would to be to not set RPATH at all unless explicitly requested. Certainly, there should be an option to disable it. -- 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: [protobuf] Re: How to Programmatically determine the Builder method names (getter and setter) for a given field name
You can find the algorithm in source code.
http://code.google.com/p/protobuf/source/browse/trunk/src/google/protobuf/compiler/java/java_helpers.cc
On Wed, Mar 16, 2011 at 2:42 PM, Ravi ravikumarkulan...@gmail.com wrote:
Hi Thanks a lot for your time.
Yes the approach looks very clean as the api getField and setField are
in built. I think we would go with this approach.
But i am just curious to know whether protobuf published anywhere the
algorithm for deriving getter and setter method names.
Thanks,
Ravikumar K
On Mar 15, 3:09 pm, Dmitriy Ryaboy dvrya...@gmail.com wrote:
We needed to do something similar for our project Elephant-Bird that
provides support for working with Protocol Buffers in Hadoop.
Protobufs have Descriptors that allow you to determine all of these things
on the fly, without encoding method naming rules and such.
Here is the relevant snippet
fromhttps://github.com/kevinweil/elephant-bird/blob/master/src/java/com/t...
public static Message addField(Message m, String name, Object value) {
Message.Builder builder = m.toBuilder();
setFieldByName(builder, name, value);
return builder.build();
}
public static void setFieldByName(Message.Builder builder, String
name, Object value) {
FieldDescriptor fieldDescriptor =
builder.getDescriptorForType().findFieldByName(name);
if (value == null) {
builder.clearField(fieldDescriptor);
} else {
builder.setField(fieldDescriptor, value);
}
}
*
*
On Tue, Mar 15, 2011 at 2:19 AM, Ravi ravikumarkulan...@gmail.com wrote:
Hi,
We would like to know how to determine the getter and setter method
names generated in java builder class for a particular field defined
in proto message.
Of course, the simple rule says that
* Convert first letter of the field name to upper case
* prefix get or set to the field name
But we want to know all the cases considered while generating builder
class.
Like what are the special characters considered? what are the
exceptional cases?
Why we want this is,
In our framework we would be programmatically generating proto files
from the xsds which we have already.
Along with this we would be generating an adapter class between our
framework and the java class generated by protoc compiler.
This adapter would call getter and setter methods of the builder class
available in the builder class to retrieve the value and to build the
object.
Any help would be appreciated.
Thanks,
Ravikumar K
--
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.
--
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.
--
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: [protobuf] Android Cross Compile
Looks like pthread library is missing. This should have been covered by the acx_pthread.m4 script. Could you please try to manually run the linker(the g++ line you pasted in email), by adding extra -pthread and/or -lpthread parameters? On Thu, Mar 10, 2011 at 3:42 AM, Evol mverre...@gmail.com wrote: Hello, I am attempting to cross-compile the libprotobuf library so I can use it on native android c/c++ code. Due to the ues of bionic as the android libc, I am getting the following error when I do a make. libtool: link: g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno- sign-compare -O2 -g -DNDEBUG -o .libs/protoc main.o ./.libs/ libprotobuf.so ./.libs/libprotoc.so -lz -Wl,-rpath -Wl,/usr/local/ android/lib ./.libs/libprotobuf.so: undefined reference to `pthread_once' I am using the standalone compiler that comes with the NDK. Thanks in advance for any help. -- 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. -- 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: [protobuf] Android Cross Compile
Please also take a look at the config.log file, generated after running ./configure, in the project root directory; search for checking for pthreads library checking whether pthreads work without any flags There should be a line, after debug info, saying result: no or result: yes From your error message, it seems android NDK doesn't require any flags to link pthread... On Thu, Mar 24, 2011 at 8:31 PM, Pherl Liu liuj...@google.com wrote: Looks like pthread library is missing. This should have been covered by the acx_pthread.m4 script. Could you please try to manually run the linker(the g++ line you pasted in email), by adding extra -pthread and/or -lpthread parameters? On Thu, Mar 10, 2011 at 3:42 AM, Evol mverre...@gmail.com wrote: Hello, I am attempting to cross-compile the libprotobuf library so I can use it on native android c/c++ code. Due to the ues of bionic as the android libc, I am getting the following error when I do a make. libtool: link: g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno- sign-compare -O2 -g -DNDEBUG -o .libs/protoc main.o ./.libs/ libprotobuf.so ./.libs/libprotoc.so -lz -Wl,-rpath -Wl,/usr/local/ android/lib ./.libs/libprotobuf.so: undefined reference to `pthread_once' I am using the standalone compiler that comes with the NDK. Thanks in advance for any help. -- 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. -- 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.
[protobuf] Re: Issue 248 in protobuf: protobuf will not compile without thread library
Comment #11 on issue 248 by liuj...@google.com: protobuf will not compile without thread library http://code.google.com/p/protobuf/issues/detail?id=248 We do have a draft here see http://codereview.appspot.com/3540041/ From the review comments, the blocking issue is google/protobuf/stubs/once.h needs to include config.h, which is not acceptable. You can actually patch the diff to have a hardcoded no thread-safety protobuf. -- 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: [protobuf] Linker Errors and stdcall vs cdecl calling conventions (VC++ 2008)
We never actually chose to use cdecl; it was simply the default used by MSVC. This whole idea that the programmer should have to choose between calling conventions is a bit strange and inconvenient. The LIBPROTOBUF_EXPORT annotations are annoying enough; I hope we don't have to litter our code with calling convention annotations as well. Is there any way we can modify the existing LIBPROTOBUF_EXPORT macro to specify calling conventions too? Your work-around of compiling the DLL with different settings should work fine. I can't imagine any reason why stdcall would cause problems. Out of curiosity, what is the binary size difference between the cdecl version and the stdcall version? The MSDN docs claim stdcall produces smaller binaries. On Tue, Mar 15, 2011 at 5:05 AM, Kostya Y kosty...@gmail.com wrote: Hello It seems like the calling convention used in libprotobuf's vc project is cdecl while the Microsoft's preferred way (or the default one) is stdcall. Is there a reason why cdecl was chosen? I am getting linker errors as the functions are not strictly defined as cdelc so the linker assumes that it should use default project settings which in my case is stdcall. As a result I get the following errors: error LNK2001: unresolved external symbol void __stdcall google::protobuf::internal::VerifyVersion(int,int,char const *) (? VerifyVersion@internal@protobuf@google@@YGXHHPBD@Z) As you can see it expects it to be __stdcall (projects settings are set to default naming convention stdcall) while it is exported as cdecl. Any suggestions how to work around it? Thanks - Kostya -- 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. -- 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.
