This represents the future direction of protobuf, replacing proto2/proto3 syntax with editions. These will enable more incremental evolution of protobuf APIs through features, which are individual behaviors (such as whether field presence is explicit or implicit). For more details see https://protobuf.dev/editions/overview/.
This PR contains a working implementation of editions for the protoc frontend and C++ code generation, along with various infrastructure improvements to support it. It gives early access for anyone who wants to a preview of editions, but has no effect on proto2/proto3 syntax. It is flag-guarded behind the `--experimental_editions` flag, and is an experimental feature with no guarantees.
PiperOrigin-RevId: 544805690
This additional if is necessary as of abseil 20230125.3 when abseil is consumed via add_subdirectory,
the abseil_dll target is named abseil_dll, while if abseil is consumed via find_package, the target is called `absl::abseil_dll` .
Once https://github.com/abseil/abseil-cpp/pull/1466 is merged and released in the minimum version of abseil required by protobuf, it is possible to always link `absl::abseil_dll` and `absl::abseil_test_dll` and remove the if.
You may wonder how linking worked at all before when `protobuf_ABSL_PROVIDER STREQUAL "package"`, as `abseil_dll` was not an imported target defined by `find_package(absl)`. The reason behind this is that if a name that is not an imported target is passed to `target_link_libraries`, it is just regarded as a C++ library name. So, in the end the `abseil_dll` library was correctly linked, simply all the transitive usage requirements defined by the `absl::abseil_dll` target were not propagated, that could lead to compilation errors if abseil was compiled with the `ABSL_PROPAGATE_CXX_STD` CMake option enabled.
Closes#12978
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12978 from traversaro:patch-1 39dd074281
PiperOrigin-RevId: 537990391
In CMake >= 3.0 it is more idiomatic to set per-target compiler options than global compiler settings. I have kept these options and defines as `PRIVATE` so they won't be exported with the target.
Closes#12916
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12916 from coryan:cleanup-cmake-avoid-global-compile-settings 3d586dc0e8
PiperOrigin-RevId: 536517165
This will require C++14 (or higher) for the `libproto*` targets **and** anything that links them. If multiple dependencies have different C++ requirements, CMake will use the maximum version. It does not work with pkg-config, and does not work if the downstream dependency forcibly downgrades the compiler to C++11 (or lower). But prevents many problems. Note that if Abseil was compiled with C++17 it will require C++17 and that will propagate through Protobuf.
Closes#12901
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12901 from coryan:feat-cmake-use-target-compile-features 95084ac691
PiperOrigin-RevId: 535579816
When building protobuf with BUILD_SHARED_LIBS disabled, conformance_test_runner should link jsoncpp_static but not jsoncpp_lib.
Closes#12733
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12733 from semlanik:main 2ab4be6bb0
PiperOrigin-RevId: 530926843
When the protobuf libraries have been compiled as shared libraries the users of the library need to add `-DPROTOBUF_USE_DLLS` to their build line. Otherwise some symbols are missing.
Fixes#12699
FWIW, I am not sure this is an ideal fix. It may be better to fix the headers such that no macros change the ABI.
Closes#12700
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12700 from coryan:fix-define-protobuf-use-dlls-in-pkg-config-file 13c792eebd
PiperOrigin-RevId: 530116678
When the protobuf libraries have been compiled as shared libraries the users of the library need to add `-DPROTOBUF_USE_DLLS` to their build line. Otherwise some symbols are missing.
Fixes#12699
FWIW, I am not sure this is an ideal fix. It may be better to fix the headers such that no macros change the ABI.
Closes#12700
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12700 from coryan:fix-define-protobuf-use-dlls-in-pkg-config-file 13c792eebd
PiperOrigin-RevId: 530116678
These more closely follow the standard practices of our users, where dependencies are pre-installed instead of using our provided sub-modules. This will prevent issues such as #12201 from reoccuring.
Additionally, this cl bumps our Abseil dependency to the latest release, and fixes a GTest issue that went previously unnoticed.
PiperOrigin-RevId: 529490402
These more closely follow the standard practices of our users, where dependencies are pre-installed instead of using our provided sub-modules. This will prevent issues such as #12201 from reoccuring.
Additionally, this cl bumps our Abseil dependency to the latest release, and fixes a GTest issue that went previously unnoticed.
PiperOrigin-RevId: 529490402
Allows the use of an external `jsoncpp` library to be used. Replicates the model used by `abseil-cpp` as a "package" or "module" to the `protobuf_JSONCPP_PROVIDER` option.
Resolves: #11827Closes#12577
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12577 from omenos:omenos/cmake-jsoncpp 073edd69b4
PiperOrigin-RevId: 528492610
This should fix#12374, #12375, and #12450. The `protobuf_PROTOC_EXEC` variable
is not defined, and I think `protobuf::protoc` is what we should be using
instead.
PiperOrigin-RevId: 525591320
For now, this only covers linux on the two architectures we have testing support for. However, it serves as a good sanity check and can be expanded in the future.
PiperOrigin-RevId: 514449399
For now, this only covers linux on the two architectures we have testing support for. However, it serves as a good sanity check and can be expanded in the future.
PiperOrigin-RevId: 514449399
This migrates from reusable workflows to composite GHA actions. This has the following advantages:
1) We can split them into smaller, easier to reason about chunks
2) We can reuse them more freely between each other and workflows
3) They don't complicate the job names
4) In theory they'll be easier to test in isolation. While composite actions can't be unit-tested, we can easily break them up into nodejs or docker actions that can be.
As a proof of concept, some of our non-Bazel tests are migrated to GHA as well (CMake + Composer)
Closes#11718
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11718 from protocolbuffers:gha-actions 5403307bc00616e94816aa460813939d8f37a1bd
PiperOrigin-RevId: 506375417
This deletes our old branches of internal Abseil code in favor of their newly open-sourced library. Notably, this removes the ability to turn CHECK crashes into exceptions.
PiperOrigin-RevId: 504460562
This will make the CMake workflow easier, where users won't need to either install utf8_range or initialize our submodules. Since this is a relatively small library that's owned by us, we can just bundle it with protobuf as a subtree
Closes#11608
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11608 from mkruskal-google:utf8_range_dep 57d5d91b68
PiperOrigin-RevId: 503314822
This leaves the decision of which C++ version to use up to our users. We still have a static_assert in port_def.inc that will prevent pre-C++14 usage.
PiperOrigin-RevId: 501351066
I went ahead and deleted the update_file_list.sh script, because (a)
there was no good reason for it to be in a separate script and (b) we
now need to handle the well-known types in addition to file_lists.cmake.
With this change, we just invoke the staleness tests from the main
script to update everything.
While I was at it I made a couple small fixes:
- Don't skip the update step just because the previous commit was by
"Protobuf Team Bot". Copybara commits use this name and we still want
to do the auto-update step after them.
- Include the CL number in the description if the previous commit came
from a CL.
PiperOrigin-RevId: 487231324
This cl hit an issue during the shared library cmake build from ODR violations, leading to mismatched absl hash seeds. The problem was pre-existing but didn't manifest until now, and can be traced to the fact that in shared library builds we linked Abseil statically. All of the cmake changes here remove the underlying ODR violation.
PiperOrigin-RevId: 485787671
* Adding jsoncpp submodule
* Adding bazel dependency
* Hook up jsoncpp in Bazel builds
* Hook up jsoncpp dependency in CMake
* Fix conformance binary path
* Move jsoncpp import to the end of the file to avoid confusing add_test
Euclid
Mike Kruskal
Adam Cozzette
Silvio Traversaro
Carlos O'Ryan
Alexey Edelev
Protobuf Team Bot
Mike Kruskal
Mike Rochefort
Deanna Garcia
deannagarcia
Joris Clement