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
For cross-compilation, we may not want to re-use the same protoc which would be used during a CMake build (these would differ in hostPlatform).
Instead, allow for invocations of `protobuf_generate` pass their preferred programs, similar to how you can do this for grpc plugins.
Optional proposal:
Use `find_program`, however, this is a pretty big behavior change, this PR allows you to "opt-out" of the legacy behavior, but users shouldn't see a difference unless they opt-in to passing their own protoc-exe command/path
Closes#17888
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17888 from jonringer:configure-protoc-cmake 9ca38aee11
PiperOrigin-RevId: 678383523
The current logic of finding a suitable include path relies on CMake to always return a meaningful relative path. On Windows, however, if the two paths reside on different drives (e.g. `c:/Users/Me` and `d:/project/`) the absolute path gets returned unaltered. This yields the invalid final path `c:/Users/Me/d:/project/`.
This case is now detected and the corresponding include path is deemed unsuitable.
(fixes#9290)
Closes#14025
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/14025 from cgudrian:issue-9290-wrong-relative-path-in-protobuf-generate 3c0fd37324
PiperOrigin-RevId: 573315544
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
When using "FetchContent_Declare" with OVERRIDE_FIND_PACKAGE,
protobuf-config.cmake won't be used, thus the protobuf-generate macro
would be unavailable. By moving protobuf_generate to its own file, it
can be sourced and used even when using CMake's FetchContent.
Co-authored-by: Harald Fernengel <547273+haraldF@users.noreply.github.com>
* Revert "Added cmake abseil include guard"
This reverts commit b6ee841d7c.
* Revert "Update CMake configuration to add a dependency on Abseil (#9793)"
This reverts commit e9246cd789.
* Proof of concept for CMake Abseil dependency
* Hooked up Abseil linking
* Adding test binaries
* Reverting absl::string view use added for testing. This will still be broken for automake and bazel
* Adding new cmake config to dist list
* Whitespace fixes and an attempt at fix for Windows Python Release (CMake version < 3.13)
* Hook up LTS to windows cmake
* Fix 'git cd' typo
* Adding clarifying comment for fix
* Adding abseil dependency to protobuf-lite too
* Update submodules instead of cloning abseil-cpp
* Adding explicit pointer to abseil root directory
Co-authored-by: Jason Lunn <jason.lunn@gmail.com>
Co-authored-by: Jorg Brown <jorg.brown@gmail.com>
* add plugin options
* refactored comment message
* added tabs for better readability
* removed newlines as they are not working properly
* allow PROTOC_OPTIONS and EXPORT_MACRO in parallel for protobuf_generate
When there are multiple proto file inputs, they are matched with the provided proto directories (-I option). These directories are tested sequentially for each input proto file and if input file is in a subdirectory of provided proto directories, this directory is considered as base for calculating output directory. This update provides same manner and removes limitations imposed by using `${CMAKE_CURRENT_SOURCE_DIR}` as main proto import directory.
1- `${CMAKE_CURRENT_SOURCE_DIR}` is only added to include directories if no import directory is provided and we are not in `APPEND_PATH` mode. In addition it is added as last possible directory to decrease its priority in searching.
2- Each directory is checked against `${_protobuf_include_path}` to find first possible directory which is parent directory of input proto file. If a directory is found, `${_rel_dir}` is calculated based on its value. If no suitable folder is found, an error will be generated.
This reverts commit 93f6b67eb2.
Protoc adds already the relative path to the output directory.
Therefore, we have to remove this again from the output directory
to prevent adding it twice.
Without this fix, protobuf_generate() sets the variable _generated_srcs to
${protobuf_generate_PROTOC_OUT_DIR}/${_rel_dir}/${_basename}${_ext}
but generates the files in
${protobuf_generate_PROTOC_OUT_DIR}/${_basename}${_ext}
A series of improvements:
- Improved Protobuf module compatibility (disabled by default);
- Hide advanced settings;
- Added build tree configuration;
- Added build of examples.
Grégoire Geis
Jonathan Ringer
Christian Gudrian
Adam Cozzette
Mike Kruskal
Harald Fernengel
Mike Kruskal
cjtallman
Arfrever Frehtes Taifersar Arahesis
Timo Lange
Igor Sirotin
Afshin Pir
listonjesse
Falko Axmann
Xiang Dai
Markus Heß
Markus Heß
Steffen Wittmeier
Christian von Arnim
Ben Boeckel
Walter Gray
Konstantin Podsvirov
Feng Xiao