Now that we require protobuf >= 3.0.0, we are always building with
proto3 syntax support.
Note that the test-generated-code3 test keeps `-DPROTO3` which is
separate from the HAVE_PROTO3 identifier. This test is building built
from the same source file as test-generated-code but the source file
supports proto2 and proto3 syntax depending on how it's compiled.
Signed-off-by: Daniel Egger <daniel@eggers-club.de>
[edmonds: From https://github.com/protobuf-c/protobuf-c/pull/523.]
[edmonds: Adjust find string from "0 |" to "0 | ", test against `== 0`
rather than `!= std::string::npos` so that the find/erase calls are
anchored to the same portion of the string.]
This commit updates a few tests where we aren't using the correct C
signature for main() or are not using any of its parameters (in the
case of t/version/version.c.)
This commit fixes the following compiler diagnostics:
../protoc-c/c_helpers.cc: In function ‘void google::protobuf::compiler::c::PrintComment(google::protobuf::io::Printer*, std::__cxx11::string)’:
../protoc-c/c_helpers.cc:221:25: warning: comparison of integer expressions of different signedness: ‘int’ and ‘std::vector<std::__cxx11::basic_string<char> >::size_type’ {aka ‘long unsigned int’} [-Wsign-compare]
for (int i = 0; i < comment_lines.size(); i++)
~~^~~~~~~~~~~~~~~~~~~~~~
../protoc-c/c_helpers.cc: In function ‘std::set<std::__cxx11::basic_string<char> > google::protobuf::compiler::c::MakeKeywordsMap()’:
../protoc-c/c_helpers.cc:273:21: warning: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]
for (int i = 0; i < GOOGLE_ARRAYSIZE(kKeywordList); i++) {
^
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.
Use the newer "legacy" way of determining whether a file descriptor is
using proto2 or proto3 syntax on protobuf >= 23.0.
Based on
66574f3fd8
but continues to support older versions of protobuf.
Unfortunately, since this is a "deprecated", "legacy" API it'll probably
disappear in about five seconds.
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.
According to the protobuf migration guide as of June 2023 [0], protobuf
22.0 (aka 4.22.0) took a dependency on something called "abseil" and as
a result the "stubs" have been removed. This apparently caused all the
uses of GOOGLE_* identifiers in protoc-c to fail when building against
newer versions of protobuf.
This commit introduces compatibility definitions when building against
protobuf >= 4.22.0 so that protobuf-c can build against older and newer
versions of protobuf.
[0] https://web.archive.org/web/20230611151200/https://protobuf.dev/support/migration/#abseil
Looking at where these identifiers are ultimately defined [0], it looks
like "DFATAL" means either "ERROR" or "FATAL" depending on whether
NDEBUG is defined. However, looking at the actual code sites in protoc-c
where DFATAL is used, it's not clear why we couldn't just use FATAL
unconditionally.
This is aimed at supporting newer versions of protobuf where the DFATAL
identifier apparently no longer exists.
[0] https://github.com/protocolbuffers/protobuf/blob/v21.12/src/google/protobuf/stubs/logging.h#L61-L65
protobuf has removed the definition of this macro as of commit
1595417dd3859bbff7d3d61ad0b6e39044d47489, so the invocation of this
macro in protobuf-c breaks the build when building agaist the protobuf
22.x or 23.x series.
Simply removing the macro invocations seems to be safe and doesn't break
the build on Debian's protobuf 3.21.12 nor Debian's protobuf 3.6.1.3.
protoc depends on protobuf libraries for execution. Order libraries
accordingly. Observing link errors with yocto's meta-mingw project
during static linkage.
Signed-off-by: Sinan Kaya <sinan.kaya@microsoft.com>
The steps to add this functionality are from the cmake tutorial:
https://cmake.org/cmake/help/latest/guide/tutorial/index.html
The include directories being set on the targets is necessary
for dependent targets. There is some redundancy with the
INCLUDE_DIRECTORIES calls alreday present, but I left it alone
to make the PR smaller and more approachable.
The project currently uses mixed cases in functions. This uses
lowercase on calls I touched, as this is what CMake documentation
uses and seems to be the preferred way.
I also started wrapping long lines, as some of the lines I touched
were over 170 characters.
I tested this on both Mac OS 10.15 Catalina and CentOS 7 (with
devtoolset-7) with CMake 3.10.3.
Will work on tests in CI next.
