There are some recent reports of strange build failures that might have
been fixed by compiling in C++17 mode, so it might be a good idea to use
C++17 in general, and not just when building against very recent
protobuf versions.
Since it looks like we've lost protobuf < 3.0.0 support, configure.ac
can be simplified a bit if we just use C++17 by default.
It's unclear from looking at the online protobuf documentation whether
C++14 or C++17 is now required when building against newer versions of
protobuf (or perhaps I'm looking in the wrong place), but experimentally
it did not work for me with C++14.
This commit rewrites the versioned PKG_CHECK_MODULES checks in
configure.ac to enforce the following policies:
* Require protobuf >= 2.6.0.
* On protobuf >= 3.0.0, require C++11.
* On protobuf >= 4.22.0, require C++17.
This commit enables use of the AX_CXX_COMPILE_STDCXX macro from the
autoconf-archive (added in the previous commit), which automatically
adds needed flags to the CXX variable to enable C++11 support. This only
works and is only required on compilers that are both new enough to have
C++11 support and old enough to not enable it by default.
We call it with "noext" as the second argument (so that we get the "std"
C++11 variant on GCC) and "mandatory" as the third argument, since we
now rely on C++11 features as of 83c59e705f461cc08e5844d62514dff27c33a74f.
Note that this macro is only called when we are building the compiler
(i.e., without --disable-protoc) so that the library can still be built
on ancient C compilers.
This is a first cut at adding proto3 support.
As far as I understand protobuf-c already has pretty much everything
needed once it is built using a new version of protobuf itself.
The only missing thing is that in proto3 all fields are optional and
having to manually set has_foo is inconvenient.
This patch special cases the proto3 syntax files so that structs for the
bytes, enum and primitive fields do not emit the has_ field.
It also adds PROTOBUF_C_LABEL_NONE to the label enum that is used for
proto3 fields. When a fields has this label, the quantifier is not
consulted and instead the field is packed/unpacked depending on
whether it has a value different from NULL/0.
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.
protoc may not be on the default PATH, so augment $PATH with the
executable path registered by pkg-config for the protobuf package.
additionally declare PROTOC as a precious variable, thus allowing it to
be explicitly set by the user at ./configure time.
based on a patch from Andrei Nigmatulin.
the protobuf header files may be installed in a non-standard location
and thus we need to use the CFLAGS registered for protobuf in pkg-config
in order to find them.
based on a patch from Andrei Nigmatulin.
if pkg-config is installed, the libprotobuf-c .pc file will be
installed; if pkg-config is not installed, the .pc file won't be
installed.
this behavior only applies when we're building with ./configure
--disable-protoc, since pkg-config is required in order to detect the
protobuf dependency.
this is conditional on whether the linker supports version scripts, for
which we use the gl_LD_VERSION_SCRIPT macro from the gnulib project.
on platforms without version scripts, we fall back to libtool's
-export-symbols-regex.
it's possible for the <google/protobuf/compiler/> header files to be
shipped in a separate package (e.g., debian's libprotoc-dev). check for
this at configure time rather than allowing the build process to fail.
Still need to add the comments in the source code. Currently I've
seeded it with the libprotobuf-c files. I've configured it
to make man pages and html pages. Might not be ideal, but makes it easy
for me to check things (html is nicer, but man pages are handier for
remote servers).
Makefile.am: add valgrind to the AM_TESTS_ENVIRONMENT
configure.ac: enable valgrind testing option for ./configure
m4/valgrind-tests.m4: enable tracing children for libtool wrapper
script compatibility, but ignore standard binaries in /usr or /bin
some of these headers aren't used in the protobuf-c code base any more,
and in any case the results of these checks (the HAVE_*_H defines in
config.h) are not actually used anywhere and the absence of any of these
headers doesn't cause configure to fail, so just delete these useless
checks.
for some reason, "make distcheck" fails when the build is configured
with --disable-protoc. i haven't been able to track down the root cause
(it appears the build is trying to generate the generated pb-c files for
the test cases, but the test cases should be disabled when
--disable-protoc is specified). so, remove the --disable-protoc option.
libprotobuf-c should always be tested as part of a build, and this can't
be done unless protoc-c is built. this also reduces the number of build
combinations that need to be tested.
this option is only supported by the upstream protobuf compiler starting
with version 2.5.0. this version is not yet widely available in the
debian/ubuntu repositories, and we would like to avoid breaking the
build on those platforms with the distribution version of protobuf
installed, so revert the following commits:
- 5ee9c03478ea13bba03e7d7edacf723f324200c2
- 84e41e7329f1f0fc09b41ee96e17b28a792cefcf
