Add Google Cloud SDK dependency and build scripts.

[mzient]

Adds the Google Cloud Storage (GCS) C++ client and its transitive dependencies, mirroring the
existing AWS SDK dependency so DALI can add a GCS reader alongside the S3 one.

What's added

• google-cloud-cpp (3.8.0) - only the storage component is requested
  (GOOGLE_CLOUD_CPP_ENABLE=storage), but that transitively pulls in monitoring, trace,
  opentelemetry and universe_domain regardless (verified: trying to drop them fails to build,
  not just configure - see build_google-cloud-cpp.sh). That's where gRPC and
  opentelemetry-cpp come from, even though the GCS client itself only talks REST.
• gRPC (1.83.1) - required transitively as above; reuses this repo's existing protobuf, Abseil,
  zlib and OpenSSL instead of building its own copies.
• opentelemetry-cpp (1.24.0) - API + SDK only, no exporters (OTLP/Zipkin/Prometheus) since
  nothing here uses them.
• nlohmann_json (3.12.0) - header-only, used by the GCS client to parse JSON API responses.
• generate_toolchain_file.sh - the CMake toolchain-file generation shared by
  build_grpc.sh/build_google-cloud-cpp.sh/build_opentelemetry-cpp.sh/build_nlohmann_json.sh/
  build_curl.sh, factored out instead of duplicated per script.
• build_openssl.sh/build_curl.sh - OpenSSL and libcurl are now built once into the shared
  install prefix and reused by both aws-sdk-cpp and google-cloud-cpp, instead of
  build_aws-sdk-cpp.sh building its own private static copies of both (which just duplicated
  the work).

Key decisions

• google-cloud-cpp is built shared, unlike everything else here. libdali.so and
  libdali_operators.so both use the GCS client; a gcs::Client constructed by one and used by
  the other has to be the same object in memory, which only holds if there is a single copy of
  the library in the process. Built statically, each .so would get its own private copy and
  passing a client across that boundary would crash. This mirrors how the AWS SDK is already
  handled (libaws-cpp-sdk-{core,s3}.so, static C runtime libs underneath). gRPC, protobuf,
  Abseil, opentelemetry-cpp, curl and OpenSSL stay static, linked into the three shared objects
  this produces (libgoogle_cloud_cpp_{storage,rest_internal,common}.so).
• -DGOOGLE_CLOUD_CPP_WITH_MOCKS=OFF drops googletest/benchmark from this dependency set
  entirely - they were only pulled in because mocks are on by default whenever BUILD_TESTING=OFF
  (which is this build's configuration). Verified with a from-scratch build: default flags fail
  configure with "Could NOT find GTest"; this flag configures and builds cleanly without it.
• GOOGLE_CLOUD_CPP_OVERRIDE_GOOGLEAPIS_URL is forwarded from the environment to the CMake
  invocation. google-cloud-cpp is otherwise the only dependency in this repo that reaches the
  network at build time (everything else is a pinned, checksummed submodule/tarball); this lets a
  network-isolated builder point it at a local copy instead.

Testing

Built from scratch (x86_64) and linked into DALI to exercise the new GCS reader (DALI-side PR to
follow). The -DGOOGLE_CLOUD_CPP_WITH_MOCKS=OFF and shared-library reasoning above were each
verified directly (see the inline review discussion for the specific build failures reproduced).

[Copilot]

🟡 Changes recommended

Fix compiler detection in generate_toolchain_file.sh so absolute host compiler paths are not misclassified as cross-compilation.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds Google Cloud Storage C++ dependencies and build orchestration, including shared OpenSSL/cURL reuse with the AWS SDK.

Changes:

• Adds Google Cloud, gRPC, OpenTelemetry, and nlohmann_json dependencies.
• Adds dependency build scripts and shared toolchain generation.
• Refactors AWS builds to reuse shared OpenSSL/cURL installations.

File summaries

File	Summary
README.rst	Documents new dependencies.
CLAUDE.md	Documents GCS build requirements.
build_scripts/generate_toolchain_file.sh	Centralizes CMake toolchain generation.
build_scripts/build_opentelemetry-cpp.sh	Builds OpenTelemetry.
build_scripts/build_openssl.sh	Builds shared-prefix OpenSSL.
build_scripts/build_nlohmann_json.sh	Installs nlohmann_json.
build_scripts/build_grpc.sh	Builds gRPC.
build_scripts/build_google-cloud-cpp.sh	Builds the Google Cloud C++ client.
build_scripts/build_deps.sh	Updates dependency ordering.
build_scripts/build_curl.sh	Builds shared-prefix cURL.
build_scripts/build_aws-sdk-cpp.sh	Reuses shared dependencies.
.gitmodules	Registers new submodules.

Review details

• Files reviewed: 16/16 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge, with no new actionable findings and the prior compiler-detection thread manually resolved.

Summary

This PR adds the Google Cloud Storage C++ client and its required dependency chain to the DALI dependency build.

• Adds pinned submodules and build scripts for google-cloud-cpp, gRPC, OpenTelemetry C++, and nlohmann_json.
• Extracts reusable OpenSSL, curl, and CMake toolchain setup into shared build steps.
• Updates AWS SDK builds to consume OpenSSL and curl from the common installation prefix.
• Handles host tools during cross-compilation and installs the Google Cloud libraries as shared objects.
• Documents dependency versions and non-obvious Google Cloud build constraints.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  Build[build_deps.sh] --> Protobuf[protobuf and Abseil]
  Build --> OpenSSL[OpenSSL]
  OpenSSL --> Curl[libcurl]
  Protobuf --> GRPC[gRPC]
  OpenSSL --> GRPC
  Build --> JSON[nlohmann_json]
  Build --> OTel[opentelemetry-cpp]
  Curl --> AWS[AWS SDK shared libraries]
  OpenSSL --> AWS
  Curl --> GCS[google-cloud-cpp storage shared libraries]
  OpenSSL --> GCS
  GRPC --> GCS
  JSON --> GCS
  OTel --> GCS

Loading

_{Reviews (5) · Last reviewed commit: "Address review: self-contained cross-com..."}

[rostan-t]

Many comments have a lot of useful explanations but some are detailed enough that they starts to obscure the actual build scripts. Could we keep the important why close to the corresponding options and shorten the investigation/history details?

Some things like the dependency chain are already included in the PR description and others like the upstream CMake line numbers can be added there if really necessary.