Ship it. No compiler,
on anyone's machine.

A program that touches nothing native

Package it, copy the two files to an empty directory with nothing else present, run it:

$ ringpp build hello.ring --out dist

built  dist
  hello.exe
  hello.ringo

run with:  hello.exe hello.ringo

That is the whole artefact. No installer, no ring.dll, no Ring install on the target machine at all — verified in this project's own gate by copying exactly those two files to a clean directory and running them there.

Five platforms — built from whichever one you're on

This is the part Zig makes possible. --target names where the program will run; it says nothing about where you're building it. All five combinations work from a single machine:

$ ringpp build service.ring --target linux-x64 --out dist-linux

built  dist-linux
  service
  service.ringo

run with:  service service.ringo

Built on a Windows machine, targeting Linux, with no Linux anywhere in sight during the build. Not taken on faith: copied to a clean Ubuntu machine and run there, output byte-identical to running the source directly on Windows. Package once per target you ship to; nobody on the team needs a second machine, a VM, or a container to produce any of the five.

A program that reaches native code

ringpp deps names every native library a program can reach before you package anything — statically, without running it:

$ ringpp deps lib.ring --ring D:\ring127

lib.ring
  load closure : 40 file(s) reached

  Native libraries reachable from this program — these do NOT travel
  inside a .ringo and must exist on the target machine:

    windows            macos                  linux                    declared in
    ring_odbc.dll      libring_odbc.dylib     libring_odbc.so          odbclib.ring:2
    ring_mysql.dll     libring_mysql.dylib    libring_mysql.so         mysqllib.ring:2
    ring_sqlite.dll    libring_sqlite.dylib   libring_sqlite.so        sqlitelib.ring:2
    ring_internet.dll  libring_internet.dylib libring_internet.so     internetlib.ring:2
    ring_openssl.dll   libring_openssl.dylib  libring_openssl.so      openssllib.ring:2
    ring_pgsql.dll     libring_pgsql.dylib    libring_pgsql.so        postgresqllib.ring:2

Point ringpp build at a real install and it bundles what it can find — never silently. A library it cannot find is named MISSING in the manifest; the package still works, and says exactly what it is missing.

Why this is a standing rule, not a one-off

Two reasons, and the first came before the second was ever measured. Qt is dual-licensed — free under LGPL terms with real obligations for how a commercial product links and redistributes it, or a paid commercial licence otherwise. For software shipped to customers, that is a real business risk, decided against before Ring++ existed. The crash above is the technical reason underneath the business one: Ring reaches native code through a scattered shelf of extensions — one ring_*.dll per capability, each with its own build, its own transitive dependencies, none of it tracked in one place. The Qt refusal is one instance of a wider, deliberate stance: Softanza's own Ring foundations aim to depend on nothing beyond what they vendor and support themselves.

Softanza is not standing still on that either. Its own engine program — a separate effort from Ring++, in its own repository — has spent five milestones replacing exactly this shelf: uuid.ring, fastpro.ring, html.ring, libcurl.ring and libuv.ring are gone from Softanza's own base library, each closed out with a Zig-native module in their place.

Ring++ does not ship that engine — it is Softanza's own project, further along a road Ring++'s own measurement (the Qt crash above) confirms is the right one to be on. Two independent efforts, the same direction: fewer scattered native dependencies, not more.