It's not the default with older Apple clang builds
and without it c++11 features don't work on at least OS X 10.7:
./src/core/lib/gprpp/ref_counted.h:28:10: fatal error: 'atomic' file not found
#include <atomic>
^~~~~~~~
I manually tested it on macOS 10.11 image and there was not a
regression.
This should fix the "Artifact Build MacOS (internal CI)" test failure.
* Use templates instead of generating them every time
* Theme changed
* Add grpc_* modules
* APIs grouped
* No documentation for class members without docstring
* Add docstring for status code
Add an environmental variable GRPC_PYTHON_DISABLE_LIBC_COMPATIBILITY that unsets the GPR_BACKWARDS_COMPATIBILITY_MODE macro during the C++ build.
The reason I'm interested in this to allow gpr_now to use the vdso rather than a syscall to read the time.
Modern Python dependancy tooling as defined in PEP-508 should use environment markers for Python version specific requirements.
This allows the `grpcio` package to work with dependancy resolvers like poetry
When building the python module and using the new
GRPC_PYTHON_BUILD_SYSTEM_CARES env variable, the third party cares code
is not compiled. Instead, the cares shared library installed on the
system is used during runtime.
This is useful for distributions who don't want to include code copies
but use shared libraries instead.
When building the python module and using the new
GRPC_PYTHON_BUILD_SYSTEM_ZLIB env variable, the third party zlib code
is not compiled. Instead, the zlib shared library installed on the
system is used during runtime.
This is useful for distributions who don't want to include code copies
but use shared libraries instead.
When building the python module and using the new
GRPC_PYTHON_BUILD_SYSTEM_OPENSSL env variable, the third party
boringssl code is not compiled. Instead, the openssl shared library
installed on the system is used during runtime.
This is useful for distributions who don't want to include code copies
but use shared libraries instead.
Nikolai Lifanov