Components and Directory Structure [PREVIOUS] [TOP] [NEXT]

6.3 Components and Directory Structure

VICAR is divided up into about a dozen major parts. Each part has its own subdirectory off the VICAR root directory, containing both source code and executable programs. See the attached VICAR directory tree diagram (last page of this document). These parts fall into two main classes. The executive provides the environment in which both the user and the applications operate. The application programs provide most of the actual image processing functions of VICAR.

Not all of the directories listed below are implemented in the UNIX version of VICAR. They are included below for completeness, to give you a framework for the whole system. Directories printed in italics below are not yet available under UNIX.

The executive directories

The application directories

There are two extra directories, which are created during the build process. They contain no source code - everything in them is copied into them during a full build.

Each of the applications directories (p2 and p3) is further divided into several major pieces. They are listed below. The aliases are used as names for the build procedures, and are given for p2 only, but p3 is exactly the same (except for a 3 instead of a 2 in the name, of course).

Explanation of Directory Structure

The VICAR directory structure is designed to accommodate a heterogeneous array of machines simultaneously, all accessing the same VICAR tree over a network (e.g. via NFS). In order to accomplish this, every directory that contains machine-specific files (such as object code or executables) actually contains several subdirectories, one for each machine type. That is indicated by the "targets..." label in the diagram. These directories contain the same files for each machine type, and must be created by the machine in question. Most external installations will consist of only one type of machine, so there will be only one machine-specific subdirectory. (Note: it's machine types, not individual machine names, that are at issue here).

The subdirectories for each machine type follow a consistent naming scheme. The shell script vicset1.csh sets an environment variable, called $VICCPU, to the name of the type of machine (these names are actually defined in the include file $V2INC/xvmaininc.h). Thus, to get at the directory where the object code libraries are stored, you would not use $V2TOP/olb, you would use $V2TOP/olb/$VICCPU. (Of course, normally you use other environment variables set up by vicset1.csh, rather than $VICCPU directly, but this is how they are set).

For example, the object library directory might look like this:

% ls -CF $V2TOP/olb
hp-700/	sgi/	sun-4/		sun-solr/
% ls -CF $V2TOP/olb/hp-700
libmath77.a	libp2sub.a	librtl.a
% ls -CF $V2TOP/olb/sgi
libmath77.a	libp2sub.a	librtl.a

The valid machine types correspond with the supported machine types listed above.

The valid machine types correspond with the supported machine types listed below. The TAE directory is a special case. Though all supported versions use TAE 5.2, we must have two separate directories for SunOS and for Solaris. TAE compiles both into subdirectories named sun4, which means that SunOS and Solaris executables may not coexist in the same version of TAE, even though they have common source code. Other platforms coexist with SunOS in the MIPL delivery, although they may coexist with the Solaris version instead if SunOS is not needed. This is set up in vicset1.csh.

Next: The Version Number
Previous: Subroutine Libraries
Top: VICAR Installation Table of Contents
Updated Tue May 6 14:06:25 1997 by Larry Bolef