2018-11-29 07:21:40 +01:00
|
|
|
################################################################################
|
|
|
|
|
#
|
|
|
|
|
# grpc
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
2022-04-25 10:05:44 +02:00
|
|
|
GRPC_VERSION = 1.45.2
|
package: remove 'v' prefix from github-fetched packages
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>
2019-06-12 08:42:06 +02:00
|
|
|
GRPC_SITE = $(call github,grpc,grpc,v$(GRPC_VERSION))
|
2021-12-11 21:23:35 +01:00
|
|
|
GRPC_LICENSE = Apache-2.0, BSD-3-Clause (third_party code), MPL-2.0 (etc/roots.pem)
|
2018-11-29 07:21:40 +01:00
|
|
|
GRPC_LICENSE_FILES = LICENSE
|
2021-05-16 12:50:26 +02:00
|
|
|
GRPC_CPE_ID_VENDOR = grpc
|
2018-11-29 07:21:40 +01:00
|
|
|
|
|
|
|
|
GRPC_INSTALL_STAGING = YES
|
|
|
|
|
|
|
|
|
|
# Need to use host grpc_cpp_plugin during cross compilation.
|
2020-09-11 18:34:09 +02:00
|
|
|
GRPC_DEPENDENCIES = c-ares host-grpc libabseil-cpp openssl protobuf re2 zlib
|
package/grpc: restrict host-grpc to the absolute minimum
Currently, grpc depends on the full host-grpc, which in turn depends on host
versions of many other libraries. One of these, host-libabseil-cpp, also
requires a host gcc 4.9 or larger, a dependency which is not met on CentOS
7.
But in fact, the target grpc only needs the 'grpc_cpp_plugin' binary from
host-grpc. And that binary does not depend on host-libabseil-cpp or other
libraries, only on host-protobuf.
Given the above, simplify the grpc/host-grpc situation.
- Add a patch to the (host-)grpc CMakeLists.txt file to add an option to
only build grpc_cpp_plugin.
- Update grpc.mk and Config.in to remove the unnecessary dependencies, and
change the host-grpc configure options to make cmake happy.
The advantages of these changes are:
- making grpc available to older hosts with gcc < 4.8, like CentOS 7
- significantly reducing the build time of host-grpc and its dependencies
The patch was proposed upstream but not accepted with below rationale.
Perhaps input from others can help in persuading upstream in a future
attempt.
'What you're doing sounds like quite a narrow use case. But we simply
cannot provide a cmake option for every possible scenario in the world.
Introducing a new cmake option isn't for free and requires careful
design and maintenance.'
Nevertheless, given the benefits in terms of build time and dependency
reduction, it makes sense to apply this patch in spite of the disadvantage
of a local non-upstreamed patch.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[Arnout: propagate removed dependency to collectd]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-05-25 20:20:44 +02:00
|
|
|
HOST_GRPC_DEPENDENCIES = host-protobuf
|
2018-11-29 07:21:40 +01:00
|
|
|
|
2019-02-23 03:10:59 +01:00
|
|
|
# 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.
|
2018-11-29 07:21:40 +01:00
|
|
|
GRPC_CONF_OPTS = \
|
2022-03-15 18:32:31 +01:00
|
|
|
-DCMAKE_EXE_LINKER_FLAGS="$(GRPC_EXE_LINKER_FLAGS)" \
|
2020-09-11 18:34:09 +02:00
|
|
|
-DgRPC_ABSL_PROVIDER=package \
|
2018-11-29 07:21:40 +01:00
|
|
|
-D_gRPC_CARES_LIBRARIES=cares \
|
|
|
|
|
-DgRPC_CARES_PROVIDER=none \
|
|
|
|
|
-DgRPC_PROTOBUF_PROVIDER=package \
|
2020-08-13 16:45:49 +02:00
|
|
|
-DgRPC_RE2_PROVIDER=package \
|
2018-11-29 07:21:40 +01:00
|
|
|
-DgRPC_SSL_PROVIDER=package \
|
2021-02-03 13:43:24 +01:00
|
|
|
-DgRPC_ZLIB_PROVIDER=package \
|
|
|
|
|
-DgRPC_BUILD_GRPC_CPP_PLUGIN=OFF \
|
|
|
|
|
-DgRPC_BUILD_GRPC_CSHARP_PLUGIN=OFF \
|
|
|
|
|
-DgRPC_BUILD_GRPC_NODE_PLUGIN=OFF \
|
|
|
|
|
-DgRPC_BUILD_GRPC_OBJECTIVE_C_PLUGIN=OFF \
|
|
|
|
|
-DgRPC_BUILD_GRPC_PHP_PLUGIN=OFF \
|
|
|
|
|
-DgRPC_BUILD_GRPC_PYTHON_PLUGIN=OFF \
|
|
|
|
|
-DgRPC_BUILD_GRPC_RUBY_PLUGIN=OFF
|
2018-11-29 07:21:40 +01:00
|
|
|
|
2022-03-15 18:32:31 +01:00
|
|
|
ifeq ($(BR2_PACKAGE_LIBEXECINFO),y)
|
|
|
|
|
GRPC_DEPENDENCIES += libexecinfo
|
|
|
|
|
GRPC_EXE_LINKER_FLAGS += -lexecinfo
|
|
|
|
|
endif
|
|
|
|
|
|
2018-12-07 18:12:41 +01:00
|
|
|
# grpc can use __atomic builtins, so we need to link with
|
|
|
|
|
# libatomic when available
|
|
|
|
|
ifeq ($(BR2_TOOLCHAIN_HAS_LIBATOMIC),y)
|
2022-03-15 18:32:31 +01:00
|
|
|
GRPC_EXE_LINKER_FLAGS += -latomic
|
2018-12-07 18:12:41 +01:00
|
|
|
endif
|
|
|
|
|
|
2019-10-28 12:50:10 +01:00
|
|
|
GRPC_CFLAGS = $(TARGET_CFLAGS)
|
|
|
|
|
GRPC_CXXFLAGS = $(TARGET_CXXFLAGS)
|
|
|
|
|
|
2019-06-02 18:25:57 +02:00
|
|
|
# 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:)
|
2019-10-28 12:50:10 +01:00
|
|
|
GRPC_CFLAGS += -DGPR_DISABLE_WRAPPED_MEMCPY
|
|
|
|
|
GRPC_CXXFLAGS += -DGPR_DISABLE_WRAPPED_MEMCPY
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_TOOLCHAIN_HAS_GCC_BUG_85180),y)
|
|
|
|
|
GRPC_CFLAGS += -O0
|
|
|
|
|
GRPC_CXXFLAGS += -O0
|
2019-06-02 18:25:57 +02:00
|
|
|
endif
|
|
|
|
|
|
2019-10-28 12:50:10 +01:00
|
|
|
GRPC_CONF_OPTS += \
|
|
|
|
|
-DCMAKE_C_FLAGS="$(GRPC_CFLAGS)" \
|
|
|
|
|
-DCMAKE_CXX_FLAGS="$(GRPC_CXXFLAGS)"
|
|
|
|
|
|
package/grpc: restrict host-grpc to the absolute minimum
Currently, grpc depends on the full host-grpc, which in turn depends on host
versions of many other libraries. One of these, host-libabseil-cpp, also
requires a host gcc 4.9 or larger, a dependency which is not met on CentOS
7.
But in fact, the target grpc only needs the 'grpc_cpp_plugin' binary from
host-grpc. And that binary does not depend on host-libabseil-cpp or other
libraries, only on host-protobuf.
Given the above, simplify the grpc/host-grpc situation.
- Add a patch to the (host-)grpc CMakeLists.txt file to add an option to
only build grpc_cpp_plugin.
- Update grpc.mk and Config.in to remove the unnecessary dependencies, and
change the host-grpc configure options to make cmake happy.
The advantages of these changes are:
- making grpc available to older hosts with gcc < 4.8, like CentOS 7
- significantly reducing the build time of host-grpc and its dependencies
The patch was proposed upstream but not accepted with below rationale.
Perhaps input from others can help in persuading upstream in a future
attempt.
'What you're doing sounds like quite a narrow use case. But we simply
cannot provide a cmake option for every possible scenario in the world.
Introducing a new cmake option isn't for free and requires careful
design and maintenance.'
Nevertheless, given the benefits in terms of build time and dependency
reduction, it makes sense to apply this patch in spite of the disadvantage
of a local non-upstreamed patch.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[Arnout: propagate removed dependency to collectd]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-05-25 20:20:44 +02:00
|
|
|
# For host-grpc, we only need the 'grpc_cpp_plugin' binary, which is needed for
|
|
|
|
|
# target grpc compilation. To avoid unnecessary build steps and host
|
|
|
|
|
# dependencies, supply enough options to pass the configure checks without
|
|
|
|
|
# requiring other host packages, unless those needed by grpc_cpp_plugin.
|
2018-11-29 07:21:40 +01:00
|
|
|
HOST_GRPC_CONF_OPTS = \
|
|
|
|
|
-DgRPC_PROTOBUF_PROVIDER=package \
|
package/grpc: restrict host-grpc to the absolute minimum
Currently, grpc depends on the full host-grpc, which in turn depends on host
versions of many other libraries. One of these, host-libabseil-cpp, also
requires a host gcc 4.9 or larger, a dependency which is not met on CentOS
7.
But in fact, the target grpc only needs the 'grpc_cpp_plugin' binary from
host-grpc. And that binary does not depend on host-libabseil-cpp or other
libraries, only on host-protobuf.
Given the above, simplify the grpc/host-grpc situation.
- Add a patch to the (host-)grpc CMakeLists.txt file to add an option to
only build grpc_cpp_plugin.
- Update grpc.mk and Config.in to remove the unnecessary dependencies, and
change the host-grpc configure options to make cmake happy.
The advantages of these changes are:
- making grpc available to older hosts with gcc < 4.8, like CentOS 7
- significantly reducing the build time of host-grpc and its dependencies
The patch was proposed upstream but not accepted with below rationale.
Perhaps input from others can help in persuading upstream in a future
attempt.
'What you're doing sounds like quite a narrow use case. But we simply
cannot provide a cmake option for every possible scenario in the world.
Introducing a new cmake option isn't for free and requires careful
design and maintenance.'
Nevertheless, given the benefits in terms of build time and dependency
reduction, it makes sense to apply this patch in spite of the disadvantage
of a local non-upstreamed patch.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[Arnout: propagate removed dependency to collectd]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-05-25 20:20:44 +02:00
|
|
|
-DgRPC_ABSL_PROVIDER=none \
|
|
|
|
|
-DgRPC_CARES_PROVIDER=none \
|
|
|
|
|
-DgRPC_RE2_PROVIDER=none \
|
|
|
|
|
-DgRPC_SSL_PROVIDER=none \
|
|
|
|
|
-DgRPC_ZLIB_PROVIDER=none \
|
|
|
|
|
-DgRPC_BUILD_CODEGEN=OFF \
|
|
|
|
|
-DgRPC_BUILD_CSHARP_EXT=OFF \
|
|
|
|
|
-DgRPC_BUILD_PLUGIN_SUPPORT_ONLY=ON \
|
|
|
|
|
-DgRPC_BUILD_GRPC_CSHARP_PLUGIN=OFF \
|
|
|
|
|
-DgRPC_BUILD_GRPC_NODE_PLUGIN=OFF \
|
|
|
|
|
-DgRPC_BUILD_GRPC_OBJECTIVE_C_PLUGIN=OFF \
|
|
|
|
|
-DgRPC_BUILD_GRPC_PHP_PLUGIN=OFF \
|
|
|
|
|
-DgRPC_BUILD_GRPC_PYTHON_PLUGIN=OFF \
|
|
|
|
|
-DgRPC_BUILD_GRPC_RUBY_PLUGIN=OFF
|
2018-11-29 07:21:40 +01:00
|
|
|
|
|
|
|
|
$(eval $(cmake-package))
|
|
|
|
|
$(eval $(host-cmake-package))
|
