gRPC C 依赖接入与构建全指南Bazel、CMake、pkg-config 三种集成路径详解【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc导读src/cpp/README.md是 gRPC 仓库中面向 C 使用者的第一入口文档系统介绍了如何把 gRPC C 作为依赖接入自己的工程以及 gRPC C 源码本身的构建方式。本文以该文档为骨架结合仓库中的 MODULE.bazel、WORKSPACE、BUILDING.md、helloworld 示例 等真实配置与源码完整梳理官方支持的平台矩阵、Bazelbzlmod 与旧版 WORKSPACE 两种模式、CMakefind_package / FetchContent / git submodule / 系统已安装 gRPC、pkg-config、make已弃用以及 vcpkg 等全部接入方式并补充了 C17 一致性、依赖 Provider 策略、安装与交叉编译等实战细节。读完本文你将能够针对自己的构建环境选择并落地一条可复现、可维护的 gRPC C 集成方案。src/cpp/目录下存放的是 gRPC 的 C 实现包含grpc/grpcpp的 C API 封装与上层代码。由于 C 生态中不存在公认统一的依赖管理标准gRPC 同时支持多种主流构建系统以满足绝大多数使用场景这正是本文要逐一展开的内容。一、支持的平台与支持级别gRPC C 官方将平台支持划分为三个级别使用者在选型前应先确认自己目标平台的归属官方支持Officially Supported遵循 OSS Foundational C Support Policy 选定官方在这些平台上运行自动化持续集成CI测试问题会被优先修复。尽力支持Best Effort没有 CI 测试覆盖但官方对在这些平台上运行有较高信心会尽力维护并欢迎补丁个别问题可能无法解决。社区支持Community Supported完全由开源社区贡献者维护没有官方支持承诺损坏可能长期无人察觉维护责任在社区长期无人维护的代码可能被删除。操作系统架构支持级别Linux - Debian、Ubuntu、CentOSx86、x64官方支持Windows 10x86、x64官方支持MacOSx64、ARM64官方支持Linux - 其他发行版x86、x64尽力支持LinuxARM64尽力支持iOS—尽力支持Android—尽力支持AIX—社区支持Asylo—社区支持FreeBSD—社区支持Fuchsia—社区支持NaCL—社区支持NetBSD—社区支持OpenBSD—社区支持Solaris—社区支持二、使用 Bazel 集成 gRPCBazel 是 gRPC 核心开发团队的主构建系统构建速度快且能轻松管理本身已支持 Bazel 的依赖。gRPC 的 MODULE.bazel 中声明了module(name grpc, version 1.84.0-dev, repo_name com_github_grpc_grpc)以及 abseil-cpp、protobuf、boringssl、c-ares、re2、zlib、opentelemetry-cpp 等一整套依赖消费者无需自行声明这些传递依赖。2.1 基于 bzlmod 的新式集成推荐如果你的工程使用 Bazel 7 及以上版本并开启 bzlmod默认开启在 Bazel Central Registry 上找到期望的 gRPC 版本后直接在工程的MODULE.bazel中加入一行bazel_dep即可bazel_dep(name grpc, version 1.72.0)bazel_dep会以模块形式拉取 gRPC并自动解析其声明的全部依赖。gRPC 在 MODULE.bazel 中不仅声明了bazel_dep还通过single_version_override、archive_override等方式对 zlib、re2、googleapis 等依赖做了版本钉扎与补丁例如 bazel/zlib/add_custom_build_file.patch保证构建可复现。2.2 基于旧版 WORKSPACE 文件的集成对于仍使用传统 Bazel WORKSPACE 文件构建的项目接入步骤如下确定要使用的 gRPC 发布版本对应的 commit SHA使用http_archive规则引入 gRPC 源码依次调用grpc_deps()与grpc_extra_deps()加载其依赖。http_archive( name com_github_grpc_grpc, urls [ https://github.com/grpc/grpc/archive/YOUR_GRPC_COMMIT_SHA.tar.gz, ], strip_prefix grpc-YOUR_GRPC_COMMIT_SHA, ) load(com_github_grpc_grpc//bazel:grpc_deps.bzl, grpc_deps) grpc_deps() load(com_github_grpc_grpc//bazel:grpc_extra_deps.bzl, grpc_extra_deps) grpc_extra_deps()仓库自身的 WORKSPACE 就是这一模式的真实范例它以workspace(name com_github_grpc_grpc)声明工作区名调用 bazel/grpc_deps.bzl 中的grpc_deps()与grpc_extra_deps()加载 boringssl、protobuf、googletest、abseil、c-ares、re2 等外部仓库并通过python_register_toolchains、pip_parse等配置 Python 相关依赖。grpc_deps()中对每个依赖都做了native.existing_rules()检查避免与消费者已有的同名仓库冲突。注意当你在自己的工程中使用http_archive引入 gRPC 时grpc_deps()会自动加载其依赖如果使用 bzlmod 方式依赖由模块解析自动完成无需手动调用上述宏。三、使用 CMake 集成 gRPC如果无法使用 BazelCMake 是最佳选择。CMake 官方支持 Linux、MacOS、Windows在其他平台上也有较大成功概率但不作承诺同时 CMake 对交叉编译支持良好可用于以 Android 为目标平台构建。3.1 统一 C 标准版本重要前提从 gRPC C 1.70 起构建至少需要 C17。为确保项目中所有库以相同的 C 版本编译应显式指定标准set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON)CMAKE_CXX_STANDARD_REQUIRED ON会强制所有目标使用 C17避免因不同 C 版本混用引发的不一致或错误。这一点很关键gRPC 的依赖 Abseil 会根据 C 版本提供不同 API例如absl::string_view在 C17 前后的实现不同BUILDING.md 中对此有明确说明。3.2 find_package发现已安装的 gRPCCMake 发现依赖的规范方式是find_package命令。gRPC 的 CMake 安装会生成gRPCConfig.cmake模板见 cmake/gRPCConfig.cmake.in其中通过find_dependency串联 zlib、protobuf、ssl、c-ares、absl、re2、opentelemetry 等依赖并引入gRPCTargets.cmake暴露gRPC::grpc等导入目标find_package(gRPC CONFIG REQUIRED) add_executable(my_exe my_exe.cc) target_link_libraries(my_exe gRPC::grpc)完整示例见 examples/cpp/helloworld/CMakeLists.txt。注意find_package只能找到已经安装到系统的软件。也就是说你需要先用 CMake 安装 gRPC 一次。gRPC 的 CMake 支持将安装目标指定为系统全局不推荐或某个目录前缀后者可以很方便地在后续工程中通过find_package(gRPC CONFIG REQUIRED)使用。下面几个小节介绍把 gRPC 构建集成进自己工程的其他策略。3.3 FetchContent随工程自动构建 gRPC如果使用 CMake v3.11 或更新版本推荐使用FetchContent模块。首次在某个构建目录运行 CMake 时FetchContent 会克隆 gRPC 仓库及其子模块FetchContent_MakeAvailable()会为你自动建立add_subdirectory()规则从而把 gRPC 作为工程的一部分一同构建cmake_minimum_required(VERSION 3.22) project(my_project) include(FetchContent) FetchContent_Declare( gRPC GIT_REPOSITORY https://github.com/grpc/grpc GIT_TAG RELEASE_TAG_HERE # e.g v1.28.0 ) set(FETCHCONTENT_QUIET OFF) FetchContent_MakeAvailable(gRPC) add_executable(my_exe my_exe.cc) target_link_libraries(my_exe grpc)注意构建 gRPC 之前需要先按 BUILDING.md 的 Pre-requisites 一节安装前置依赖Linux 下为build-essential autoconf libtool pkg-configCMake 构建还需cmake。3.4 git submodule将 gRPC 源码树加入工程如果无法使用 FetchContent另一种方式是先把 gRPC 源码树作为 git submodule 加入你的工程然后用add_subdirectory()引入add_subdirectory(grpc) # grpc 为 submodule 所在目录具体可参考 examples/cpp/helloworld/CMakeLists.txt 中include(../cmake/common.cmake)之后的构建流程它通过_PROTOBUF_PROTOC与_GRPC_CPP_PLUGIN_EXECUTABLE调用protoc和grpc_cpp_plugin生成helloworld.pb.cc、helloworld.grpc.pb.cc等代码再编译链接为greeter_client、greeter_server、greeter_callback_client、greeter_async_server等可执行目标。3.5 支持用户使用系统已安装的 gRPC即使你的工程默认自建 gRPC也应考虑用户想用系统里已安装的 gRPC 来构建你的软件的情形。这是典型做法option(USE_SYSTEM_GRPC Use system installed gRPC OFF) if(USE_SYSTEM_GRPC) # Find system-installed gRPC find_package(gRPC CONFIG REQUIRED) else() # Build gRPC using FetchContent or add_subdirectory endif()通过USE_SYSTEM_GRPC开关一个工程可以同时支持自建依赖与复用系统安装两种构建路径完整示例同样见 examples/cpp/helloworld/CMakeLists.txt。四、使用 pkg-config 集成非 CMake 工程如果工程不使用 CMake例如直接使用make可以先通过 CMake 安装 gRPC C然后让非 CMake 工程依赖 gRPC 安装时提供的pkgconfig文件。gRPC 的安装会生成grpc.pc、grpc.pc等 pkg-config 描述文件其内容模板见 cmake/pkg-config-template.pc.in包含prefix、includedir、libdir、Cflags、Requires、Libs等标准字段其中Requires.private/Libs.private记录了静态链接所需的传递依赖。仓库的发布验证脚本 test/distrib/cpp/run_distrib_test_cmake_pkgconfig.sh 完整展示了这一工作流先分别用 CMake 安装 abseil、c-ares、protobuf、re2、zlib、OpenTelemetry再以-DgRPC_INSTALLON -DCMAKE_INSTALL_PREFIX/usr/local/grpc及各gRPC_*_PROVIDERpackage安装 gRPC随后设置export PKG_CONFIG_PATH/usr/local/grpc/lib/pkgconfig export PATH$PATH:/usr/local/grpc/bin pkg-config --cflags grpc pkg-config --libs --static grpc pkg-config --cflags grpc pkg-config --libs --static grpc最后在 examples/cpp/helloworld/Makefile 中通过pkg-config --cflags protobuf grpc absl_flags absl_flags_parse与pkg-config --libs --static protobuf grpc ...取得编译与链接参数来构建示例。该 Makefile 同时验证了系统必须具备protoc3.0.0 或更新与grpc_cpp_plugin否则system-check会失败并给出提示。CentOS 7 用户注意CentOS 7 自带的pkg-config是 0.27.1存在一个会导致调用耗时极长的 bug。如果打算使用 pkg-config需要先升级到更新版本。五、make 构建已弃用make曾是 UNIX 系统上的默认构建选择但现已不再被推荐应改用bazel或cmake。如需使用make安装 gRPC C请按照 BUILDING.md 的说明从源码构建然后本地执行make install。该过程也会安装 protocol buffer 编译器protoc若系统尚无以及protoc的 C gRPC 插件。警告使用make install安装后没有简便的卸载方式如果之后想移除 grpc/protobuf 安装或升级到更新版本会带来麻烦。仓库根目录的 Makefile 目前仅面向内部使用不供外部消费。六、通过包管理器安装社区维护gRPC 官方不正式支持任何 C 包管理系统但存在一些由社区维护、持续更新且运行良好的包。其中较为知名的是vcpkg# 按官方说明在你的系统上安装 vcpkg 包管理器 git clone https://github.com/Microsoft/vcpkg.git cd vcpkg # Linux 上引导 ./bootstrap-vcpkg.sh # Windows 上则改用 # ./bootstrap-vcpkg.bat ./vcpkg integrate install # 使用 vcpkg 包管理器安装 gRPC ./vcpkg install grpcvcpkg 中的 gRPC port 由微软团队成员与社区贡献者持续维护若版本过旧可到 vcpkg 仓库提交 issue 或 pull request。欢迎社区为更多流行包管理系统提供贡献与支持。七、示例与更多文档构建并运行最简 gRPC C 示例Hello World的方法见 examples/cpp 目录其中helloworld子目录同时提供了 CMakeLists.txt、Makefile 与 BUILD 三种构建入口greeter_server.cc展示了ServerBuilder、RegisterService、BuildAndStart、Wait的典型服务端写法完整的 C 使用文档可参考 gRPC 主文档站点具体包括Overview以各语言 Hello World 示例引入 gRPC含 CgRPC Basics - C逐步创建一个简单 gRPC C 应用Route Guide 教程对应 examples/cpp/route_guideAsynchronous Basics - C讲解 gRPC C 异步/非阻塞 API 的使用。八、从源码开发与构建 gRPC C 本身如果你要为 gRPC C 贡献代码或属于高级用户需要从源码构建 gRPC 本身详细步骤见 BUILDING.md。这里提炼几个关键点8.1 前置依赖以 Linux 为例$ [sudo] apt-get install build-essential autoconf libtool pkg-config # 若计划用 CMake 构建 $ [sudo] apt-get install cmake # 贡献者构建并运行测试时clang 与 LLVM C 库仅 sanitizer 构建需要 $ [sudo] apt-get install clang libc-devMacOS 需要先安装 Xcode 或 Command Line Toolsxcode-select --install再通过 Homebrew 安装autoconf automake libtool shtoolWindows 上需要 Visual Studio 2022 或更新、Git、CMake以及 boringssl 所要求的 nasmchoco install nasm需加入 PATH可选安装 Ninja。克隆仓库时须使用--recursive或git submodule update --init下载依赖子模块Bazel 构建不依赖子模块其依赖模型不同。8.2 用 Bazel 构建推荐# 构建 gRPC C $ bazel build :all # 运行全部 C/C 测试 $ bazel test --configdbg //test/...注意若使用 Bazel 7 或更新版本由于 gRPC 尚未与 bzlmod 完全兼容构建时需要加--enable_bzlmodfalse关闭 bzlmod。8.3 用 CMake 构建Linux/UnixMake 生成器$ mkdir -p cmake/build $ cd cmake/build $ cmake -DCMAKE_CXX_STANDARD17 ../.. $ makeWindowsVisual Studio 2022 md .build cd .build cmake -G Visual Studio 17 2022 -DCMAKE_CXX_STANDARD17 .. cmake --build . --config ReleaseWindowsNinja构建更快仍需 Visual C cd cmake md build cd build call %VS170COMNTOOLS%..\..\VC\Auxiliary\Build\vcvarsall.bat x64 cmake -GNinja -DCMAKE_BUILD_TYPERelease -DCMAKE_CXX_STANDARD17 ..\.. cmake --build .如需构建共享库.so/ DLL追加-DBUILD_SHARED_LIBSON。Windows 的 DLL 构建为尽力支持级别C DLL 没有稳定 ABI跨 DLL 分配/释放内存不安全官方不推荐也不提供大量测试。8.4 依赖管理gRPC_ _PROVIDERgRPC 的 CMake 构建通过gRPC_depname_PROVIDER变量如gRPC_CARES_PROVIDER控制依赖来源取值有两种module随 gRPC 一起构建依赖源码来自 gRPC 的 git submodulespackage使用系统上已有的外部依赖副本来自系统包管理器或你先前用CMAKE_INSTALL_PREFIX通过 CMake 安装的。例如设置gRPC_CARES_PROVIDERmoduleCMake 会在构建 gRPC 前先构建 c-ares设置gRPC_CARES_PROVIDERpackage则会搜索系统已安装的 c-ares 来构建 gRPC。常见的依赖包括gRPC_ABSL_PROVIDER、gRPC_PROTOBUF_PROVIDER、gRPC_RE2_PROVIDER、gRPC_SSL_PROVIDER、gRPC_ZLIB_PROVIDER等。8.5 构建后安装设置-DgRPC_INSTALLON构建install目标。安装位置由CMAKE_INSTALL_PREFIX控制。CMake v3.13 可以按 module 模式构建依赖并同 gRPC 一起单步安装gRPC 1.27 或 CMake 3.13 时依赖需选 package 模式即系统上须先有这些库参考 run_distrib_test_cmake.sh。典型安装命令$ cmake ../.. -DgRPC_INSTALLON \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_CXX_STANDARD17 \ -DgRPC_ABSL_PROVIDERpackage \ -DgRPC_CARES_PROVIDERpackage \ -DgRPC_PROTOBUF_PROVIDERpackage \ -DgRPC_RE2_PROVIDERpackage \ -DgRPC_SSL_PROVIDERpackage \ -DgRPC_ZLIB_PROVIDERpackage $ make $ make install8.6 交叉编译使用 CMake 为其他架构交叉编译时需要先为主机构架构建protoc和grpc_cpp_plugin构建 gRPC 的过程中会用到这两个本机可执行文件再通过CMAKE_TOOLCHAIN_FILE指定工具链文件$ cmake ../.. -DCMAKE_TOOLCHAIN_FILEpath/to/file $ make仓库提供了 run_distrib_test_cmake_aarch64_cross.sh 交叉编译示例。8.7 关于 SONAME 与 ABI 兼容CMake 构建会在 ABI 破坏时尽量提升 SONAME revision。虽然 SONAME 变化明确表示 ABI 不兼容但官方不保证相同 SONAME 版本内存在任何形式的 ABI 稳定性——升级 gRPC 后应重新编译依赖它的二进制。总结将 gRPC C 接入工程的核心决策点是构建系统现代 Bazel 工程优先走bazel_dep(name grpc, ...)的 bzlmod 路径旧工程可用http_archivegrpc_deps()/grpc_extra_deps()CMake 工程则根据是否允许自建依赖在find_package、FetchContent、git submodule 与USE_SYSTEM_GRPC开关之间选择非 CMake 工程可复用安装时生成的 pkg-config 文件已弃用的make与社区维护的 vcpkg 则作为补充选项。无论选择哪条路径都要保证工程统一使用 C17 及以上标准并理解 gRPC 对 Abseil、protobuf、c-ares、re2、SSL、zlib 等依赖的管理方式——这正是 src/cpp/README.md 与 BUILDING.md 为使用者勾勒出的完整接入地图。【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gRPC C++ 依赖接入与构建全指南：Bazel、CMake、pkg-config 三种集成路径详解
gRPC C 依赖接入与构建全指南Bazel、CMake、pkg-config 三种集成路径详解【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc导读src/cpp/README.md是 gRPC 仓库中面向 C 使用者的第一入口文档系统介绍了如何把 gRPC C 作为依赖接入自己的工程以及 gRPC C 源码本身的构建方式。本文以该文档为骨架结合仓库中的 MODULE.bazel、WORKSPACE、BUILDING.md、helloworld 示例 等真实配置与源码完整梳理官方支持的平台矩阵、Bazelbzlmod 与旧版 WORKSPACE 两种模式、CMakefind_package / FetchContent / git submodule / 系统已安装 gRPC、pkg-config、make已弃用以及 vcpkg 等全部接入方式并补充了 C17 一致性、依赖 Provider 策略、安装与交叉编译等实战细节。读完本文你将能够针对自己的构建环境选择并落地一条可复现、可维护的 gRPC C 集成方案。src/cpp/目录下存放的是 gRPC 的 C 实现包含grpc/grpcpp的 C API 封装与上层代码。由于 C 生态中不存在公认统一的依赖管理标准gRPC 同时支持多种主流构建系统以满足绝大多数使用场景这正是本文要逐一展开的内容。一、支持的平台与支持级别gRPC C 官方将平台支持划分为三个级别使用者在选型前应先确认自己目标平台的归属官方支持Officially Supported遵循 OSS Foundational C Support Policy 选定官方在这些平台上运行自动化持续集成CI测试问题会被优先修复。尽力支持Best Effort没有 CI 测试覆盖但官方对在这些平台上运行有较高信心会尽力维护并欢迎补丁个别问题可能无法解决。社区支持Community Supported完全由开源社区贡献者维护没有官方支持承诺损坏可能长期无人察觉维护责任在社区长期无人维护的代码可能被删除。操作系统架构支持级别Linux - Debian、Ubuntu、CentOSx86、x64官方支持Windows 10x86、x64官方支持MacOSx64、ARM64官方支持Linux - 其他发行版x86、x64尽力支持LinuxARM64尽力支持iOS—尽力支持Android—尽力支持AIX—社区支持Asylo—社区支持FreeBSD—社区支持Fuchsia—社区支持NaCL—社区支持NetBSD—社区支持OpenBSD—社区支持Solaris—社区支持二、使用 Bazel 集成 gRPCBazel 是 gRPC 核心开发团队的主构建系统构建速度快且能轻松管理本身已支持 Bazel 的依赖。gRPC 的 MODULE.bazel 中声明了module(name grpc, version 1.84.0-dev, repo_name com_github_grpc_grpc)以及 abseil-cpp、protobuf、boringssl、c-ares、re2、zlib、opentelemetry-cpp 等一整套依赖消费者无需自行声明这些传递依赖。2.1 基于 bzlmod 的新式集成推荐如果你的工程使用 Bazel 7 及以上版本并开启 bzlmod默认开启在 Bazel Central Registry 上找到期望的 gRPC 版本后直接在工程的MODULE.bazel中加入一行bazel_dep即可bazel_dep(name grpc, version 1.72.0)bazel_dep会以模块形式拉取 gRPC并自动解析其声明的全部依赖。gRPC 在 MODULE.bazel 中不仅声明了bazel_dep还通过single_version_override、archive_override等方式对 zlib、re2、googleapis 等依赖做了版本钉扎与补丁例如 bazel/zlib/add_custom_build_file.patch保证构建可复现。2.2 基于旧版 WORKSPACE 文件的集成对于仍使用传统 Bazel WORKSPACE 文件构建的项目接入步骤如下确定要使用的 gRPC 发布版本对应的 commit SHA使用http_archive规则引入 gRPC 源码依次调用grpc_deps()与grpc_extra_deps()加载其依赖。http_archive( name com_github_grpc_grpc, urls [ https://github.com/grpc/grpc/archive/YOUR_GRPC_COMMIT_SHA.tar.gz, ], strip_prefix grpc-YOUR_GRPC_COMMIT_SHA, ) load(com_github_grpc_grpc//bazel:grpc_deps.bzl, grpc_deps) grpc_deps() load(com_github_grpc_grpc//bazel:grpc_extra_deps.bzl, grpc_extra_deps) grpc_extra_deps()仓库自身的 WORKSPACE 就是这一模式的真实范例它以workspace(name com_github_grpc_grpc)声明工作区名调用 bazel/grpc_deps.bzl 中的grpc_deps()与grpc_extra_deps()加载 boringssl、protobuf、googletest、abseil、c-ares、re2 等外部仓库并通过python_register_toolchains、pip_parse等配置 Python 相关依赖。grpc_deps()中对每个依赖都做了native.existing_rules()检查避免与消费者已有的同名仓库冲突。注意当你在自己的工程中使用http_archive引入 gRPC 时grpc_deps()会自动加载其依赖如果使用 bzlmod 方式依赖由模块解析自动完成无需手动调用上述宏。三、使用 CMake 集成 gRPC如果无法使用 BazelCMake 是最佳选择。CMake 官方支持 Linux、MacOS、Windows在其他平台上也有较大成功概率但不作承诺同时 CMake 对交叉编译支持良好可用于以 Android 为目标平台构建。3.1 统一 C 标准版本重要前提从 gRPC C 1.70 起构建至少需要 C17。为确保项目中所有库以相同的 C 版本编译应显式指定标准set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON)CMAKE_CXX_STANDARD_REQUIRED ON会强制所有目标使用 C17避免因不同 C 版本混用引发的不一致或错误。这一点很关键gRPC 的依赖 Abseil 会根据 C 版本提供不同 API例如absl::string_view在 C17 前后的实现不同BUILDING.md 中对此有明确说明。3.2 find_package发现已安装的 gRPCCMake 发现依赖的规范方式是find_package命令。gRPC 的 CMake 安装会生成gRPCConfig.cmake模板见 cmake/gRPCConfig.cmake.in其中通过find_dependency串联 zlib、protobuf、ssl、c-ares、absl、re2、opentelemetry 等依赖并引入gRPCTargets.cmake暴露gRPC::grpc等导入目标find_package(gRPC CONFIG REQUIRED) add_executable(my_exe my_exe.cc) target_link_libraries(my_exe gRPC::grpc)完整示例见 examples/cpp/helloworld/CMakeLists.txt。注意find_package只能找到已经安装到系统的软件。也就是说你需要先用 CMake 安装 gRPC 一次。gRPC 的 CMake 支持将安装目标指定为系统全局不推荐或某个目录前缀后者可以很方便地在后续工程中通过find_package(gRPC CONFIG REQUIRED)使用。下面几个小节介绍把 gRPC 构建集成进自己工程的其他策略。3.3 FetchContent随工程自动构建 gRPC如果使用 CMake v3.11 或更新版本推荐使用FetchContent模块。首次在某个构建目录运行 CMake 时FetchContent 会克隆 gRPC 仓库及其子模块FetchContent_MakeAvailable()会为你自动建立add_subdirectory()规则从而把 gRPC 作为工程的一部分一同构建cmake_minimum_required(VERSION 3.22) project(my_project) include(FetchContent) FetchContent_Declare( gRPC GIT_REPOSITORY https://github.com/grpc/grpc GIT_TAG RELEASE_TAG_HERE # e.g v1.28.0 ) set(FETCHCONTENT_QUIET OFF) FetchContent_MakeAvailable(gRPC) add_executable(my_exe my_exe.cc) target_link_libraries(my_exe grpc)注意构建 gRPC 之前需要先按 BUILDING.md 的 Pre-requisites 一节安装前置依赖Linux 下为build-essential autoconf libtool pkg-configCMake 构建还需cmake。3.4 git submodule将 gRPC 源码树加入工程如果无法使用 FetchContent另一种方式是先把 gRPC 源码树作为 git submodule 加入你的工程然后用add_subdirectory()引入add_subdirectory(grpc) # grpc 为 submodule 所在目录具体可参考 examples/cpp/helloworld/CMakeLists.txt 中include(../cmake/common.cmake)之后的构建流程它通过_PROTOBUF_PROTOC与_GRPC_CPP_PLUGIN_EXECUTABLE调用protoc和grpc_cpp_plugin生成helloworld.pb.cc、helloworld.grpc.pb.cc等代码再编译链接为greeter_client、greeter_server、greeter_callback_client、greeter_async_server等可执行目标。3.5 支持用户使用系统已安装的 gRPC即使你的工程默认自建 gRPC也应考虑用户想用系统里已安装的 gRPC 来构建你的软件的情形。这是典型做法option(USE_SYSTEM_GRPC Use system installed gRPC OFF) if(USE_SYSTEM_GRPC) # Find system-installed gRPC find_package(gRPC CONFIG REQUIRED) else() # Build gRPC using FetchContent or add_subdirectory endif()通过USE_SYSTEM_GRPC开关一个工程可以同时支持自建依赖与复用系统安装两种构建路径完整示例同样见 examples/cpp/helloworld/CMakeLists.txt。四、使用 pkg-config 集成非 CMake 工程如果工程不使用 CMake例如直接使用make可以先通过 CMake 安装 gRPC C然后让非 CMake 工程依赖 gRPC 安装时提供的pkgconfig文件。gRPC 的安装会生成grpc.pc、grpc.pc等 pkg-config 描述文件其内容模板见 cmake/pkg-config-template.pc.in包含prefix、includedir、libdir、Cflags、Requires、Libs等标准字段其中Requires.private/Libs.private记录了静态链接所需的传递依赖。仓库的发布验证脚本 test/distrib/cpp/run_distrib_test_cmake_pkgconfig.sh 完整展示了这一工作流先分别用 CMake 安装 abseil、c-ares、protobuf、re2、zlib、OpenTelemetry再以-DgRPC_INSTALLON -DCMAKE_INSTALL_PREFIX/usr/local/grpc及各gRPC_*_PROVIDERpackage安装 gRPC随后设置export PKG_CONFIG_PATH/usr/local/grpc/lib/pkgconfig export PATH$PATH:/usr/local/grpc/bin pkg-config --cflags grpc pkg-config --libs --static grpc pkg-config --cflags grpc pkg-config --libs --static grpc最后在 examples/cpp/helloworld/Makefile 中通过pkg-config --cflags protobuf grpc absl_flags absl_flags_parse与pkg-config --libs --static protobuf grpc ...取得编译与链接参数来构建示例。该 Makefile 同时验证了系统必须具备protoc3.0.0 或更新与grpc_cpp_plugin否则system-check会失败并给出提示。CentOS 7 用户注意CentOS 7 自带的pkg-config是 0.27.1存在一个会导致调用耗时极长的 bug。如果打算使用 pkg-config需要先升级到更新版本。五、make 构建已弃用make曾是 UNIX 系统上的默认构建选择但现已不再被推荐应改用bazel或cmake。如需使用make安装 gRPC C请按照 BUILDING.md 的说明从源码构建然后本地执行make install。该过程也会安装 protocol buffer 编译器protoc若系统尚无以及protoc的 C gRPC 插件。警告使用make install安装后没有简便的卸载方式如果之后想移除 grpc/protobuf 安装或升级到更新版本会带来麻烦。仓库根目录的 Makefile 目前仅面向内部使用不供外部消费。六、通过包管理器安装社区维护gRPC 官方不正式支持任何 C 包管理系统但存在一些由社区维护、持续更新且运行良好的包。其中较为知名的是vcpkg# 按官方说明在你的系统上安装 vcpkg 包管理器 git clone https://github.com/Microsoft/vcpkg.git cd vcpkg # Linux 上引导 ./bootstrap-vcpkg.sh # Windows 上则改用 # ./bootstrap-vcpkg.bat ./vcpkg integrate install # 使用 vcpkg 包管理器安装 gRPC ./vcpkg install grpcvcpkg 中的 gRPC port 由微软团队成员与社区贡献者持续维护若版本过旧可到 vcpkg 仓库提交 issue 或 pull request。欢迎社区为更多流行包管理系统提供贡献与支持。七、示例与更多文档构建并运行最简 gRPC C 示例Hello World的方法见 examples/cpp 目录其中helloworld子目录同时提供了 CMakeLists.txt、Makefile 与 BUILD 三种构建入口greeter_server.cc展示了ServerBuilder、RegisterService、BuildAndStart、Wait的典型服务端写法完整的 C 使用文档可参考 gRPC 主文档站点具体包括Overview以各语言 Hello World 示例引入 gRPC含 CgRPC Basics - C逐步创建一个简单 gRPC C 应用Route Guide 教程对应 examples/cpp/route_guideAsynchronous Basics - C讲解 gRPC C 异步/非阻塞 API 的使用。八、从源码开发与构建 gRPC C 本身如果你要为 gRPC C 贡献代码或属于高级用户需要从源码构建 gRPC 本身详细步骤见 BUILDING.md。这里提炼几个关键点8.1 前置依赖以 Linux 为例$ [sudo] apt-get install build-essential autoconf libtool pkg-config # 若计划用 CMake 构建 $ [sudo] apt-get install cmake # 贡献者构建并运行测试时clang 与 LLVM C 库仅 sanitizer 构建需要 $ [sudo] apt-get install clang libc-devMacOS 需要先安装 Xcode 或 Command Line Toolsxcode-select --install再通过 Homebrew 安装autoconf automake libtool shtoolWindows 上需要 Visual Studio 2022 或更新、Git、CMake以及 boringssl 所要求的 nasmchoco install nasm需加入 PATH可选安装 Ninja。克隆仓库时须使用--recursive或git submodule update --init下载依赖子模块Bazel 构建不依赖子模块其依赖模型不同。8.2 用 Bazel 构建推荐# 构建 gRPC C $ bazel build :all # 运行全部 C/C 测试 $ bazel test --configdbg //test/...注意若使用 Bazel 7 或更新版本由于 gRPC 尚未与 bzlmod 完全兼容构建时需要加--enable_bzlmodfalse关闭 bzlmod。8.3 用 CMake 构建Linux/UnixMake 生成器$ mkdir -p cmake/build $ cd cmake/build $ cmake -DCMAKE_CXX_STANDARD17 ../.. $ makeWindowsVisual Studio 2022 md .build cd .build cmake -G Visual Studio 17 2022 -DCMAKE_CXX_STANDARD17 .. cmake --build . --config ReleaseWindowsNinja构建更快仍需 Visual C cd cmake md build cd build call %VS170COMNTOOLS%..\..\VC\Auxiliary\Build\vcvarsall.bat x64 cmake -GNinja -DCMAKE_BUILD_TYPERelease -DCMAKE_CXX_STANDARD17 ..\.. cmake --build .如需构建共享库.so/ DLL追加-DBUILD_SHARED_LIBSON。Windows 的 DLL 构建为尽力支持级别C DLL 没有稳定 ABI跨 DLL 分配/释放内存不安全官方不推荐也不提供大量测试。8.4 依赖管理gRPC_ _PROVIDERgRPC 的 CMake 构建通过gRPC_depname_PROVIDER变量如gRPC_CARES_PROVIDER控制依赖来源取值有两种module随 gRPC 一起构建依赖源码来自 gRPC 的 git submodulespackage使用系统上已有的外部依赖副本来自系统包管理器或你先前用CMAKE_INSTALL_PREFIX通过 CMake 安装的。例如设置gRPC_CARES_PROVIDERmoduleCMake 会在构建 gRPC 前先构建 c-ares设置gRPC_CARES_PROVIDERpackage则会搜索系统已安装的 c-ares 来构建 gRPC。常见的依赖包括gRPC_ABSL_PROVIDER、gRPC_PROTOBUF_PROVIDER、gRPC_RE2_PROVIDER、gRPC_SSL_PROVIDER、gRPC_ZLIB_PROVIDER等。8.5 构建后安装设置-DgRPC_INSTALLON构建install目标。安装位置由CMAKE_INSTALL_PREFIX控制。CMake v3.13 可以按 module 模式构建依赖并同 gRPC 一起单步安装gRPC 1.27 或 CMake 3.13 时依赖需选 package 模式即系统上须先有这些库参考 run_distrib_test_cmake.sh。典型安装命令$ cmake ../.. -DgRPC_INSTALLON \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_CXX_STANDARD17 \ -DgRPC_ABSL_PROVIDERpackage \ -DgRPC_CARES_PROVIDERpackage \ -DgRPC_PROTOBUF_PROVIDERpackage \ -DgRPC_RE2_PROVIDERpackage \ -DgRPC_SSL_PROVIDERpackage \ -DgRPC_ZLIB_PROVIDERpackage $ make $ make install8.6 交叉编译使用 CMake 为其他架构交叉编译时需要先为主机构架构建protoc和grpc_cpp_plugin构建 gRPC 的过程中会用到这两个本机可执行文件再通过CMAKE_TOOLCHAIN_FILE指定工具链文件$ cmake ../.. -DCMAKE_TOOLCHAIN_FILEpath/to/file $ make仓库提供了 run_distrib_test_cmake_aarch64_cross.sh 交叉编译示例。8.7 关于 SONAME 与 ABI 兼容CMake 构建会在 ABI 破坏时尽量提升 SONAME revision。虽然 SONAME 变化明确表示 ABI 不兼容但官方不保证相同 SONAME 版本内存在任何形式的 ABI 稳定性——升级 gRPC 后应重新编译依赖它的二进制。总结将 gRPC C 接入工程的核心决策点是构建系统现代 Bazel 工程优先走bazel_dep(name grpc, ...)的 bzlmod 路径旧工程可用http_archivegrpc_deps()/grpc_extra_deps()CMake 工程则根据是否允许自建依赖在find_package、FetchContent、git submodule 与USE_SYSTEM_GRPC开关之间选择非 CMake 工程可复用安装时生成的 pkg-config 文件已弃用的make与社区维护的 vcpkg 则作为补充选项。无论选择哪条路径都要保证工程统一使用 C17 及以上标准并理解 gRPC 对 Abseil、protobuf、c-ares、re2、SSL、zlib 等依赖的管理方式——这正是 src/cpp/README.md 与 BUILDING.md 为使用者勾勒出的完整接入地图。【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考