feat(clients)+test(interop): C++ client + Java validation of the daemon (B7)
tests / build-and-test (push) Successful in 2m54s
tests / thread-sanitizer (push) Successful in 3m48s
tests / tshark-dissector (push) Successful in 2m24s
tests / secs4j-interop (push) Successful in 1m44s
tests / python-interop (push) Successful in 3m10s
tests / libfuzzer (push) Successful in 3m38s

B7 — the daemon's HSMS face under the Java reference: Dockerfile.server now
bakes secs_gemd alongside secs_server (grpc deps in both stages), and
secs4j_validate.sh gains TARGET=gemd to point the 55-check secs4java8 suite
at the daemon instead. Result: 55/55 green. With secsgem-py already
validating both faces, byte-identical GEM between secs_server and secs_gemd
is now proven by both reference implementations, not inferred from shared
code. CI runs the daemon target as an extra step (image layers shared).

Second client — clients/cpp: a header-only C++ twin of the Python client
over the same proto. eq.set("ChamberPressure", 2.5) with bare literals
(integral/floating dispatch avoids variant ambiguity), get/fire/alarm/
clear, control_state/request_control_state/health, on("START", fn) +
listen()/listen_async()/stop() with auto-CompleteCommand, SecsGemError
carrying the daemon's message. cpp_mini_tool (~30 lines) mirrors the
Python mini_tool. Tested end-to-end over real loopback TCP against the
service inside secs_gemd_tests — now 4 cases / 141 assertions — including
set/get round-trips, error text, alarm-by-name into the model, health,
and the full HCACK-4 command loop with parameters.

(Build note: two grpc-heavy TUs at -O3 OOM even at -j2 on Docker Desktop;
built -j1. Known environment limitation, roadmap-documented.)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
2026-06-10 23:37:14 +02:00
parent 4f3031aeb9
commit b30443089f
9 changed files with 515 additions and 13 deletions
+26
View File
@@ -0,0 +1,26 @@
# secsgem-client (C++)
The C++ twin of [clients/python](../python): a header-only client for the
`secs_gemd` daemon. Name-based, plain-typed, no SEMI knowledge required.
```cpp
#include "secsgem_client/equipment.hpp"
secsgem_client::Equipment eq("localhost:50051");
eq.set("ChamberPressure", 2.5); // host sees it on its next poll
eq.fire("ProcessStarted"); // S6F11, report auto-assembled
eq.alarm("chiller_temp_high"); // S5F1 set / eq.clear(...) clears
eq.on("START", [&](const secsgem_client::Command& cmd) {
run_recipe(cmd.params.at("PPID"));
eq.fire("ProcessStarted"); // the host's completion signal
});
eq.listen(); // or listen_async() + stop()
```
Errors throw `secsgem_client::SecsGemError` carrying the daemon's
explanation. Build: include this header, compile the generated
`equipment.pb.cc` / `equipment.grpc.pb.cc` from
[proto/secsgem/v1](../../proto/secsgem/v1/equipment.proto), link `grpc++`.
In this repo the `cpp_mini_tool` CMake target (built when grpc is present)
is the worked example; out of tree, copy its four-line target definition.