gRPC C++ 如何在 Windows 10 上構建？

Question

我在嘗試使用 Visual Studio 2015 (C++) 和 cmake 在 Windows 10 上構建 gRPC 時遇到了麻煩。

我已經從 GitHub 下載並解壓了 grpc 及其所有 .gitmodules（以及它們的 .gitmodules 等），並將它們解壓到指定位置。 當我 cmake grpc 時，它會抱怨 cares/cares 中沒有 CMakeLists.txt。 grpc 的 .gitmodules 指定 cares-1_12_0，並且不包括 CMakeLists.txt 文件。 該怎么辦？ cares/cares 的主版本包含一個 CMakeLists.txt 文件，因此我將其復制到 -1_12_0 樹中。 現在它找到了 CMakeLists.txt，但隨后抱怨找不到其他文件。 如果我只使用 cares 的主版本而不是 1_12_0（希望現在已經修復了任何不兼容性），我不會再收到 cares 投訴。 我發現解決關心投訴的另一種方法是將 c-ares-master.zip 解壓縮到 grpc/third_part/cares/cares 中，然后將 c-ares-cares-1_12_0.zip 解壓縮到同一位置。 我認為這樣 c-ares-master.zip 將提供 c-ares-cares-1_12_0.zip 丟失的任何文件，並且 c-ares-cares-1_12_0.zip 將覆蓋任何具有相同名稱的文件 - 1_12_0 版本——但這是否是一個好習慣（在指定特定版本時復制主版本之上的特定分支）？ （我沒有使用 git 下載，因為它在此處不可用或未獲批准使用，因此我必須手動遍歷依賴項。）

下一個抱怨來自 protobuf 3.0.x：repeat_field_reflection.h not found，但這只是一個警告。

然后是從基准測試拋出的關於找不到 GTEST_LIBRARY、GTEST_INCLUDE_DIR 和 GTEST_MAIN_LIBRARY 的錯誤。

在嘗試構建 grpc 之前，我是否需要構建/安裝所有這些子模塊（自下而上）？ 不同模塊的構建過程（以及由此產生的構建目錄結構）之間的差異向我表明，這個問題的答案應該是“否”，但我不確定。 我知道 cmake 為從單個根 CMakeLists.txt 開始的源樹（通過所有第三方依賴項）遞歸構建提供支持（即，cmake 的單次執行應該構建所有內容），因此 cmake 的這種能力是有意義的要使用，並且依賴項的構建目錄結構應該一致。

我注意到 grpc 的 .gitmodules 需要 protobuf 3.0.x，但它也列出了 bloaty，而 bloaty 的 .gitmodules 需要 protobuf（大概是主版本）。 在 src 樹的不同部分使用不同版本的 protobuf（並構建兩個版本的 protobuf）會導致問題嗎？ 如果是這樣，當樹的不同部分需要同一模塊的不同版本時，我該怎么辦？

至少有 3 個地方需要 Googletest（grpc、bloaty、protobuf-master（bloaty 需要，但 protobuf-3.0.x 不需要，而 protobuf-3.0.x 是 grpc 直接需要的））。 我應該在哪里設置我的 GTEST_ROOT 指向，以及它如何與期望它位於自己的第三方分支下的某個模塊一起工作？ Googletest 構建完成后如何安裝？

cmake 查找所有（或許多）標准 C #include 文件的內容。 許多找到了，許多沒有找到（我是從 VS2015 x64 Native Tools Command Prompt 構建的，所以適用的 LIB 和 INCLUDE 路徑應該可用；我看過它們，它們看起來很合理。）。 如果它默認搜索所有這些，那么我猜沒有找到一些應該不是問題（如果它們沒有被 grpc 或其依賴項使用），所以我沒有追捕它們。 但是，沒有找到的是 pthread.h（我知道至少有一個模塊使用 pthread，但是 cmake 輸出的下一行是“Found Threads: TRUE”）。 另一個令人不安的發現是“--檢查 off64_t 的大小-失敗”（似乎這樣的值對於定義 protobuf 結構可能很重要。）CMake 還運行了許多測試。 有些成功了； 其他人沒有。 我是否應該關注測試失敗（哪些）？

我還注意到其中許多模塊 [幾乎] 每天都在更改，因此我突然想到，對 GitHub 存儲庫中主版本的依賴可能隨時中斷。 最近有人為 Windows 構建了 C++ gRPC 嗎？

任何幫助或建議將不勝感激。

Answer 1

無法直接向 roger 發表評論，因為我缺少所需的 karma 點，但我也能夠在 Windows 10 上遇到同樣的問題。這在 CMAKE 3.14 中工作，然后在 3.19 中被破壞，當我被迫更新我的Jenkins 服務器的另一個原因。

當我使用以下內容時（聯網，不是這個答案的首選，但為了安心而首選），它工作可靠； 如果您在構建機器上可以訪問網絡，請使用它。

# Builds gRPC based on GIT checked-out sources
ExternalProject_Add(grpc
  PREFIX grpc
  SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/path/to/grpc"
  CMAKE_CACHE_ARGS
        -DgRPC_INSTALL:BOOL=ON
        -DgRPC_BUILD_TESTS:BOOL=OFF
        -DgRPC_BUILD_GRPC_RUBY_PLUGIN:BOOL=OFF
        -DgRPC_PROTOBUF_PROVIDER:STRING=module
        -DgRPC_PROTOBUF_PACKAGE_TYPE:STRING=CONFIG
        -DgRPC_ZLIB_PROVIDER:STRING=module
        -DgRPC_CARES_PROVIDER:STRING=module
        -DgRPC_SSL_PROVIDER:STRING=module
        -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_CURRENT_BINARY_DIR}/grpc
  DEPENDS c-ares protobuf zlib
)

如果你不能這樣做，我不得不通過單獨構建每個組件，跟蹤它們的安裝位置，然后將它們作為參數添加到 ExternalProjectAdd...

# Builds c-ares project from the git submodule.
ExternalProject_Add(c-ares
  PREFIX c-ares
  SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/path/to/cares"
  CMAKE_CACHE_ARGS
        -DCARES_SHARED:BOOL=OFF
        -DCARES_STATIC:BOOL=ON
        -DCARES_STATIC_PIC:BOOL=ON
        -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_CURRENT_BINARY_DIR}/c-ares
)

# Builds protobuf project from the git submodule.
ExternalProject_Add(protobuf
  PREFIX protobuf
  SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/path/to/protobuf/cmake"
  CMAKE_CACHE_ARGS
        -Dprotobuf_BUILD_TESTS:BOOL=OFF
        -Dprotobuf_WITH_ZLIB:BOOL=OFF
        -Dprotobuf_MSVC_STATIC_RUNTIME:BOOL=OFF
        -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_CURRENT_BINARY_DIR}/protobuf
)

# Builds zlib project from the git submodule.
ExternalProject_Add(zlib
  PREFIX zlib
  SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/path/to/zlib"
  CMAKE_CACHE_ARGS
        -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_CURRENT_BINARY_DIR}/zlib
)

# the location where protobuf-config.cmake will be installed varies by platform

set(_FINDPACKAGE_PROTOBUF_CONFIG_DIR "${CMAKE_CURRENT_BINARY_DIR}/protobuf/cmake")

# if OPENSSL_ROOT_DIR is set, propagate that hint path to the external projects with OpenSSL dependency.
set(_CMAKE_ARGS_OPENSSL_ROOT_DIR "-DOPENSSL_ROOT_DIR:PATH=${OPENSSL_ROOT_DIR}")

# Builds gRPC based on locally checked-out sources and set arguments so that all the dependencies
# are correctly located.
ExternalProject_Add(grpc
  PREFIX grpc
  SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/path/to/grpc"
  CMAKE_CACHE_ARGS
        -DgRPC_INSTALL:BOOL=ON
        -DgRPC_BUILD_TESTS:BOOL=OFF
        -DgRPC_BUILD_GRPC_RUBY_PLUGIN:BOOL=OFF
        -DgRPC_PROTOBUF_PROVIDER:STRING=package
        -DgRPC_PROTOBUF_PACKAGE_TYPE:STRING=CONFIG
        -DProtobuf_DIR:PATH=${_FINDPACKAGE_PROTOBUF_CONFIG_DIR}
        -DgRPC_ZLIB_PROVIDER:STRING=package
        -DZLIB_ROOT:STRING=${CMAKE_CURRENT_BINARY_DIR}/zlib
        -DgRPC_CARES_PROVIDER:STRING=module
        -Dc-ares_DIR:PATH=${CMAKE_CURRENT_BINARY_DIR}/c-ares/lib/cmake/c-ares
        -DgRPC_SSL_PROVIDER:STRING=package
        ${_CMAKE_ARGS_OPENSSL_ROOT_DIR}
        -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_CURRENT_BINARY_DIR}/grpc
  DEPENDS c-ares protobuf zlib
)