Adds support for the LITE_RUNTIME optimization option to the protobuf-c
compiler. Enabling this option would generate lighter weight message,
enum, and service descriptors that contain NO strings. As a result,
calls to lookup descriptors via the *_get_{field,value,method}_by_name
API will return NULL.
Default compiler behavior (when optimize_for is not specified or is not
set to LITE_RUNTIME) is unchanged.
Certain protobuf comments could generate invalid C comments
and inadvertently close the comment block. This commit removes '/'
signs in such comments.
One example of a .proto file containing such comments is a commonly
included descriptor.proto from the protobuf library.
warning: assigning to 'uint8_t *' (aka 'unsigned char *')
from 'char *' converts between pointers to integer types
with different sign [-Wpointer-sign]
Add a field flag and functions to pack/unpack oneofs
Add logic to parse multiple fields for the same oneof
Add logic for merging submessages that contain oneofs
For certain platforms where autotools is not the preferred build system,
provide a fallback cmake file that can compile protoc-c and a static
library of libprotobuf-c.
Based on the file from alex85k's protobuf-c repository.
(Issue #168.)
The object file name is not what is expected when building with
automake's "subdir-objects" option. Rather than expecting automake to
generate a specific filename, we simply make the generated header a
dependency of all objects for cxx-generate-packed-data.
(Issue #156, #169.)
Per http://msdn.microsoft.com/en-us/library/z8y1yy88(v=vs.71).aspx,
Microsoft compilers do not support the Standard C keyword 'inline',
instead preferring the implementation-specific '__inline', so add a
workaround for these specific compilers.
Based on a patch from alex85k (#167).
Per the protobuf developers,
We will from everything away from Google Code eventually. We haven't
decided where to put future release packages yet but as it seems github
supports this well chances are we'll use github as the canonical location
for all downloads.
gcc silently treats arithmetic on a void pointer as char pointer
arithmetic without -pedantic. Other compilers do not. Make it explicit
that we are doing arithmetic on a pointer with object size 1.
This eliminates the following diagnostic:
protobuf-c/protobuf-c.c: In function 'parse_packed_repeated_member':
protobuf-c/protobuf-c.c:2404:34: warning: pointer of type 'void *' used in arithmetic [-Wpedantic]
void *array = *(void **) member + siz * (*p_n);
(I did not find any other instances of 'void *' arithmetic when
compiling with -pedantic.)
Based on a patch from alex85k (#167).
If we are not building on gcc, PROTOBUF_C__DEPRECATED needs to be
defined but empty. Previously we were not defining it at all in certain
situations, which would cause build failures.
Based on a patch from alex85k (#167).
protobuf 2.5.0 started warning that we would need to enable the
'allow_alias' option on this enum due to the duplicate enum values, and
protobuf 2.6.0 turned this into an error. Turn this option on, now that
protobuf 2.5.0 is more common (e.g., it's now in Ubuntu 14.04 LTS). This
will break with older protobuf versions, so we now require >= 2.5.0.
We should now see diagnostics like these disappear from the build log:
[libprotobuf ERROR google/protobuf/descriptor.cc:4153] "foo.VALUE_B" uses the same enum value as "foo.VALUE_A". If this is intended, set 'option allow_alias = true;' to the enum definition.
Based on a patch from Ilya Lipnitskiy.
In order to add compatibility with the latest protobuf 2.6.0 release, we
need to add an option to the t/test-full.proto schema that was
introduced in protobuf 2.5.0, so we need to depend on protobuf 2.5.0 or
higher now.
This should fix the following build failure.
./protoc-c/protoc-c: error while loading shared libraries: libprotobuf.so.8: cannot open shared object file: No such file or directory
make: *** [t/test.pb-c.c] Error 127
