Thanks for the quick response! This stems from my own misunderstanding then. We had diagnosed a new failure to the diff between those two outputs, but the error must be elsewhere. Sorry for the noise!
On Tue, Jan 24, 2017 at 12:03 PM, David Renshaw <[email protected]> wrote: > Hi, > > The generated code contains the full schema information from the code > generator request, including the displayName > <https://github.com/sandstorm-io/capnproto/blob/v0.5.3/c%2B%2B/src/capnp/schema.capnp#L33> > field, > which will differ depending on the value --src-prefix. > > There should be no observable effects of having different values for > `displayName`, except possibly in error messages. > > You can examine the schema information yourself by doing this: > > capnp compile -o - test/common.capnp | capnp decode > /usr/local/include/capnp/schema.capnp CodeGeneratorRequest > > > - David > > > On Tue, Jan 24, 2017 at 2:46 PM, <[email protected]> wrote: > >> Hi folks, >> >> I just hit an unexpected effect of --src-prefix when using capnp compile >> (capnp version 0.5.3): it appears that using --src-prefix can cause structs >> to end up different sizes in generated code. I've attached a simple test >> case; with --src-prefix, the struct ends up being one byte shorter than >> without using --src-prefix: >> >> $ capnp --version >> Cap'n Proto version 0.5.3 >> >> $ cat test/common.capnp >> >> @0xc2be90a8da0c2971; >> >> >> using Cxx = import "/capnp/c++.capnp"; >> $Cxx.namespace("common"); >> >> >> struct S >> { >> x @0 : UInt64; >> } >> >> $ capnp compile -oc++:res-no-prefix test/common.capnp >> >> $ capnp compile --src-prefix=test -oc++:res-prefix test/common.capnp >> >> $ diff res-prefix/common.capnp.c++ res-no-prefix/test/common.capnp.c++ >> 8c8 >> < static const ::capnp::_::AlignedData<31> b_afcc81ad15d9043d = { >> --- >> > static const ::capnp::_::AlignedData<32> b_afcc81ad15d9043d = { >> 11c11 >> < 13, 0, 0, 0, 1, 0, 1, 0, >> --- >> > 18, 0, 0, 0, 1, 0, 1, 0, >> 15,16c15,16 >> < 21, 0, 0, 0, 122, 0, 0, 0, >> < 25, 0, 0, 0, 7, 0, 0, 0, >> --- >> > 21, 0, 0, 0, 162, 0, 0, 0, >> > 29, 0, 0, 0, 7, 0, 0, 0, >> 18c18 >> < 21, 0, 0, 0, 63, 0, 0, 0, >> --- >> > 25, 0, 0, 0, 63, 0, 0, 0, >> 21,22c21,23 >> < 99, 111, 109, 109, 111, 110, 46, 99, >> < 97, 112, 110, 112, 58, 83, 0, 0, >> --- >> > 116, 101, 115, 116, 47, 99, 111, 109, >> > 109, 111, 110, 46, 99, 97, 112, 110, >> > 112, 58, 83, 0, 0, 0, 0, 0, >> 46c47 >> < 0xafcc81ad15d9043d, b_afcc81ad15d9043d.words, 31, nullptr, >> m_afcc81ad15d9043d, >> --- >> > 0xafcc81ad15d9043d, b_afcc81ad15d9043d.words, 32, nullptr, >> m_afcc81ad15d9043d >> >> This difference is unexpected, given that the documentation for the >> src-prefix flag implies that the only thing that should be effected by it >> is the location of the generated file. That said, I'm not sure if it's a >> documentation bug or a compiler bug, so I didn't dig further into the >> compiler to figure out where the difference is being introduced. Am I >> misunderstanding src-prefix, or is this a bug? >> >> Thanks so much! >> Haldean >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Cap'n Proto" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> Visit this group at https://groups.google.com/group/capnproto. >> > > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
