|
|
|
|
General Information
Tutorials
Reference Manuals
Libraries
Translation Tasks
Tools
Administration
|
|
Guide for New Eli Users
Customizing Eli's BehaviorAll derived objects are stored in a directory called the derived object cache, or simply the cache. The cache also contains a database that stores the depends relationship between the output and input files of a tool run, and the contains relationship between a list and its elements. Many of the ways of customizing Eli involve various aspects of the derived object cache. Eli can also be used non-interactively, and can be customized by defining shortcuts for frequently-used derivations.
Hints on Cache Management
The default location for the cache is a directory named An Eli session is begun by giving the following command:
eli [ -c cache ] [ -r | -R ] All of the command line arguments are optional, and all affect the cache:
Cache directories may also be deleted using normal Unix commands
whenever they are not being used by active Eli sessions.
If the specified cache does not exist when the There is no limit to the number of cache directories that may exist at one time. You might choose to have a separate cache for each project you are working on, or you might choose to have a single cache to hold information for all of your projects. If you choose multiple caches, each can be smaller than the cache you would use for all projects. When a project is complete, you can delete all the intermediate objects relating to it by deleting the cache directory for that project.
Cache contents are architecture dependent, so it is not possible to
create a cache on one architecture and then
use that same cache on a different architecture.
In order to avoid this error, Eli creates a separate subdirectory of the
cache directory for each host (not architecture) on which it is
invoked.
This behavior is unpleasant in a setting where there is a pool of hosts,
all of which have the same architecture, running with a common file server.
If the environment variable
The default inter-process communication mechanism
for the odin cache manager process is TCP/IP.
If TCP/IP is not available,
set the environment variable
Hints on Session ManagementThere are two kinds of Eli sessions -- interactive and non-interactive. Interactive sessions are used when the requests being made are ones that Eli can satisfy quickly, and actions by the user are necessary between requests. During initial development of a specification, when specification errors prevent Eli from completely satisfying the request, interactive sessions are very fruitful: The user makes a request, errors are reported, the user corrects the errors and makes the request again.
One important decision that must be made for either kind of session is the
amount of information that should be provided to the user during that session.
(Of course if the session is interactive, this decision can be changed
during the session itself by making appropriate requests.)
Eli is capable of describing at great length what it is doing at any given
moment.
Since the purpose of Eli is to suppress the details of the process needed to
satisfy your request, you will probably not want Eli to report those details to
you.
The Eli variable
The value of the environment variable
-> EDITOR=!emacsclient (Note the use of ! to indicate that the assignment is to an environment variable rather than to an Eli variable.)
You may wish to make your selection of an editor dependent on some property
of the environment.
A typical situation is to use one editor when seated at a workstation and
another when logged in remotely.
In this case, create a script `my_editor' that tests the appropriate
environment variables, decides what editor to use, and invokes it.
Then set the value of the environment variable
Users of Gnu Emacs
who invoke Emacs only once per login session
(i.e. in a window that is always present) can
use the server capability of Emacs.
To do this, execute the command
Eli consults file `Odinfile'
in the current directory for information about the task at hand.
`Odinfile' is used to define one or more targets.
Each target defines some product that can be requested,
using the notation target
|
