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
Initial bazel tests for C# protoc and grpc_protoc_plugin.
This initial test just generated code from the proto file and compares
the generated code against expected files.
I've put the tests in `test/csharp/codegen` as that is similar to where
the C++ tests are placed, but they could be moved to
`src\csharp` if that is a better place.
Further tests can be added once the initial framework for the tests is
agreed.