nanopb options ; compiling the same proto file with protoc-c and protoc

[Michael Haberler]

Hi Petteri,

I would like to have a common set of proto definitions, which compile to several bindings (nanopb, protoc-c, protoc - C++, and protoc-Python)

is that possible? are there any tricks I can pull so the nanopb options are ignored by the other protoc/protoc-c runs?

thanks in advance,

- Michael

-- example:

import "scalar.proto";
import "nanopb.proto";

....
message RTAPI_Message {
....
repeated ScalarValue arg = 30 [(nanopb).max_count = 10];
}

[petteri...@gmail.com]

Hi,

> is that possible? are there any tricks I can pull so the nanopb
> options are ignored by the other protoc/protoc-c runs?

There are no tricks to make them ignored, but they are valid .proto
syntax so "good parsers" such as google's own protoc should be just fine
with them. Not sure about protoc-c, but I think it should handle it
also. However you will also need to compile nanopb.proto in order not to
have broken #includes.

Adding a separate configuration file with just the nanopb options has
been on the issues list for some time. So far there is just the
generator option -s to set settings for a whole file.

--
Petteri

[Michael Haberler]

I think I have it sorted now, there were some peculiarities:

the protoc-c compiler at least as per current ubuntu precise version does not include descriptor.h ; protoc does
so that needs to be built too in this case, besides nanopb.proto derived files

here is the full Makefile strangeness for building .proto files containing nanopb options into a nanopb library, a protoc-c C library, a protoc C++ library, and working protoc Python bindings:

http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/protobuf/Submakefile;h=10bdd69b084170fc6cde86e6cb71bc4918a17ee7;hb=6b27278a1e7731801d388338bb90457cb74bf64c

the fixed-size and max-repeat-count type options are super useful to avoid dynamic memory allocation and related problems in touchy environments, like a kernel module!


thanks!

- Michael

> --
> You received this message because you are subscribed to the Google Groups "nanopb" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to nanopb+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

[petteri...@gmail.com]

Hi,

> the fixed-size and max-repeat-count type options are super useful to
> avoid dynamic memory allocation and related problems in touchy
> environments, like a kernel module!

If you want to try it out, I now added preliminary support for separate
options file.

Basically to define options for messages in MyProto.proto, you will
create a text file called MyProto.options. This way there is no need to
add anything nanopb-specific into the .proto file.

The .options file should contain lines like this:

* max_size:16 max_count:5
FunnyMessage.* max_size:32
FunnyMessage.funnyfield field_type:FT_CALLBACK

There is a trivial example with the alltypes.proto, but no documentation
yet. With the generator option -v you can see how the wildcards work out
into per-field options.

--
Petteri

[Michael Haberler]

Hi Petteri,

Am 09.03.2013 um 13:31 schrieb petteri...@gmail.com:

> Hi,
>
>> the fixed-size and max-repeat-count type options are super useful to
>> avoid dynamic memory allocation and related problems in touchy
>> environments, like a kernel module!
>
> If you want to try it out, I now added preliminary support for separate
> options file.
>
> Basically to define options for messages in MyProto.proto, you will
> create a text file called MyProto.options. This way there is no need to
> add anything nanopb-specific into the .proto file.

well yes and no; I still see nanopb.proto included and that carries over into the C/C++/Python builds a bit even if nanopb_generator.py suppresses the inclusion of nanopb.proto and descriptor.proto related includes

In case this isnt just an omission - if you really want to keep the proto files free of nanopb specifics I guess the nanopb.proto file should be included by nanopb_generator.py without explicit mentioning in the proto file

but the impact of nanopb.proto on the non-nanopb builds is harmless if only suprising for the casual user

- Michael

>
> The .options file should contain lines like this:
>
> * max_size:16 max_count:5
> FunnyMessage.* max_size:32
> FunnyMessage.funnyfield field_type:FT_CALLBACK
>
> There is a trivial example with the alltypes.proto, but no documentation
> yet. With the generator option -v you can see how the wildcards work out
> into per-field options.
>
> --
> Petteri
>

[petteri...@gmail.com]

Hi,

> well yes and no; I still see nanopb.proto included and that carries
> over into the C/C++/Python builds a bit even if nanopb_generator.py
> suppresses the inclusion of nanopb.proto and descriptor.proto related
> includes

The nanopb.proto include is no longer necessary. I just forgot to remove
it at first, but did so later:
https://code.google.com/p/nanopb/source/detail?r=9b6641ac643af4f301e05421f2b228084dcc8693

> but the impact of nanopb.proto on the non-nanopb builds is harmless if
> only suprising for the casual user

Usually yeah. Some more exotic parsers totally break down if they see an
import or field options used. Otherwise it is just a nuisance.

--
Petteri

[Michael Haberler]

Perfect. It also enables setting project-wide options, say driven from autoconf and edited into the options file, on such parameters without fiddling the .proto files proper.

I'll switch to that scheme and let you know how it pans out.


Michael