Users still using the old `WORKSPACE` system may need to do the same or use `repo_mapping` on repositories that still use the old names. See Abseil's release notes for details: https://github.com/abseil/abseil-cpp/releases/tag/20250127.
PiperOrigin-RevId: 725247849
Enables bzlmod for most CI tests, except python (and thus upb) since infra for system python headers for python dist are not bzlmod compatible and require further work.
#test-continuous
PiperOrigin-RevId: 721946253
We need the minitable plugin to use the C++ plugin framework because it's soon
going to live in the same binary as the Rust code generator. The other plugins
we might as well move just for consistency, and this allows us to delete the
`upb::Plugin` class as well.
PiperOrigin-RevId: 716234662
This avoids installing every header required by protoc, and only installs the ones we've explicitly marked as public in bazel (and their transitive dependencies).
PiperOrigin-RevId: 709815861
This will help us avoid further bugs like #19735, where we're typically not very aware of how our files get installed as long as everything builds. With these tests in place, we will need to manually update the golden files whenever we add a new file to users' installations.
PiperOrigin-RevId: 709134471
The main branch was upgraded to use C++17 after the 29.0 branch cut, in commit
fe535930d3
There are still stale references to C++14 in the code, build chain, and
READMEs. This commit cleans up the stale configs and settings.
PiperOrigin-RevId: 706000867
cmake: make DEPENDENCIES in protobuf_generate() a multi-value keyword (#19175)
It was previously a one-value keyword, so given
```cmake
protobuf_generate(
...
DEPENDENCIES
a
b
)
```
`a` would be a dependency, and `b` would be discarded (or, more precisely, added to `protobuf_generate_UNPARSED_ARGUMENTS`).
This can be confirmed with the following changes:
```diff
diff --git a/cmake/protobuf-generate.cmake b/cmake/protobuf-generate.cmake
index 244407ee2..6dfbcef6d 100644
--- a/cmake/protobuf-generate.cmake
+++ b/cmake/protobuf-generate.cmake
@@ -10,6 +10,9 @@ function(protobuf_generate)
cmake_parse_arguments(protobuf_generate "${_options}" "${_singleargs}" "${_multiargs}" "${ARGN}")
+ message("Deps: ${protobuf_generate_DEPENDENCIES}")
+ message("Unparsed args: ${protobuf_generate_UNPARSED_ARGUMENTS}")
+
if(NOT protobuf_generate_PROTOS AND NOT protobuf_generate_TARGET)
message(SEND_ERROR "Error: protobuf_generate called without any targets or source files")
return()
diff --git a/cmake/tests.cmake b/cmake/tests.cmake
index 7976546fe..1cadf1e5a 100644
--- a/cmake/tests.cmake
+++ b/cmake/tests.cmake
@@ -27,6 +27,7 @@ foreach(proto_file ${lite_test_protos})
LANGUAGE cpp
OUT_VAR pb_generated_files
IMPORT_DIRS ${protobuf_SOURCE_DIR}/src
+ DEPENDENCIES a b
)
set(lite_test_proto_files ${lite_test_proto_files} ${pb_generated_files})
endforeach(proto_file)
```
Which printed "Deps: a" and "Unparsed args: b" for lite test files. With this change, it now prints "Deps: a;b" and "Unparsed args: ".
AFAIK, making `DEPENDENCIES` a multi-value keyword is mostly backwards-compatible; however, users who specified dependencies that were being ignored may be surprised to see that they are no longer ignored (which could cause build errors).
To prevent this kind of problem in the future, validating that `protobuf_generate_UNPARSED_ARGUMENTS` is empty could be useful, but to avoid potentially breaking more builds I did not do this in this PR.
Closes#19175
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/19175 from 71:protobuf-generate-dependencies c998afa11a
PiperOrigin-RevId: 694186507
Instead of fetching dependencies by default, we will first look for a local installation and only fetch as a fallback. Two new options are added for forcing either of these behaviors. protobuf_FORCE_FETCH_DEPENDENCIES will always fetch dependencies, and protobuf_PREVENT_FETCH_DEPENDENCIES will never do so.
#test-continuous
PiperOrigin-RevId: 693898394
upb headers are not in `${protobuf_SOURCE_DIR}/src`, so the `string(REPLACE ...)` command fails and the `save-installed-headers.vcxproj` contains an invalid path regarding upb headers, causing a failure in compilation.
Closes#18135
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18135 from Delcaran:main 28c40493e3
PiperOrigin-RevId: 686963169
See abseil release notes:
https://github.com/abseil/abseil-cpp/releases/tag/20240722.0
This is necesary pre-work to enable C++17 builds in preparation of baseline C++
upgrade from C++14 to C++17. C++14 support is scheduled to reach EOL on
2024-12-15:
https://github.com/google/oss-policies-info/blob/main/foundational-cxx-support-matrix.md
Interestingly enough, the older Abseil version 20230802.1 is actually OK for
building on macOS with C++17. However, we depend on GoogleTest, and they
transitively depend on Abseil version 20240116.2, which caused Bazel to
implicitly change the Abseil dependency to most recent specified version of
20240116.2:
https://github.com/google/googletest/blob/main/MODULE.bazel
Current builds with C++17 and Abseil version 20240116.2 on older macos versions
that didn't support `std::filesystem::path` would give the following error:
> error: 'path' is unavailable: introduced in macOS 10.15.
With this version upgrade, we pull in an Abseil patch that fixes this issue on
macOS:
65a55c2ba8
PiperOrigin-RevId: 686670268
This flips the default behavior to "fetch", downloading local copies of required dependencies. This can be disabled by setting `-Dprotobuf_FETCH_DEPENDENCIES=OFF`, in which case we will look for a local installation using find_package. Setting `-Dprotobuf_ABSL_PROVIDER=package` will continue to have the same behavior as before.
See https://protobuf.dev/news/2024-10-02/#replace-cmake-submods for more details.
#test-continuous
PiperOrigin-RevId: 686649864
Mike Kruskal
Adam Cozzette
zhangskz
Protobuf Team Bot
Mike Kruskal
Tony Liao
Andre Sailer
Grégoire Geis
Matteo
Protobuf Team Bot
Zoey Greer