We here address the following warnings:
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:87:18: target 'grpc_cpp_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:93:18: target 'grpc_csharp_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:99:18: target 'grpc_node_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:105:18: target 'grpc_objective_c_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:111:18: target 'grpc_php_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:117:18: target 'grpc_python_plugin' is both a rule and a file; please choose another name for the rule
WARNING: /Users/dws/src/grpc-dws/src/compiler/BUILD:123:18: target 'grpc_ruby_plugin' is both a rule and a file; please choose another name for the rule
that come from asking Bazel to build the following:
@com_github_grpc_grpc//src/compiler:grpc_cpp_plugin
@com_github_grpc_grpc//src/compiler:grpc_csharp_plugin
@com_github_grpc_grpc//src/compiler:grpc_node_plugin
@com_github_grpc_grpc//src/compiler:grpc_objective_c_plugin
@com_github_grpc_grpc//src/compiler:grpc_php_plugin
@com_github_grpc_grpc//src/compiler:grpc_python_plugin
@com_github_grpc_grpc//src/compiler:grpc_ruby_plugin
The macro grpc_proto_plugin() in bazel/grpc_build_system.bzl has a genrule that uses the same name for both the rule and its output file. This macro gets used in src/compiler/BUILD to define the above plugin targets.
We address this by giving the rule's output file a different name from the rule. This avoids needing to update all the existing references to the plugin rules.
Closes#39060Closes#39165
PiperOrigin-RevId: 766690690
Our test script broke with Bazel 8 because it changed where it puts executables. The Bazel team suggested using `rlocation` to fix this (like b09335b86e). This should fix our C# and Objective-C codegen tests.
Partial commit of #38254Closes#38479
PiperOrigin-RevId: 716341395
Fix for https://github.com/grpc/grpc/issues/34113 - setting C# option
base_namespace to an empty string results in inconsistent behavior
Allow the `base_namespace` option in the protocol buffers C# gRPC plugin
to be specified with an empty string to make sure the plugin has the
same behaviour as the protocol buffers compiler.
Reverts grpc/grpc#32636
```
src/compiler/csharp_generator_helpers.h:25:7: error: no member named 'compiler' in namespace ...
src/compiler/csharp_generator_helpers.h:25:25: error: no member named 'csharp' in namespace 'compiler' ...
```
Added `base_namespace` experimental option to `grpc_csharp_plugin` as
this has been requested several times by
people not using `Grpc.Tools` to generate their code - see
https://github.com/grpc/grpc/issues/28663
Notes:
- it should not be used with `Grpc.Tools`. That has a different way of
handling duplicate proto file names in different directories. Using this
option will break those builds. It can only be used on the `protoc`
command line.
- it uses common code with the `base_namespace` option for C# in
`protoc`, which unfortunately has a slightly different name mangling
algorithm for converting proto file names to C# camel case names. This
only affects files with punctation or numbers in the name. This should
not matter unless you are expecting specific file names
- See
https://protobuf.dev/reference/csharp/csharp-generated/#compiler_options
for an explanation of this option
