* Drop Python versions <3.7.
* Updated README to clarify that Python 3.7 is the minimum.
* Removed more Python 3.5-specific code.
Also changed tests to skip missing interpreters.
* Invoke tox directly instead of through Python.
Hopefully this will pick up python3.
* Updated java_stretch image to bullseye to get Python >= 3.7.
* Use jdk11 instead of jdk8.
* Installed python2 for gtest.
* Use "python3 -m venv" instead of "virtualenv."
* Install python3-venv.
If `-Dprotobuf_USE_EXTERNAL_GTEST=ON` is passed to CMake, it will use an external Google Test copy (i.e. by calling `find_package(GTest REQUIRED)`) rather than the one provided as a submodule.
This makes sense for larger projects that might already include Google Test and want to use a more standard CMake approach.
Also updated build instructions with this information, and more idiomatic usage.
Co-authored-by: Adam Cozzette <acozzette@google.com>
Convenience feature: enable users to test via the familiar `ctest` command rather than making the `check` target.
They would be able to use the familiar CMake pattern:
```
cmake -S source/protobuf -B build/protobuf ...
cmake --build build/protobuf
ctest --test-dir build/protobuf
cmake --install build/protobuf
```
This is a follow-up to 9f447fc9d3da93da29b8301f1a8ca57b1ea812d7
* Remove javanano from .gitignore.
Ignore java/lite/target
* Resolve more java field accessor name conflicts.
Previously, some proto field names would cause the java code generator to generate accessor names that conflict with method names from the message super classes/interfaces.
A list of field names that cause such conflicts previously existed, but the list did not contain every field name that would cause a conflict.
Additionally, only snake_case field names would be detected. If the field name was in camelCase, the conflict would not be detected.
This change adds the complete set of field names that will cause assessor name conflicts, and detects conflicts in both snake_case and camelCase field names.
Fixes#8142
* Prevent java accessor name conflicts for fields with leading underscores.
Previously, some protobuf field names beginning with leading underscores (e.g. _class) would cause uncompilable java code to be generated due to assessor name conflicts.
Now, non-conflicting java accessor method names are created for those fields
* Improve comments/documentation for conversion from snake case to camel case
Rename snakeCaseToCamelCase to snakeCaseToLowerCamelCase
Add snakeCaseToUpperCamelCase
Add clarifying in-line comments for field name generation
Remove explicit version numbers from references.
* Fix indents and typo
* Unnest <pre> tag
* improve grammar in comments
are colliding -> collide
* Remove ternary operator and improve comments
* Fix typo in comment
The base class/documentation suggest that the argument
names are `self` and `done`, while the runtime used
argument names `srvc` and `callback`.
`mypy.stubtest` was able to identify this - as it compares
the types (autogenerated by
[`mypy-protobuf`](https://github.com/dropbox/mypy-protobuf/))
to the actual code generated by protoc at runtime.
Since the stubs assume the generated code matches the abstract
interface in service.py - it saw these differences.
This updates the CMake support to additionally symlink the soversion value
to the generated shared library when so generated. This aligns the
generated soversion with that traditionally used by the Makefile build
workflow and provides cross-compatibility irrespective of build approach
used.
The primary version of the non-symlink library retains the actual
(non-SO) project version for clarity and compatibility with
installations built using prior versions of CMake support. An example of
the net resulting symlink structures is shown below, where the most
important aspect is that the symlink matching the embedded SONAME is
present (libprotobuf.so.30 in the example case).
Makefile:
libprotobuf.so -> libprotobuf.so.30.0.0
libprotobuf.so.30 -> libprotobuf.so.30.0.0
libprotobuf.so.30.0.0
CMake:
libprotobuf.so -> libprotobuf.so.30
libprotobuf.so.30 -> libprotobuf.so.3.19.0.0
libprotobuf.so.3.19.0.0
Fixes: #8635
When both directories are added this results in protoc emitting a
"warning: directory does not exist.". This makes sense because when
there are no inputs from the other directory, it is also not present
n the sandbox where protoc is executed.
