Ring++ can take a Ring program and turn it into something you hand to someone else, with no compiler and no Ring installation needed on their machine. It does that for essentially anything — except one case, which it stops and refuses outright.
If your program draws a window using Ring's Qt bridge, Ring++ will not package it. Not "will try and warn you" — it stops before writing a single byte.
That is a strong thing for a tool to do, so it owes an explanation. There are two, and they arrived in that order.
Reason one: a licence, not a technicality
Qt is the toolkit Ring uses to draw graphical interfaces. It is dual-licensed: you may use it free under the LGPL, which carries real obligations about how a commercial product links to it and redistributes it — or you buy a commercial licence instead.
For software delivered to paying customers, that is a business risk with a cost attached, and someone eventually has to answer for it. That decision was taken before Ring++ existed. It is not a judgement about Qt's quality, which is not in question.
Reason two: it was measured, and it was worse than expected
The second reason came later and turned a policy into a hard refusal.
Ring++ can look at a program and list every outside
component it needs, without running it. Point it at a program that draws
windows and it finds exactly one: a single file called
ringqt.dll. Bundle that file and every check agrees the
package is complete — nothing is reported missing.
Copied to a clean machine and run: no output whatsoever. No
error, no window, no message. Windows reports exit code
0xC0000409 and that is the entire story the user gets.
The reason is that ringqt.dll is not one
component. It is a doorway to roughly seventy-five more Qt
libraries, which the operating system loads at the moment the program
starts — and which no amount of reading the Ring source could ever
reveal, because the Ring source never mentions them.
Why silence is worse than an error
A missing-file error is a bad afternoon. You read the name, you find the file, you move on.
This is the other kind. Every automated check said the package was complete. It would have passed review. It would have shipped. And the first person to discover otherwise would be a customer, watching nothing happen, with no message to send back to anyone.
A tool that can produce that outcome should not offer
it. So ringpp build now recognises the case and stops,
naming the reason, before writing anything at all. That refusal is itself
tested: the test puts the exclusion back and confirms the silent-crash
package reappears, because a safety rule nobody has watched fail is not
known to work.
What this is not
It is not a rule against native components in general. Ring++ happily packages programs that use databases, networking or encryption — six such libraries are bundled and run in the test suite. Each is a single self-contained file that declares what it needs.
The Qt bridge is excluded for being the one whose real dependencies cannot be seen from the outside — and Ring++ would rather refuse than guess.
The build page has the full walkthrough, including the captured output from the package that crashed.