Allegro CL Runtime

$Revision: 5.0.2.5 $

The document introduction.htm provides an overview of the Allegro CL documentation with links to all major documents. The document index.htm is an index with pointers to every documented object (operators, variables, etc.) The revision number of this document is below the title. These documents may be revised from time to time between releases.

1.0 Allegro Runtime introduction
2.0 Conditions on distributing Allegro Runtime created applications

1.0 Allegro Runtime introduction

Runtime is a way to license the distribution of applications written in Allegro CL. It is designed to offer Value Added Resellers (VARs) and developers using Allegro CL for product development a way to deliver their products without requiring their users to have fully-paid licenses for Allegro CL.  Runtime is a separate product distributed by Franz Inc. Certain features usually available in Allegro CL are removed or disabled in a runtime image.

There are actually two flavors of Runtime (which is used to refer to both versions):

Common to both versions are the following restrictions:

Allegro CL Runtime adds these restrictions:

If you purchase Allegro CL Dynamic Runtime you will also receive Allegro CL Runtime.

On Windows, Allegro CL Runtime and Allegro CL Dynamic Runtime are options for Allegro CL Professional and Enterprise Editions only.

We will not discuss the licensing arrangements for any of the above Runtime products in this document. Please contact your Franz Inc. sales representative for more information on that point.

Creating images made for distribution under your Runtime license agreement is done with excl:generate-application or with excl:build-lisp-image. The excl:build-lisp-image keyword argument, :runtime, is accepted by generate-application and has three valid values:

nil don't generate an Runtime image
:standard generate an Allegro CL Runtime image
:dynamic generate an Allegro CL Dynamic Runtime image

Just build your application as you would normally build it with generate-application or excl:build-lisp-image. The use of the :runtime keyword can be done after all other testing of your application is finished and you wish to start the delivery phase. You should plan on extensive testing of the Runtime image, to make sure that you are not using any of the restricted functionality discussed above.

When :runtime is non-nil, tests are done during the image build to ensure that disallowed functionality is not being included in the image. The build fails if these tests indicate disallowed functionality is loaded. Sometimes disallowed functionality is loaded because of arguments to generate-application or excl:build-lisp-image are inappropriate, as discussed just below. Disallowed functionality may also be autoloaded because of calls in loaded Lisp code. Please contact Franz Inc. for assistance if you are having difficulty building a runtime image because of  inclusion of disallowed functionality.

You should specify values as indicated for the following arguments to build-lisp-image or generate-application when :runtime is :standard or :dynamic (i.e. not nil):

Arguments: Specify this value: Notes:
:include-devel-env nil When :include-devel-env is non-nil, the file develenv.cl is loaded into the image being built. That file requires many modules, including some that are not permitted in a runtime image. You can copy that file and edit to remove the requires for things not allowed in runtime, specifying the edited file as one to be loaded (with the :lisp-files argument to build-lisp-image and the input-files argument to generate-application).
:include-compiler

:discard-compiler

In :standard runtime, both must be nil or both must be t.

In :dynamic runtime (where the compiler is allowed) all (consistent) values are allowed.

If both have value t, the compiler is available while the image is being built and discarded at the end of the build process.
:load-xref-info
:record-xref-info
:discard-xref-info
nil The cross reference facility cannot be part of runtime. Specifying :discard-xref-info to be nil seems counter-intuitive but since no xref info is loaded, none needs to be discarded. Specifying :discard-xref-info true causes the xref module to be loaded, and that is not allowed in a runtime image.

A standard Allegro Runtime image will have :runtime-standard on the cl:*features* list. A dynamic Allegro Runtime image will have :runtime-dynamic.

2.0 Conditions on distributing Allegro Runtime created applications

With the Runtime option, a licensed developer can redistribute Runtime created applications to unlicensed end users as long as the following conditions are met:

  1. generate-application is used to create the application and the appropriate non-nil :runtime option is given.
  2. None of the files making up the Allegro CL or Runtime products may be sent to end users. Only the files that generate-application copies to the destination directory may be given to end users.

Copyright (C) 1998-1999, Franz Inc., Berkeley, CA. All Rights Reserved.