kumquat-buildroot/package/grpc/grpc.mk
Trent Piepho d88a6fa9a9 package/grpc: update to 1.18.0
Bump version.  Freshen a patch that had a conflict.

Remove duplicate env setting.

Add comment about the hack being used to get gRPC to use the buildroot
c-ares library.  Otherwise it looks like the cmake env settings are out
of date vs what the gRPC build documentation says to use.

Signed-off-by: Trent Piepho <tpiepho@impinj.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-17 17:39:22 +01:00

45 lines
1.5 KiB
Makefile

################################################################################
#
# grpc
#
################################################################################
GRPC_VERSION = v1.18.0
GRPC_SITE = $(call github,grpc,grpc,$(GRPC_VERSION))
GRPC_LICENSE = Apache-2.0
GRPC_LICENSE_FILES = LICENSE
GRPC_INSTALL_STAGING = YES
# Need to use host grpc_cpp_plugin during cross compilation.
GRPC_DEPENDENCIES = c-ares host-grpc openssl protobuf zlib
HOST_GRPC_DEPENDENCIES = host-c-ares host-openssl host-protobuf host-zlib
# gRPC_CARES_PROVIDER=package won't work because it requires c-ares to have
# installed a cmake config file, but buildroot uses c-ares' autotools build,
# which doesn't do this. These CARES settings trick the gRPC cmake code into
# not looking for c-ares at all and yet still linking with the library.
GRPC_CONF_OPTS = \
-D_gRPC_CARES_LIBRARIES=cares \
-DgRPC_CARES_PROVIDER=none \
-DgRPC_PROTOBUF_PROVIDER=package \
-DgRPC_SSL_PROVIDER=package \
-DgRPC_ZLIB_PROVIDER=package \
-DgRPC_NATIVE_CPP_PLUGIN=$(HOST_DIR)/bin/grpc_cpp_plugin
# grpc can use __atomic builtins, so we need to link with
# libatomic when available
ifeq ($(BR2_TOOLCHAIN_HAS_LIBATOMIC),y)
GRPC_CONF_OPTS += -DCMAKE_EXE_LINKER_FLAGS=-latomic
endif
HOST_GRPC_CONF_OPTS = \
-D_gRPC_CARES_LIBRARIES=cares \
-DgRPC_CARES_PROVIDER=none \
-DgRPC_PROTOBUF_PROVIDER=package \
-DgRPC_SSL_PROVIDER=package \
-DgRPC_ZLIB_PROVIDER=package
$(eval $(cmake-package))
$(eval $(host-cmake-package))