ozl - oz linker

ozl FILE options ...

Application development can be considerably eased by splitting the application in a large number of orthogonal and reusable functors. However, deployment of an application gets harder in the presence of a large number of functors: (1) Installing the application requires correct installation of a large number of functors, (2) Execution might be slow due to frequent file- or even network accesses.

The commandline tool ozl eases deployment by creating a new functor that includes imported functors in a prelinked fashion: it is possible to collapse a hierarchy of functors into a single equivalent one. The model that should be kept in mind, is that the newly created functor employs an internal, private module manager that excutes the toplevel application functor together with all included functors.

It is usually invoked as follows: ozl IN -o OUT where IN is the input functor and OUT is the resulting collapsed functor. ozl understands the following options:

--relative (default), --norelative

All functors that are referred to by relative urlss are included.

--include=URL,...,URL

Include all functors whose url matches one of the comma separated url prefixes.

--exclude=URL,...,URL

Exclude all functors whose url matches one of the comma separated url prefixes.

Note that multiple --include and --exclude directives can be given on the commandline. They have cummulative effect, with the policy that later directives take precedence over earlier ones. For example:

ozl --include=/foo/ --exclude=/foo/bar/ ...

causes all imports from files below directory /foo to be included except those under directory /foo/bar. We can further refine this policy by introducing an exception to the last exclusion pattern and request inclusion of modules imported from below directory /foo/bar/baz:

ozl --include=/foo/ --exclude=/foo/bar/ --include=/foo/bar/baz/ ...

--compress=N, -z N

The created pickle is compressed with level N (a single digit). By default the compression level N is 0, that is, no compression is employed.

--executable (-x), --noexecutable (default)

Output the pickled functor as being executable (that is, with an additional header).

--execheader=STRING

When invoked with option -x the linker first outputs a header so that the output file may be interpreted by the operating system as an executable. Under Unix, the default behaviour is to use the following as header:

#!/bin/sh exec ozengine $0 "$@"

The --execheader option allows you to specify a different header.

--execpath=STRING

Uses the header given above in the description of --execheader, except that ozengine is replaced by STRING.

--execfile=FILE

Reads in FILE and uses this as header. Under Windows, the default behaviour is to use the file provided in ozhome/bin/ozwrapper.bin, where ozhome is Mozart's installation folder. ozwrapper.bin is a Windows executable that launches ozengine.

--execwrapper=FILE

Reads in ozhome/bin/FILE and uses it as header for executable files. Apart from ozwrapper.bin, an ozwrapperw.bin is supplied that launches ozenginew instead of ozengine. This option provides a convenient way to use this alternative wrapper.

--sequential, --nosequential (default)

Do not create a thread per executed functor body, rather execute all functor bodies in the same thread in a bottom up fashion. Use with care! In case the functors included have cyclic imports, it is not used.