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.
Currently, grpc_cc_test with size="large" will still have
timeout="moderate" (which corresponds to medium size test)
because the timeout will be overriden by the default arg.
Fixing as this behavior is very counterintuitive.
protos
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 for protos
- generated code for example build
- adding changes for non-bazel builds
- change sanity tests to ignore the generated files.
Building gRPC Python with Bazel has been one of the long requested
additions to gRPC (#8079). Doing so had been made complex by the fact
that Bazel itself is still in active development.
There has been extensive work on building Cython code at tensorflow,
which can be reused for gRPC's purposes as well.
Major included changes required for building grpcio with Bazel are:
- Include Cython as a third party Bazel package, to compile the Cython
parts of gRPC Python.
- Include rules for Python autoconfiguration so Python headers can be
detected by cygrpc.