This change adds `ares_android.h` and `ares_android.c` to the `third_party/cares/cares.BUILD` in order to support builds in the Android Native Development Kit (NDK).
Fixes grpc#21437
genrules are not supported on Windows without
an msys bash installation, which is an undesirable
dependency. Fortunately we can use skylib's copy_file
to accomplish the same thing as the genrules were doing.
release notes: no
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));
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.
For ios build, bazel build needs to be invoked with:
--ios_multi_cpu=armv7,arm64 build. This in turn gets picked as
cpu based on the docs:
--[no]experimental_enable_objc_cc_deps default: "true"
Allows objc_* rules to depend on cc_library and causes any objc dependencies to be built with --cpu set to "ios_<--ios_cpu>" for any values in --ios_multi_cpu.
This diff explicitly adds darwin config for cpu being ios_x86_64, ios_armv7,
ios_armv7s and ios_arm64. We cant use ios_cpu as condition because its set to x86_64
by default and causes linux build break.
The WORKSPACE file now pulls third_party dependencies directly instead of requiring a git submodule init and update.
The git hashes pulled by Bazel are exactly the same as the git submodules checked into third_party.
A tiny bit of complexity comes from the c-ares project's use of ares_config.h.cmake and ares_build.c.cmake.
The current solution to this problem is to check in a valid ares_config.h and a few valid ares_config.h files.
This is the same general approach used still, but ares_config.h and ares_build.h are supplied to cares.BUILD
from the only remaining local_repository, which serves only to export these two header files.
- Update CMakeLists.txt (original template and generated code)
to prevent forcefully linking `dl` on all UNIX platforms,
and rely on `${CMAKE_DL_LIBS}` portable variable instead.
- Do not try linking against `librt` on macOS.
- Add a `config_freebsd` directory containing the header file
generated by the `configure` script for the `ares` library.