The purpose of the Runtime Generator is to provide a convenient and cost-effective way to distribute Prolog application programs to end-users. Initially a Prolog application should be developed using the Development System. The Development System allows the application developer to load, run, modify and debug programs interactively, without having to leave the environment. When an application program has been completed, the Runtime Generator product allows a developer to create a production version of the application, ready to be shipped to end-users. This version of the application is called a runtime system.

The important points to note about runtime systems are:

  1. They can easily be deployed, because they do not require any authorization codes in order to run.
  2. They are smaller than programs built on top of the Development System, since they do not include program development features such as the compiler, the debugger and the Emacs interface

The process of building a runtime system is almost identical to the process of building a stand-alone program with the Development System, and both of these processes are documented in sap-srs. The compiler qpc is used to compile your Prolog source files into Quintus Object Format (QOF) files, and these are then linked together using the link editor qld. Both qpc and qld require a -D command-line option when building a stand-alone program; the default is to build a runtime system.

It is recommended that before turning an application program into a runtime system you first build it as a stand-alone program. This way, if there are any problems, you will have the debugger available to help you eliminate them.

Once you have built a stand-alone program, it should be very easy to rebuild the application as a runtime system. This section describes the few points that may need to be considered in making this transition:

  1. Some built-in predicates are not available in runtime systems, since they are intended for use in program development rather than for use in application programs. See sap-rge-dspn.
  2. Runtime systems do not have the normal Prolog top level. Instead, you must specify a starting point for the program by defining the predicate runtime_entry/1. This predicate also allows you to specify what is to be done after an abort occurs. See sap-rge-pro.
  3. Runtime systems have different default behavior on a ^C interrupt. Instead of giving the user a set of choices, the system immediately aborts. See sap-rge-iha.
  4. If your runtime system contains dependencies on "non-standard" shared libraries, or on one or more shared object files (specified in calls to load_foreign_executable/1), then in order to be able to deliver the runtime system to a different machine you will need either
    1. to make the system completely self-contained by replacing the shared object files and libraries with equivalent archive files when building it; or
    2. to ensure that all necessary shared libraries and shared object files are available on the target machine.

    See sap-rge-sos for more information on this issue.

Another difference between runtime systems and programs running under the Development System is that runtime systems suppress informative error messages, on the basis that such messages are intended for the application developer, not the application user. For example, if a runtime system consults a file, no message is printed to the screen to indicate this. If you wanted some such message to appear at runtime, you would have to program it yourself.

Error messages are not suppressed, however. If you want to suppress the printing of some (or all) error messages you can do it by providing a definition for the predicate message_hook/3. See ref-msg-umf-ipm.