Move macOS and Windows onto erpl-proto too

[jrosskopf]

#70/#74 switched the Linux release arm to erpl-proto, statically linked. macOS and Windows still bundle the SAP NW RFC SDK. This is the plan to finish the job.

Where we actually stand

Worth stating plainly, because the gap is bigger than "flip two matrix entries":

• erpl-proto's CI is Ubuntu-only. scripts/check-cross-targets.sh exists but is not run in CI, and it is cargo check anyway — the shim has never been compiled for macOS or Windows, let alone linked or run.
• erpl-rev's CI covers Linux and Windows, both on the SDK. macOS is only built in the release workflow.
• Live SAP verification exists only on Linux, against the local A4H trial. GitHub-hosted macOS/Windows runners cannot reach it.

One thing is better than feared: the shim's dependency tree is just erpl-proto → erpl-proto-wire + serde. No TLS, no async runtime, no platform-specific crates. The portable surface is small.

Phase 0 — make erpl-proto build on those platforms (erpl-proto)

Nothing downstream is worth attempting until this is green.

1. Add macOS and Windows jobs to erpl-proto's CI: cargo build --release -p erpl-proto-nwrfc (both staticlib and cdylib) and cargo test --workspace.
2. Actually run scripts/check-cross-targets.sh in CI — today it never runs.
3. Record cargo rustc -- --print native-static-libs per platform. Linux prints -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc, all implicit, which is why Linux linked with no extra work. Windows will not be so kind, and Phase 1 needs this list rather than a guess.
4. Run tools/abi_probe.c and scripts/check-header-abi.sh / check-header-symbols.sh per platform. This is the highest-value check in the whole plan: it compares 96 sizes, offsets and constants against SAP's own header. It needs the SAP SDK headers on those runners, which the S3/OIDC path already used by erpl-rev can supply.

The specific thing to watch: erpl-proto's header defines SAP_UC as uint16_t unconditionally, while SAP's Windows header uses wchar_t. Both are 16-bit on Windows so it should agree — but "should" is exactly what the probe is for.

Phase 1 — link it (erpl-rev)

1. CMake: append the platform's native-static-libs to SAP_LIBS under RFC_LINK=static, taken from Phase 0's output. The archive is currently linked alone, which only works because Linux needs nothing extra.
2. Windows CRT: erpl-rev builds with vcpkg x64-windows-static-md (dynamic CRT) and Rust's MSVC target defaults to the dynamic CRT, so they should match. Verify rather than assume — a mismatch produces duplicate-symbol noise that is easy to misread.
3. Make the bundle assertion portable. ldd (Linux) / otool -L (macOS) / dumpbin /dependents (Windows), all asserting no sapnwrfc, sapucum or ICU. As written it would simply fail on macOS.
4. bundle.ps1 needs the equivalent of the - sentinel stage_runtime.sh already accepts, so the Windows payload can be duckdb.dll alone.
5. Flip rfc: proto for the osx and windows matrix entries and drop their SDK fetch and AWS steps, exactly as the Linux arm did.

Phase 2 — what evidence justifies shipping

This is the real decision, not the code.

Evidence	Proves	Available?
CI build + link + --smoke	it loads, one call works	yes, cheap
erpl-proto conformance suite per platform	the wire codec, capture-driven	yes, no SAP needed
ABI probe per platform	the C ABI matches SAP's header	yes, needs SDK headers
Live 13-stage e2e	it actually replicates from SAP	no — not from a hosted runner

The first three are necessary and not sufficient. The registered-server path — gateway registration, the RFC callback loop — is the product, and none of the three exercises it.

Options for the last row, in increasing order of effort: a self-hosted macOS runner; exposing the A4H trial over a tailnet so hosted runners can reach it (erpl_tunnel already does this trick); or one manual live run per platform on a real Mac and a real Windows box.

Recommendation: the first three as the CI gate, plus one manual live e2e per platform before flipping the release default. Shipping an RFC stack whose first contact with a real SAP system is a customer's is not a trade worth making for two platforms.

Phase 3 — release and bundles

Payloads become DuckDB alone on all three. Update the release-notes body, which currently states that macOS and Windows bundle the SDK. Keep the per-platform --smoke with no external libraries on the loader path.

Phase 4 — blog post

The published caveat is accurate today (Linux switched, macOS/Windows deliberately not). Once all three ship it needs a final pass: the SDK is gone everywhere, and it should say what evidence stands behind each platform rather than implying they are equally proven.

Rough effort

Phase 0 ~half a day, Phase 1 ~half a day, Phase 3/4 small. Phase 2 dominates and depends on the evidence decision above.

[jrosskopf]

Closing: the plan landed, and most of it was overtaken

Against main today:

Phase	State
Flip rfc: proto for osx and windows	done — both matrix entries are rfc: proto, RFC_LINK=static
Portable no-SDK assertion	done — ldd / otool -L / dumpbin, each asserting no sapnwrfc, sapucum or ICU
Release notes claiming macOS/Windows bundle the SDK	fixed — they now say all three carry no SDK and no ICU
bundle.ps1 needs a - sentinel	obsolete — #83 deleted bundle.ps1, bundle.sh, stage_runtime.sh and the launcher
Payloads become DuckDB alone	obsolete — DuckDB is linked statically into the binary; there is no payload at all
Windows CRT x64-windows-static-md	superseded — now x64-windows-static. DuckDB sets CMAKE_MSVC_RUNTIME_LIBRARY unconditionally, so /MT wins in its subdirectory and mixing gave LNK2038 on every DuckDB object
CMake native-static-libs per platform	not needed as written; the static link works on all three as built

Also since: macOS gained a CI job, which it did not have when this was written —
it was built only by the release workflow, on a tag, which is the worst place to
find a platform break. Two Windows-only defects have already been caught there.

What remains is exactly one row of Phase 2's evidence table, and it is unchanged
by any of the above: live SAP verification on macOS and Windows. CI proves
those binaries compile, link, load and answer RfcGetVersion; nothing proves
they replicate from a real system, because a hosted runner cannot reach one.

Closing this and filing that single item on its own, so nobody picking it up has
to first discover that four of its phases refer to files that no longer exist.