ozl(1)
NAME
ozl - oz linker
SYNOPSIS
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 sepa rated url prefixes.
--exclude=URL,...,URL
Exclude all functors whose url matches one of the comma sepa rated 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 pro vides 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.