This fixes the issue: https://github.com/grpc/grpc/issues/16688
Which causes that grpc can not be build because of the following
compiler error:
third_party/cares/cares/ares_init.c: In function ‘ares_dup’:
third_party/cares/cares/ares_init.c:301:17: error: argument to ‘sizeof’ in ‘strncpy’ call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer- memaccess] sizeof(src->local_dev_name));
All these changes need to go together to make sense
- changes to use new version of upb in bazel
- allowing includes in build target option
- script for generating c code (upb) for protos
- generated code for example protos
- adding changes for non-bazel builds
- change sanity tests to ignore the generated files.
Bazel recognizes both "darwin" and "darwin_x86_64" as CPU values, and
the Apple Bazel rules currently recommend the latter for building
macOS targets. Until this is cleaned up, this change allows grpc to
build correctly when that configuration is used.
Fixes#17649.
The basic criteria is to have protoc generate code for envoy api's and
this change achieves that.
e.g.
protoc -I=$PWD -I=$PWD/third_party/data-plane-api -I=$PWD/third_party/googleapis -I=$PWD/third_party/protobuf -I=$PWD/third_party/protoc-gen-validate third_party/data-plane-api/envoy/api/v2/eds.proto
- Include new rules from bazelbuild/rules_python, which allow for
importing pip dependencies with Bazel.
- Make Cython BUILD file visible to WORKSPACE.
- Use a custom requirements file for Bazel python. This is added to
allow for requirements previously added only during build steps.