Oberon || Compiler & Tools || Library || Module Index || Search Engine

Ulm's Oberon System:
obload

NAME

obload - load Oberon object from CDB

SYNOPSIS

obload [-a auth] [-A arch] {-b basedir} [-i intensity] [-l loglevel] [-m] [-o output] [-O pattern] [-c|-C] [-D|-M] {modname}

DESCRIPTION

obload generates (if non-existing or out-of-date) and loads (if requested) a persistent object of the Oberon compiler for all given modules (modname) whose sources must be present in the compiler database (CDB, see obci).

Objects generated by the compiler are persistent objects representing abstract syntax trees (either architecture-independent or architecture-dependent), or ready-to-run machine code. Both, definitions and modules may be translated into abstract syntax trees.

obload works recursively in a manner comparable to make(1). If the target is missing or out-of-date regarding to the most recent sources found in CDB, obload tries to rebuild it. If one of the abstract trees representing the definitions for the modules imported by modname is missing or out-of-date, it will be regenerated like the primary target.

Note that compilation options have to be passed to obci because different sources may require different options.

Following options are supported:

-a auth

specifies a file containing a persistent object of type Shards.Lid that is to be used for authorization.

-A arch

load an object for the architecture arch. Architectures are to be specified in a syntax as required by Architectures.

-b basedir

defines the base path of the compiler data base (CDB). Default is /pub/cdb/oberon. Note that any number of base paths may be given. Multiple base paths are combined through TranslucentNames, i.e. results are written into the last base path, and base paths specified later on the command line take precedence over those given earlier.

-c

store all generated objects into CDB. By default, architecture-independent abstract syntax trees of modules will not be stored. Note that the use of this option can be more time-consuming since re-generation of objects can be in some cases faster than loading persistent objects from CDB.

-C

do not store anything into CDB.

-D

load an object containing an abstract syntax tree for the definition (public interface) of modname (default).

-i intensity

allows to set the intensity level for Storage.Intensity (see Storage). This allows to fine-tune the balance of memory usage vs CPU time by the garbage collection. By default, the intensity is 8. Lower intensity values reduce memory usage but cause CPU overhead by more frequent garbage collections. Higher intensity values cause more memory to be used while saving more CPU time. Please note however, that the address space can also be a significant limit, i.e. at high intensity values it is possible that no more address space is found by Memory.

-l loglevel

requests log information as generated via CompilerLogs to be displayed. This is mainly useful to follow the recursive process of building. A log level of 0 (default) suppresses any logs. Larger log levels cause more output to generated.

-m

asks to setup performance monitoring by SysMonitor. Statistics are printed to standard output.

-M

load an object containing an architecture-independent abstract syntax tree, or, if an architecture was specified, ready-to-run machine code of modname.

-o output

asks the generated persistent object to be stored into output.

-O pattern

asks the requested results and their transitive closure to be stored in multiple files whose names are generated from pattern. All characters within pattern are taken literally with the exception of two-character sequences starting with ``%'':

%a: insert the string representing the architecture. ``gen'' is inserted if it is architecture-independent.
%c: insert the string representing the architecture class. ``gen'' is inserted if it is architecture-independent.
%m: insert the module name.
%t: insert the type, i.e. ``def'' for public interfaces, and ``mod'' for private implementations.
%%: insert a single ``%''.

DIAGNOSTICS

All error messages generated by the compiler are hopefully self-explanatory. Please do not expect error messages from the given modules only but the transitive closure of imported modules as they have possibly not been compiled yet. The layout of error messages is different (and easier to read) if it goes directly to a tty if a standout mode is supported. See CompilerErrors, Listers, and TerminalListers for details.

ENVIRONMENT

Following environment parameters allow to override the builtin defaults:

CDB_AUTH: default path of the authorization file.
CDB_BASEDIR: default path of CDB within the Oberon name space.

EXAMPLE

Following commands check in Oberon sources into the CDB and try to load them:

oberon$ A=/var/cdbd/db/write
oberon$ obci -a $A Hello.o[dm]
oberon$ obload -a $A -A SPARC -M -o Hello.obj Hello

This command line, however, does not load the modules Hello depends on. This is possible through the ``-O'' option:

oberon$ obload -a $A -A SPARC -M -O %m.obj Hello

This transitive closure, however, omits those modules which are nowhere explicitly imported but still required by the runtime system. This module list can be retrieved using the ``-r'' option of genobrts(1):

oberon$ rtmodules=`$BINDIR/genobrts -r`
oberon$ obload -a $A -A SPARC -M -O %m.obj Hello $rtmodules

Edited by: borchert, last change: 2005/02/05, revision: 1.5, converted to HTML: 2005/02/05