This handles special charaters like in "my-file.proto" properly.
Also use headerbasename instead of full path, so that compiling files
with relative path doesn't create symbols like FOO/BAR/BAZ_MESSAGES.

Update issue 149
Status: FixedInGit

Update issue 147
Status: FixedInGit

Previously this got included by bbfreeze, but apparently no more.

Update issue 146
Status: FixedInGit

Do not assume that Python has already been found by CMake. Fix value of
CMake variable PYTHON_EXECUTABLE if Python 3 was found. Change minimum
supported Python version to 2.6.

This fixes a bug introduced by this commit:
d8d3b75e

1) Search explicitly for python2.7

In systems where python3 is default or in build cases where the user has
already searched for and found python3 in CMake, store the python3
executable and search for python2.7.

2) Generate nanopb core protobuf files with CMake

Generate python output files used in turn by the nanopb generator
script. This removes the requirement of manually calling 'make' in the
nanopb/generator/proto directory.

3) Use nanopb options file if it exists

Look for nanopb options file and use in protobuf source and header
generation if it exists. The options file must have the same name and
path as the proto file, excluding the extension.

Added test case for the same.

Update issue 142
Status: FixedInGit

The sizes are represented as EncodedSize() instances, which cause
max() operation to sort them by address instead of value. This caused
pretty much random item to be selected for the maximum.

Update issue 141
Status: FixedInGit

Update issue 131
Status: FixedInGit

Fixes crashes / memory leaks when using pointer type fields.
Also fixes initialization of which_oneof fields.

The behaviour with no_unions:true is the same as of nanopb 0.3.1 and earlier.

Basic test included, should probably add an oneof to the AllTypes test also.

Update issue 131
Status: Started

Because Issue #139 now allows limiting integer fields, it is good
to check the values received from other protobuf libraries against
the lower limits.

This allows overriding the integer field types to e.g. uint8_t for
saving RAM.

Update issue 139
Status: FixedInGit

Update issue 140
Status: FixedInGit

There was a memory leak when:

1) A statically allocated submessage or
2) an extension field submessage

contained

A) a pointer-type field or
B) a submessage that further contained a pointer-type field.

This was because pb_release() didn't recurse into non-pointer fields.

Update issue 138
Status: FixedInGit

This makes the behaviour more consistent with non-extension fields,
and also makes sure that all 'found' fields of extensions are initially
false.

The memset() filled also the extensions field, which was just
waiting for a crash to happen.