Successor to #75, which closed with everything else done or overtaken.
All three platforms now build erpl-proto statically, link DuckDB statically, pass
the unit suite in CI, and ship in a release. Only Linux has ever talked to a
real SAP system.
What is and is not proven
| Evidence |
macOS |
Windows |
Proves |
| CI build + link + unit tests |
yes |
yes |
it compiles and the pure logic works |
--smoke |
yes |
yes |
the RFC backend and DuckDB load and are callable |
| erpl-proto conformance suite |
yes |
yes |
the wire codec, capture-driven |
| 13-stage live e2e |
no |
no |
it actually replicates from SAP |
The registered-server path — gateway registration, the RFC callback loop, the
BXML round trip — is the product, and none of the first three exercises it. A
hosted GitHub runner cannot reach the A4H trial, which is why this gap survived.
Why it is worth doing rather than assuming
Recent history on exactly these platforms:
- Windows was missing
WSAStartup entirely. It built cleanly and would then
have reported a healthy gateway as unreachable, sending people to inspect
firewalls.
GetCurrentProcessId and getpid needed platform headers MSVC did not get.- A stale runtime state file was never deleted on Windows, because the code held
the file open while removing it — legal on POSIX, refused there.
All three were compile-or-unit failures caught by CI. A wrong runtime
behaviour against a real gateway is the class CI cannot see.
What would close this
One manual live e2e per platform: point a real Mac and a real Windows box at an
SAP system, register, and run scripts/e2e.sh. Record which SAP release and
which erpl-rev version it was run against, so the claim has a date on it.
Cheaper alternatives if a manual run is impractical: expose an SAP system over a
tailnet so hosted runners can reach it (erpl_tunnel already does this), or a
self-hosted runner on each platform.
Until then, the release notes should keep saying what evidence stands behind each
platform rather than implying all three are equally proven — which they currently
do, and which should not be quietly dropped.
Successor to #75, which closed with everything else done or overtaken.
All three platforms now build erpl-proto statically, link DuckDB statically, pass
the unit suite in CI, and ship in a release. Only Linux has ever talked to a
real SAP system.
What is and is not proven
--smokeThe registered-server path — gateway registration, the RFC callback loop, the
BXML round trip — is the product, and none of the first three exercises it. A
hosted GitHub runner cannot reach the A4H trial, which is why this gap survived.
Why it is worth doing rather than assuming
Recent history on exactly these platforms:
WSAStartupentirely. It built cleanly and would thenhave reported a healthy gateway as unreachable, sending people to inspect
firewalls.
GetCurrentProcessIdandgetpidneeded platform headers MSVC did not get.the file open while removing it — legal on POSIX, refused there.
All three were compile-or-unit failures caught by CI. A wrong runtime
behaviour against a real gateway is the class CI cannot see.
What would close this
One manual live e2e per platform: point a real Mac and a real Windows box at an
SAP system, register, and run
scripts/e2e.sh. Record which SAP release andwhich erpl-rev version it was run against, so the claim has a date on it.
Cheaper alternatives if a manual run is impractical: expose an SAP system over a
tailnet so hosted runners can reach it (
erpl_tunnelalready does this), or aself-hosted runner on each platform.
Until then, the release notes should keep saying what evidence stands behind each
platform rather than implying all three are equally proven — which they currently
do, and which should not be quietly dropped.