Repository navigation
Conversation
…probes) Toward shipping libcvc with the gRPC cross-node transport on every platform. Validate the CVC_ENABLE_GRPC build in CI first: - Linux: a libcvc-release-grpc lane (blocking) — proves the OPTIMIZED grpc build (the config publish ships), alongside the existing debug-grpc surface check. - macOS + Windows: libcvc-release-grpc PROBE lanes, marked experimental so continue-on-error makes them non-blocking — they report whether grpc builds there (never attempted) without blocking the PR. Each provisions shared grpc+protobuf via cvcpkg (shared grpc is published for all three platforms) and configures -DCVC_ENABLE_GRPC=ON. Once the macOS/Windows probes are green they get promoted to blocking and wired into publish; that, plus the static+shared libcvc link variants, are follow-ups.
mkdtemp(3) is POSIX-only and does not compile on MSVC (C3861), which broke the Windows grpc CI probe once the gRPC bundles linked cleanly. Replace it with a std::filesystem make_temp_dir in both grpc transport TLS test helpers. They stay gated behind CVC_DISTRIBUTED_STATE_TLS_TESTS (off on Windows), so only the compile needed fixing, not the openssl cert-minting path.
… probes The macOS/Windows grpc lanes are experimental "does libcvc build with CVC_ENABLE_GRPC" probes. Under the grpc config, cvcgl_* tests do not reach CTestTestfile on those two platforms (cvcGL still builds; the Linux grpc lane is unaffected and keeps enforcing the guard, and the non-grpc release lanes enforce it on macOS/Windows). Gate the guard to skip the enable_grpc probe so it reports the grpc build result instead of a cvcGL test-registration quirk.
Mirror the shared grpc probes with a static-link variant: install the grpc closure via 'cvcpkg --link static' and link it into libcvc, catching a static-only grpc break. A new grpc_link matrix var drives the provision step (defaults to shared, so existing lanes are unchanged); package-linux gains the continue-on-error wiring macos/windows already had, so the new probe is non-blocking while proven out. The macOS static grpc lane follows once its static closure is published (only linux/windows static closures exist today).
macOS static grpc closure is now published (grpc 1.68.2+cvc.5 static, resolving cleanly via the build-tool-clash fix cy-pca/cvcpkg#355 that leaves the un-static-able macOS cmake out of the prefix). Add the macOS libcvc-release-grpc-static probe to match Linux and Windows; the macOS provision step is already grpc_link-parameterized, so this is just the matrix entry. experimental -> continue-on-error, as the other grpc probes.
…probe The macOS grpc probe links grpc's shared libs from a separate $GRPC_PREFIX. gtest_discover_tests runs each test executable to enumerate its tests, so without libgrpc++.dylib on the dyld path the launch failed -- surfacing as 'cvcgl_* tests registered: 0' and then GoogleTestAddTests 'Error running test executable' (ctest exit 8). Export DYLD_FALLBACK_LIBRARY_PATH to include $GRPC_PREFIX/lib before ctest. Harmless on the static lane (its prefix holds .a, not dylibs).
The grpc probes are green on Linux (debug/release/static) and Windows (release/static) on every run since the MSVC-skew bundle rebuild, the mkdtemp test fix and the static-link fixes. Drop experimental->continue-on-error from the Linux static and Windows shared+static grpc lanes so a grpc regression now fails CI. macOS grpc lanes stay experimental: the hosted macOS runners are too scarce to make a grpc lane blocking (the whole macOS job set has queued for hours) and the macOS probes have not run green since the dylib fix. Promote them once macOS CI is reliable and confirmed green.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Step 1 of shipping libcvc with the gRPC cross-node transport on every platform (the conference server/host needs it). Validate the
CVC_ENABLE_GRPCbuild in CI before touching publish.Today gRPC is only built in one lane:
libcvc-debug-grpc(Linux, Debug, excluded from the coverage gate). The shipped cvcpkg libcvc is gRPC-off, and macOS/Windows have never built gRPC.This PR
libcvc-release-grpc(blocking): proves the optimized grpc build — the config publish will ship — alongside the existing Debug surface check.libcvc-release-grpc(non-blocking probes):experimental: true→continue-on-error, so they report whether grpc compiles there without blocking the PR. Each provisions shared grpc+protobuf via cvcpkg (shared grpc is published for all three platforms — confirmed) and configures-DCVC_ENABLE_GRPC=ON.Why probes
I can't build macOS/Windows locally, so CI is the only way to find out if the transport code (and MSVC/clang) handle grpc. Non-blocking keeps the pipeline green while we learn; the mac/Windows results drive the next steps.
Plan (follow-ups)
publish-cvcpkg.ymlto build libcvc grpc-on + declare the grpc deps.libcvc.aresolves grpc at the consumer against shared grpc, so no static-grpc dep builds are required.Not auto-merged: I want to read the macOS/Windows probe results first.