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
Before this CL, it was only possible to get CHandles when fetching messages from a map. proto2::cpp does not have this restriction, so we patch this gap in here.
+utilize the new Emit :)
PiperOrigin-RevId: 686475508