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.