Hi Adams,
Nice to see there is an issue I could follow. FYI I'm going with (1).
To add a data point, we're interested in the lite runtime not for mobile
but to avoid exacerbating long link times when adding protobuf to an
(already) large project.
Thanks,
Mohamed Koubaa
Software Developer
ANSYS Inc
On Tue, Dec 6, 2016 at 11:53 AM, Adam Cozzette wrote:
> Hi Mohamed, sorry for the delay getting back to you. I had forgotten about
> this but there is a known issue that protobuf lite does not contain the
> well-known protos: https://github.com/google/protobuf/issues/1889 Even if
> you tweak the build to include them, there is still the issue that the
> generated code from them will rely on symbols which are not present in the
> lite runtime.
>
> I think there are two possible workarounds for now:
> 1) You could just link against the full runtime but continue using
> optimize_for = LITE in your .proto files. This way you would still have the
> code size benefit of having generated descriptors omitted from your binary,
> but you would have extra library code, so you would have to look at the
> size of your binary and see if this makes sense in your case.
> 2) You could essentially copy any.proto to another directory in your
> project and give it a different package name. Then you could use this
> private version of Any and it would be wire-compatible with
> google.protobuf.Any.
>
> On Thu, Dec 1, 2016 at 10:48 AM, Mohamed Koubaa
> wrote:
>
>> Hello,
>>
>> This works as long as my test project links against the full protobuf
>> runtime. Attempting to link against the lite runtime produces the
>> following unresolved symbols:
>>
>> error LNK2001: unresolved external symbol "public: __cdecl
>> google::protobuf::Any::Any(void)" (??0Any@protobuf@google@@QEAA@XZ)
>>
>> error LNK2001: unresolved external symbol "void __cdecl
>> google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fany_2eproto(void)"
>> (?protobuf_AddDesc_google_2fprotobuf_2fany_2eproto@protobuf@google@
>> @YAXXZ)
>>
>> error LNK2001: unresolved external symbol "public: virtual bool __cdecl
>> google::protobuf::Any::MergePartialFromCodedStream(class
>> google::protobuf::io::CodedInputStream *)" (?MergePartialFromCodedStream@
>> Any@protobuf@google@@UEAA_NPEAVCodedInputStream@io@23@@Z)
>>
>> error LNK2001: unresolved external symbol "public: virtual int __cdecl
>> google::protobuf::Any::ByteSize(void)const " (?ByteSize@Any
>> @protobuf@google@@UEBAHXZ)
>>
>> error LNK2001: unresolved external symbol "public: void __cdecl
>> google::protobuf::Any::MergeFrom(class google::protobuf::Any const &)"
>> (?MergeFrom@Any@protobuf@google@@QEAAXAEBV123@@Z)
>>
>> error LNK2001: unresolved external symbol "public: static class
>> google::protobuf::Any const & __cdecl
>> google::protobuf::Any::default_instance(void)"
>> (?default_instance@Any@protobuf@google@@SAAEBV123@XZ)
>>
>>
>> Thanks,
>> Mohamed Koubaa
>> Software Developer
>> ANSYS Inc
>>
>> On Thu, Dec 1, 2016 at 1:36 PM, Mohamed Koubaa
>> wrote:
>>
>>> Hello,
>>>
>>> FWIW, this is the boilerplate I use for my proto3.0.0 project. It
>>> depends on GetTypeName() whose future is uncertain in the lite runtime. It
>>> appears to work in one of my tests but I am not sure if I am missing
>>> something subtle. I'm using SerializeWithCachedSizesToArray because I
>>> learned that it is faster for large messages because it does not compute
>>> the size twice.
>>>
>>> static void PackInto(google::protobuf::Any* target, const
>>> google::protobuf::MessageLite& msg)
>>> {
>>> int msg_size = msg.ByteSize();
>>> char* msg_buffer = new char[msg_size];
>>>
>>>
>>> msg.SerializeWithCachedSizesToArray((google::protobuf::uint8*)msg_buffer);
>>> //avoids double
>>> target->set_type_url(msg.GetTypeName());
>>> target->set_value(msg_buffer,msg_size);
>>>
>>> delete[] msg_buffer;
>>> }
>>>
>>> static void UnpackFrom(const google::protobuf::Any& source,
>>> google::protobuf::MessageLite* msg)
>>> {
>>> EXPECT_EQ(source.type_url(), msg->GetTypeName()); //Could be
>>> converted to an assert or CHECK style macro in a non-test project
>>> msg->ParseFromArray(source.value().c_str(), source.value().size());
>>> }
>>>
>>> Thanks,
>>> Mohamed Koubaa
>>> Software Developer
>>> ANSYS Inc
>>>
>>> On Tue, Nov 29, 2016 at 8:22 PM, Adam Cozzette
>>> wrote:
>>>
Right now there doesn't seem to be a consensus around adding built-in
support for Any in the lite runtime, so I suspect that the status quo will
probably remain for now. If you would like to use Any with the lite
runtime, I think it's probably best to just manually serialize and parse to
and from your Any fields, since that will work even if it involves a little
extra boilerplate.
On Tue, Nov 29, 2016 at 11:20 AM, Mohamed Koubaa <
mohamed.kou...@ansys.com> wrote:
> Hello,
>
> I am sorry to bring back an old thread, but the outcome is not clear.
> Is there either an intent or any ong
