69808c7536
On Github, a large number of projects name their tag vXYZ (i.e v3.0, v0.1, etc.). In some packages we do: <pkg>_VERSION = v0.3 <pkg>_SITE = $(call github foo,bar,$(<pkg>_VERSION)) And in some other packages we do: <pkg>_VERSION = 0.3 <pkg>_SITE = $(call github foo,bar,v$(<pkg>_VERSION)) I.e in one case we consider the version to be v0.3, in the other case we consider 0.3 to be the version. The problem with v0.3 is that when used in conjunction with release-monitoring.org, it doesn't work very well, because release-monitoring.org has the concept of "version prefix" and using that they drop the "v" prefix for the version. Therefore, a number of packages in Buildroot have a version that doesn't match with release-monitoring.org because Buildroot has 'v0.3' and release-monitoring.org has '0.3'. Since really the version number of 0.3, is makes sense to update our packages to drop this 'v'. This commit only addresses the (common) case of github packages where the prefix is simply 'v'. Other cases will be handled by separate commits. Also, there are a few cases that couldn't be handled mechanically that aren't covered by this commit. Signed-off-by: Victor Huesca <victor.huesca@bootlin.com> [Arnout: don't change flatbuffers, json-for-modern-cpp, libpagekite, python-scapy3k, softether] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
53 lines
1.8 KiB
Makefile
53 lines
1.8 KiB
Makefile
################################################################################
|
|
#
|
|
# grpc
|
|
#
|
|
################################################################################
|
|
|
|
GRPC_VERSION = 1.18.0
|
|
GRPC_SITE = $(call github,grpc,grpc,v$(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
|
|
|
|
# Set GPR_DISABLE_WRAPPED_MEMCPY otherwise build will fail on x86_64 with uclibc
|
|
# because grpc tries to link with memcpy@GLIBC_2.2.5
|
|
ifeq ($(BR2_x86_64):$(BR2_TOOLCHAIN_USES_GLIBC),y:)
|
|
GRPC_CONF_OPTS += \
|
|
-DCMAKE_C_FLAGS="$(TARGET_CFLAGS) -DGPR_DISABLE_WRAPPED_MEMCPY" \
|
|
-DCMAKE_CXX_FLAGS="$(TARGET_CXXFLAGS) -DGPR_DISABLE_WRAPPED_MEMCPY"
|
|
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))
|