.bp
.NH 1 "THE KHOROS IMAKE SYSTEM
.XS
\s12\*(SN  THE KHOROS IMAKE SYSTEM
.XE
.sp 2
.PP
.nh
The Khoros system is designed to be run on a variety of platforms
and as such needs a common method which allows Khoros to be compiled
and installed on different architectures.  The method that was chosen uses
\fIImakefiles\fR and the utility \fBimake\fR, the same utility used by MIT with
the X11 source. \fBImake\fP allows architecture dependent \fIMakefiles\fP
to be automatically generated from an \fIImakefile\fP specification.
.PP
Khoros uses a series of \fIImakefiles\fR which are created from a set
of template files.  Each \fIImakefile\fR in turn includes a ``specification
file'', that defines which \fBimake\fR rules are applied for making 
the resulting \fIMakefile\fP. The resulting architecture dependent
\fIMakefile\fP is then used to compile and install programs, libraries, and
shell scripts.
.sp 2
.NH 2 "BACKGROUND"
.XS
      \*(SN  BACKGROUND
.XE
.sp
.PP
.nh
The \fBimake\fR and \fIImakefile\fR environment created for 
MIT X11 was not intended for software development.  It was primarily
set up to help compile and install a `final product', on many different
hardware architectures.  Khoros, on the other hand, uses \fBimake\fR and
\fIImakefiles\fR while in the development of the `final product'
allowing users and developers to extend Khoros.
As a result, many modifications were necessary to allow Khoros to be able to
use \fIImakefiles\fR.  These modifications necessitated the creation
of a set of files similar in nature to the `normal' \fBimake\fR definition
and configuration files, but allow Khoros to use \fBimake\fR other ways
To help manage the growth of Khoros during its development, 
\fBimkmf\fR and \fBmakemake\fR
were built to aid in the creation of \fIImakefiles\fR and \fIMakefiles\fR
in a consistent and easy manner.  These tools allow a software developer 
to easily add to a `final product' without having to spend an inordinate
amount of time learning about \fBimake\fR and \fIImakefiles\fR.
.PP
This manual section covers various aspects of how Khoros uses \fIImakefiles\fR
using the utility \fBimkmf\fR, how to install Khoros using the existing 
\fIImakefiles\fR, and how to integrate new sources into Khoros or to
move/rename existing sources.
.PP
This document does not go into any details on the specifics of 
how \fBimake\fR works, but enough information is given to compile 
and manage the Khoros \fBimake\fP system.
For more details, it is suggested that the reader consult the following 
references.  
.sp
.IP
"Configuration Management in the X Window System," Fulton, Jim (found in
MIT X.V11R4 source in mit/doc/config/usenixws/paper.ms)
.sp
.IP
"An \fIImake\fR Tutorial," Moraes, Mark, November 24, 1989
(found in MIT X.V11R4 source in contrib/doc/imake/imake.tex)
.sp 2
.NH 2 "KHOROS IMAKE TOOLS: imake, makemake, imkmf, makedepend"
.XS
              \*(SN  KHOROS IMAKE TOOLS: imake, makemake, imkmf, makedepend
.XE
.PP
Four main utility programs are used to manage the Khoros \fBimake\fP system. 
These
programs include \fBimake\fP, \fBmakemake\fP, \fBimkmf\fP, 
and \fBmakedepend\fP. \fBImake\fP and \fBmakedepend\fP are low-level tools
called by \fBmakemake\fP and/or \fBimkmf\fP. \fBMakemake\fP and \fBimkmf\fP
are used frequently to update and build both \fIMakefiles\fP and 
\fIImakefiles\fP. For specific information on how to use these tools, consult
the Khoros manpages makemake(1), imkmf(1), imake(1) and makedepend(1). 
The following paragraphs provide a brief introduction to each of these 
utility programs.
.PP
The utility \fBimake\fP is a low level configuration tool. \fBImake\fP takes
an Imakefile with a set of specifications defined in 
\fIKHOROS_HOME/repos/config/imake_conf\fP and generates a architecture
specific \fIMakefile\fP. \fBImake\fP uses the C preprocessor (cpp), taking
advantage of its include-file and macro-processing facilities for the
purpose of generating \fIMakefiles\fP suitable for \fBmake\fP.
.PP
The Khoros utility \fBmakemake\fR is a shell script that calls \fBimake\fR
with all of the necessary arguments to successfully \fBmake\fR or update
a \fIMakefile\fR
from an \fIImakefile\fR.  Currently, the \fBmakemake\fR script contains
the following command:
.in +1i
.nf
\f(CW
imake \\
   -DKHOROS_TEMPLATE=\\"Khoros.tmpl\\" \\
   -DKHOROS_HOME=$KHOROS_HOME \\
   -D{toolbox_defines} \\
   -T$KHOROS_HOME/repos/config/imake_conf/Khoros.tmpl \\
   -I$KHOROS_HOME/repos/config/imake_conf \\
   -I{toolbox_includes} \\
   -I$KHOROS_HOME/repos/config/imake_tmpls
\fR
.in -1i
.fi
.sp 1
These arguments to \fBimake\fR specify 
\fI$KHOROS_HOME/repos/config/imake_conf/Khoros.tmpl\fR as 
the basic startup file which in turn includes all of the other 
necessary files, including the current directory's \fIImakefile\fP 
(\fI./Imakefile\fR).
\fBImake\fR will first look in the directory 
\fI$KHOROS_HOME/repos/config/imake_conf\fR for the
\fBimake\fR specification files. It will then search all
the toolbox \fIrepos/config/imake_conf\fR directories
for the toolbox definition file.
Figure 1 Section B.3.1 shows the files that \fBimake\fR 
includes in the process of making a \fIMakefile\fR.  
.PP
The \fBimkmf\fP utility automatically generates an \fIImakefile\fP,
assuming that one does not
already exist, or updates an already existing one to contain
information sufficient to compare the files contained in the
directory.  If an \fIImakefile\fP does not exist, \fBimkmf\fP copies a
template, specified on the command line with `-type', into
the current directory and then proceeds to update it.
Revision is accomplished by reviewing of all the
files in the current directory and updating any existing
"definition" that \fBimkmf\fP uses.
\fBimkmf\fP uses the template \fIImakefiles\fP that can be found in
$KHOROS_HOME/repos/config/imake_tmpls/.
These template files include different
specifications to compile a program (independent or dependent of X11,
independent or dependent on Fortran), to create a library, to continue making
in sub-directories, and to install shell scripts.  All of these templates
contain empty \fBmake\fR definitions which are filled in by \fBimkmf\fR. 
The templates available are:
.sp
.in +1i
.nf
Imakefile.p \(em for programs which are independent of X11
Imakefile.pf \(em for programs which are dependent on Fortran and independent of X11
Imakefile.x \(em for programs which are dependent on X11
Imakefile.xf \(em for programs which are dependent on Fortran and X11
Imakefile.l  \(em for libraries
Imakefile.d \(em for directories
Imakefile.s \(em for scripts
.in -1i
.fi
.PP
Finally, the \fBmakedepend\fP utility is used to generate file dependencies
for C source files in each directory after the \fIMakefile\fP has been
built. Dependencies of C files upon objects can be statically listed in the
\fIImakefile\fP, but dependencies for header files (.h files) can not. 
Since different
architectures organize dependencies for header files differently, these
dependencies must be generated dynamically for each architecture. 
\fBMakedepend\fP is called automatically when a \fIMakefile\fP is
generated or updated using \fBmakemake\fP.
.sp 2
.NH 2 "CONFIGURING THE KHOROS IMAKE SYSTEM"
.XS
      \*(SN  CONFIGURING THE KHOROS IMAKE SYSTEM
.XE
.PP
Before Khoros can be compiled on a platform, the \fIimake\fP system
must be configured. The configuration consists of editing some of
the \fIimake\fP include-macro files. Before discussing the specifics 
required to compile Khoros, an overview of the \fIimake\fP 
symbol and macro construct and the include-macro
files is given. This will, hopefully, give one a clearer idea
of how \fIimake\fP gathers the information necessary to build a
\fIMakefile\fP. Finally, information specific to configuring the imake
system is discussed.
.sp 2
.NH 3 "\fBImake\fP Symbol and Macro Construct"
.XS
              \*(SN  \fBImake\fP Symbol and Macro Construct
.XE
.PP
The \fBimake\fP system uses symbol and macro constructs to gather
information necessary to generate a \fIMakefile\fP. The symbol and
macro constructs are defined in the Khoros \fBimake\fP configuration
files. The configuration files are discussed in the next subsection.
.PP
\fBImake\fP passes its input through the C preprocessor (cpp) so that
the definitions in the configuration files can take advantage of
several features not present in \fBmake\fP. The features include 
parameterized macros (using #define), file inclusion (using
#include) and conditional testing (using #if, #ifdef and #ifndef).
.PP
The flexibility of the Khoros configuration files is achieved through
the following construct, which defines a \fIsymbol\fP only if it
has not previously been defined:
.in +1i
.nf

	\f(CW#ifndef symbol
	#define symbol
	#endif\fP

.fi
.in -1i
.PP
This construct allows any system, library, or build symbol to be given a 
default definition if none has previously supplied. This definition
construct along with support for inclusion of platform, site and
library specific files prior to the section in which the default symbols
are defined, provides the ability to build a hierarchy for defining
symbols. For example, the default C compiler symbol, \fICcCmd\fP, 
occurs in the build section of the \fIKhoros.tmpl\fP file and is defined
as:
.in +1i
.nf

	\f(CW#ifndef CcCmd
	#define CcCmd cc
	#endif\fP

.fi
.in -1i
However, suppose you want to use \fIgcc\fP as the C compiler rather than
\fIcc\fP. The \fICcCmd\fP can be overridden by putting the following
symbol definition in either the \fISite.def\fP or \fIplatform.cf\fP
file. 
.in +1i
.nf

        \f(CW#ifndef CcCmd
        #define CcCmd gcc
        #endif\fP

.fi
.in -1i
.PP
The pattern followed in the the system/build section of the
\fIKhoros.tmpl\fP file is that definitions for \fIcpp\fP symbols
are listed first, followed by definitions for \fImake\fP
variables. The strategy adopted is to associate a 
\fIcpp\fP symbol with a given \fImake\fP variable by equating the
\fImake\fP variable to a given \fIcpp\fP symbol. The example
below illustrates this concept:
.in +1i
.nf

        \f(CW#ifndef CcCmd
        #define CcCmd gcc
        #endif
	  .
	  .
	  .
	CC=CcCmd\fP

.fi
.in -1i
.PP
For a listing of all \fIcpp\fP symbols and \fBimake\fP rules,
consult Vol 2, Appendix C, Imake Symbols and Variables. This 
appendix is helpful when either determining which \fIcpp\fP symbol
to change/set for a correct compile and when porting to a new
architecture.
.sp 2
.NH 3 "\fIImake\fP Configuration Files"
.XS
              \*(SN  \fIImake\fP Configuration Files
.XE
.PP
To produce a \fIMakefile\fP from an \fPImakefile\fP, the \fBimake\fP
utility uses configuration files located in
\fI$KHOROS_HOME/repos/config/imake_conf\fP. The following list
briefly describes each configuration file:
.in +1i
.nf
Khoros.tmpl \(em	Master template file used to generate the Makefile
\fIplatform\fP.cf \(em	Platform-specific definitions (the filename varies)
Site.def \(em		Site-specific definitions
Library.def \(em	Library specific definitions
Khoros.rules \(em	\fIcpp\fR macros to generate \fImake\fR rules
\fItoolbox\fP.def \(em	Toolbox-specific definitions (the filename varies)
.in -1i
.fi
.PP
Figure 1 below shows how the configuration files are included and
processed by \fBimake\fP to produce a Makefile. The \fIKhoros.tmpl\fP
file contains a #include line for each of the other four configuration
files and for the \fIImakefile\fP, and the \fIImakefile\fP contains a 
#include line for the
\fItoolbox\fP.def file. The 
\fIKhoros.tmpl\fP file also contains in-line sections for 
a header block section, a description
of system characteristics, build definitions and \fIextra make\fP
rules.
.PP
The \fIKhoros.tmpl\fP file contains all the default symbol definitions
for the Khoros \fBimake\fP system. Symbols defined
in the \fIplatform.cf\fP file will override the same symbols in the
\fISite.def\fP, \fILibrary.def\fP and \fIKhoros.tmpl\fP files.
Subsequently, symbols defined in the \fISite.def\fP file, which have
not previously been defined in the \fIplatform.cf\fP file will 
override the same symbols in the \fILibrary.def\fP and \fIKhoros.tmpl\fP files.
Any symbols defined in the \fItoolbox\fP.def file will
override the same symbols in all the previously included imake configuration
files.
Note: the \fIImakefile\fP should only contain \fBmake\fP variables; it
should not contain
\fIcpp\fP symbols. A \fBmake\fP variable defined in the \fIImakefile\fP
will override all previous declarations of that variable since the
variable is made by assignment rather than defined. 
.bp
.KF
.sp 2
.TS
center box tab (%) ;
l s s
l   l   l
l   l   l
l   _   l
l | l | l
l   _   l
l   _   l
l | l | l
l   _   l
l   l   l
l   _   l
l | l | l
l   _   l
l   _   l
l | l | l
l   _   l
l   _   l
l | l | l
l   _   l
l   _   l
l | l | l
l | l | l
l   _   l
l   l   l
l   l   l
l 
l .
\fIKhoros.tmpl\fR 
 %
%Header Blocks
 %
%#include \fI"Platform.cf"\fR     
 %
 %
%#include \fI"Site.def"\fR     
 %
%System description and build definitions
 %
%#include \fI"Library.def"\fR     
 %
 %
%#include \fI"Khoros.rules"\fR     
 %
 %
%#include \fI"{Toolbox_name}"\fR     
 %
 %
%#include \fI"./Imakefile"\fR     
%T{
.in +.1i
.sp
.B1
.sp .5
#include \fI"*.template"\fR\ \ \ 
    \s-4(Specific to Imakefile used)\s+4
.sp .5
.B2
.in -.1i
T}
%
%Extra \fImake\fP rules
 
 
.TE
.sp
.ce
Figure 1.  Khoros \fBimake\fR template structure
.sp 3
.KE
.sp 2
.NH 4 "Header Block"
.XS
                   \*(SN  Header Block
.XE
.PP
The header block section of \fIKhoros.tmpl\fP determines the type of
machine on which \fBimake\fP is being run. This will allow \fBimake\fP
to include the proper \fIplatform.cf\fP file when creating \fIMakefiles\fP.
Most C preprocessors
have unique symbols that indicate a given platform. For example,
a SUN4's preprocessor defines the symbol "sun", where as the 
Apollo defines the symbol "apollo". If the C preprocessor
does not define any such symbol, one can use the BOOTSTRAPFLAGS
option with \fBimake\fP to define a unique 
C preprocessor symbol. \fBimake\fP is designed
to pass the BOOTSTRAPFLAGS symbol to the C preprocessor for use. This
is important for those trying to port Khoros to a new platform.
.sp 2
.NH 4 "Platform.cf File"
.XS
                  \*(SN  Platform.cf File
.XE
.PP
After the header block section has determined which platform-specific
file to use, That file is then included by \fIKhoros.tmpl\fP.
The platform-specific file includes symbol definitions necessary to
build Khoros on a particular system. Overall these files are
usually a conglomeration of symbol definitions, make variables and
imake rules. This file must be edited before attempting to 
compile Khoros.  Appendix C, Vol 2, "Imake Symbols and Variables"
will aid in determining which symbol definitions need to be
changed or added.
.sp 2
.NH 4 "Site.def File"
.XS
                  \*(SN  Site.def File
.XE
.PP
This file contains site-specific definitions. This file should
reflect site-wide conventions. The \fISite.def\fP  file is a good place to 
override symbol defaults defined in the \fIKhoros.tmpl\fP file, at
least in theory. This file works fine if Khoros is going to
be installed and maintained on only one platform. If Khoros is
going to be installed and/or maintained on multiple platforms,
it is best make changes in the \fIplatform.cf\fP file rather than
the \fISite.def\fP file. This \fISite.def\fP is, in a sense,
global; symbol defines for one platform might not be 
correct for a different platform.
.sp 2
.NH 4 "System Description and Build Definitions"
.XS
                  \*(SN  System Description and Build Definitions
.XE
.PP
The inclusion of platform-specific and site-specific files in the
\fIKhoros.tmpl\fP are followed by a section containing some 
default symbol definitions. This section will make sure that
symbols, such as CcCmd, get defined that have not previously been defined.
This section is also where \fBmake\fP variables get equated to
\fIcpp\fP symbols.  This section of the \fIKhoros.tmpl\fP should
not be modified; definitions should be overridden in the 
platform-specific and site-specific files.
.sp 2
.NH 4 "Library.def File"
.XS
                  \*(SN  Library.def File
.XE
.PP
The \fILibrary.def\fP file contains symbol definitions and \fBmake\fP
variable equates for the Khoros libraries and programs.
This file defines the system libraries, X11R4 libraries, Fortran
libraries and Khoros libraries necessary to build Khoros. Most
of the symbol definitions and \fBmake\fP variables in this file
do not have defaults in the \fIKhoros.tmpl\fP file. The \fILibrary.def\fP file
is included after the \fISite.def\fP and \fIplatform.cf\fP files.
.sp 2
.NH 4 "Khoros.rules File"
.XS
                  \*(SN  Khoros.rules File
.XE
.PP
This file contains the \fIcpp\fP macros used to generate 
\fBmake\fP rules for the \fIMakefiles\fP. This file should not
be modified. If rule changes need to be made, the \fIplatform.cf\fP
file is the place to make changes. Consult the \fIsgi.cf\fP file
for an example.
.sp 2
.NH 4 "toolbox.def File"
.XS
                  \*(SN  toolbox.def File
.XE
.PP
This file contains the symbol definitions for a particular toolbox.
All the symbol definitions specified in this file will override
the same symbol definition that was previously defined. This
file exists in each toolbox in the repos/config/imake_conf
directory. The \fBimkmf\fP program will automatically
include this file.  If the "-toolbox" \fBimkmf\fP option is not used on
the command line, the default
toolbox definition file for KHOROS_HOME will be used.  It is located in
 $KHOROS_HOME/repos/config/imake_conf/Toolbox.def.  
If the "-toolbox {toolbox_name}" option is specified, the 
 $TOOLBOX_NAME/repos/config/imake_conf/{toolbox_name}.def file will be
used.
For more information on setting up and
managing toolboxes, consult Vol 2, Chapter 1, specifically read about
\fBkraftsman, composer and kinstall\fP.
.sp 2
.NH 4 "./Imakefile File"
.XS
                  \*(SN  ./Imakefile File
.XE
.PP
The last file included in the \fIKhoros.tmpl\fP file is the 
\fIImakefile\fP from the current directory. The Khoros 
\fIImakefiles\fP define the sources, objects, header files and
necessary libraries needed to compile. \fIImakefiles\fP should
always be generated using the progarm \fBimkmf\fP.
.sp 2
.NH 4 "Extra Make Rules"
.XS
                  \*(SN  Extra Make Rules
.XE
.PP
The last section of the \fIKhoros.tmpl\fP file defines some
of the common \fBmake\fP targets such as "clean", "tags", etc.
These definitions should not be modified.
.sp 2
.NH 3 "Khoros \fIImakefile\fP Templates"
.XS
                  \*(SN  Khoros \fIImakefile\fP Templates
.XE
.PP
The Khoros \fBimake\fP system uses template \fIImakefiles\fP
when generating \fIImakefiles\fP. The utility \fBimkmf\fP uses
the template files in \fI$KHOROS_HOME/repos/config/imake_tmpls\fP
to make an \fIImakefile\fP.
.PP
All of the \fIImakefile\fR templates, besides containing the \fBmake\fR
definitions to be filled in by \fBimkmf\fR, contain ``include'' references
to other files that contain specifications which are common to all of
the \fIImakefile\fR templates.  Templates \fIImakefile.p\fR and
\fIImakefile.x\fR include the file \fIProg.template\fR;
\fIImakefile.pf\fR and \fIImakefile.xf\fR include the file
\fIFProg.template\fR; \fIImakefile.l\fR includes the
file \fILib.template\fR; \fIImakefile.d\fR includes the file 
\fIDir.template\fR and
\fIImakefile.s\fR includes the file \fIScrpt.template\fR.
Note, these files should never
have to be touched, changes to the imake system should be made through
the \fIplatform.cf\fP files, the \fISite.def\fP file and the \fILibrary.def\fP
file located in \fI$KHOROS_HOME/repos/config/imake_conf\fP.
.PP
.nh
The \fI*.template\fR files contain the \fBimake\fR specifications
instead of the \fIImakefile\fR templates themselves because if a
``rule'' needs to
be added or modified which changes the way \fIImakefiles\fR
work, for example
compiling a library, then only a single file, in this case
\fILib.template\fR, needs to be updated instead of all library
\fIImakefiles\fR.
.sp 2
.NH 2 "KHOROS INSTALLATION CONFIGURATION"
.XS
      \*(SN  KHOROS INSTALLATION CONFIGURATION
.XE
.sp
.PP
Before the installation can begin, there are three files that need to 
be checked for correctness to insure proper installation of Khoros.
All three files are located in \fI$KHOROS_HOME/repos/config/imake_conf\fR 
and contain symbol definitions to override default specifications.
.PP
The first file, \fIplatform.cf\fR, where \fIplatform\fP is the
architecture of your machine. For example, use the file "sun.cf"
if you are on a Sun, use the file "ultrix.cf" if you are on 
a Decmips, use the file "sgi.cf" if you are on a SGI machine. 
The \fIplatform.cf\fR file contains machine specific symbol
defines. If is important to set the symbols to the correct
value. For example, if your system does not have a Fortran compiler,
then set the symbol "HasFortran" to NO, if your system
does not support Saber-C, set the symbol HasSaberC to NO. 
.PP
The next file that needs to be modified is the \fISite.def\fP
file. It is suggested that the file not be changed. It is better
to copy the symbols that need changing into the \fIplatform.cf\fR
file, and make the changes in the \fIplatform.cf\fR file. The reason
for this is because if you are going to support Khoros on
more than one architecture the \fIplatform.cf\fR will override
the \fISite.def\fP file. The \fISite.def\fP file is a "global"
file where as the  \fIplatform.cf\fR is local to a particular
platform.
.PP
The symbols in the \fISite.def\fP file define where the
Khoros binaries, libraries, man pages, and source directories
exist. Also, this file contains some of the common symbols that
need to be overridden from the defaults. Note, many of the
symbols in the \fISite.def\fP file will appear in the
\fIplatform.cf\fR file.
.PP
The last file that needs to be modified is the \fILibrary.def\fR file.
This file contains the symbol defines for which libraries are
necessary to link against. The only symbols that should be changed
in this file are \fILibDir, SysLibs, XLibs, ForSysLibs, and ExtraLibs\fP.
.sp 2
.NH 3 "Multiple Architectures"
.XS
          \*(SN  Multiple Architectures
.XE
.PP
If you plan to support Khoros on multiple architectures, then all
changes to the \fBimake\fP system should be made in the
\fIplatform.cf\fR file. The \fISite.def\fP and  \fILibrary.def\fR file
act as "global" files for symbol defines, whereas the 
\fIplatform.cf\fR file is local to a particular architecture. Again,
any symbol that is defined in the \fIplatform.cf\fR file will override
the same symbol in the \fISite.def\fP and  \fILibrary.def\fR file.
.sp 2
.NH 3 "Commonly Asked Questions"
.XS
          \*(SN  Commonly Asked Questions
.XE
.PP
Below are a few commonly asked questions about the \fBimake\fP configuration
files. We suggest that the symbol defines discussed below are put
in the \fIplatform.cf\fR file.
.RS
.IP Q:
X11 directories are not in the "standard" place on my machine, how
do I specify where the X11 directories exist?
.IP A:
define the symbol "XLibDir" to the directory where the X11 libraries exist
.br
.nf

	\f(CW#define XLibDir /usr/local/lib/X11\fP
.fi
.sp
define the symbol "XIncludes" to the directory where the X11 include directory
exists.
.br
.nf

        \f(CW#define XIncludes -I/usr/local/include\fP

.fi

.RE
.RS
.IP Q:
Fortran libraries are in /usr/lang rather than in /usr/lib, how do I change
where to look for Fortran libraries?
.IP A:
define the symbol "FortranLibDir" to the directory where the Fortran libraries exist
.br
.nf

	\f(CW#define FortranLibDir /usr/lang\fP
.fi
.RE
.RS
.IP Q:
I need to add some other libraries to compile against, how do I add these
extra libraries?
.IP A:
define the symbol "ExtraLibs" to the directory where the libraries exist
.br
.nf

	\f(CW#define ExtraLibs /myhome/foobar\fP
.fi
.RE
.RS
.IP Q:
How do I make the libraries load with a different option than the
C programs load with?
.IP A:
define the symbol "LibraryLdCmd" to the command that you want the
libraries to load with and the "LdCmd" to the command that you want
the C programs to load with.
.br
.nf

	\f(CW#define LibraryLdCmd ld\fP
	\f(CW#define LdCmd cc\fP
.fi
.RE
.RS
.IP Q:
How do I specify different compile options for libraries and
C programs.
.IP A:
define the symbol "LibraryCCOptions" to the options that you want the
libraries to compile with and the "DefaultCCOptions" to the options
that you want the C programs to compile with.
.br
.nf

	\f(CW#define LibraryCCOptions -q -P\fP
	\f(CW#define DefaultCCOptions -float\fP
.fi
.RE
.IP Q:
How do I specify different compile options for Fortan libraries and
Fortran object files.
.IP A:
define the symbol "LibraryFCOptions" to the options that you want the
libraries or other Fortran object files to compile with. 
.br
.nf

	\f(CW#define LibraryFCOptions -O\fP
.fi
.RE
.PP
Although many more questions about configuring the \fBimake\fP system
have been asked, this set of questions and answers should give one the
feel of how to make changes to the \fBimake\fP configuration files.
It is strongly suggested that the document Vol 2, Appendix C, 
"Imake Symbols and Variables" be consulted when making changes to
the \fBimake\fP symbols.
.sp 2
.NH 2 "ADDING FILES TO KHOROS"
.XS
      \*(SN  ADDING FILES TO KHOROS
.XE
.sp
.PP
.nh
At this point it is assumed that Khoros has already been successfully
installed, and now other data processing programs or applications
are to be added to enhance it.  These enhancements may range from
simply adding a new algorithm to
an existing library, to something a little more difficult, such as adding a new
library, program or shell script. NOTE, KHOROS SOURCE SHOULD NOT BE MODIFIED.
MODIFICATION OF KHOROS SOURCE WILL PREVENT THE ABILITY TO UPDATE THE
SOURCE WITH LATER PATCHES. New routines, libraries and scripts should
be installed in a Khoros toolbox, or kept in the users local
area.
.PP
.nh
In all cases the \fIImakefiles\fR are managed by the \fBimkmf\fR
utility which either creates \fIImakefiles\fR if none exist, or updates them to
contain current information concerning the files in existence in the current
directory.
.PP
It is strongly suggested that the Khoros utilities for installing
and managing the Khoros source tree and the Khoros toolboxes be used
rather than performing the tasks manually, as outlined below. Please
consult the "Writing Programs" documentation Vol 2, Chapter 1,
and the Configuration Management documentation Vol 2, Chapter 9, Section A
before
installing a new routine. The utilities that may be helpful for
managing Khoros and Khoros toolbox source include: \fBkraftsman, kmakeall,
kinstall, kdinstall, krmprog, ksrcconf, and klnfile\fP. Use \fBvman\fP
to obtain more information on these tools.
.sp 2
.NH 2 "UPDATING \f(BIImakefiles\fP"
.XS
      \*(SN  UPDATING \fIImakefiles\fP
.XE
.sp
.PP
.nh
.PP
.nh
If all the \fIImakefiles\fR in a subdirectory
need to be updated or changed to reflect changes made to the \fIImakefile\fR
templates, probably as a result of adding a new library (see EXAMPLE 2),
then all that needs to be done is to cd into the directory 
and run \fBmake AllImakefiles\fR. 
The \fIImakefiles\fR have built into them the necessary information
so that \fBimkmf\fR gets called with the correct arguments.
.PP
If the \fIImakefiles\fP need to be completely regenerated, the 
command \fBmake GenAllImakefiles\fP, will remove the existing 
\fIImakefiles\fR and recreate them. The difference between
\fBmake AllImakefiles\fR and \fBmake GenAllImakefiles\fP is 
\fBmake AllImakefiles\fR just updates existing \fIImakefiles\fR while
\fBmake GenAllImakefiles\fP recreates them. Normally
\fBmake GenAllImakefiles\fP is not needed.
.sp 2
.NH 2 "WORKING WITH \f(BIMakefiles\fP"
.XS
      \*(SN  WORKING WITH \fIMakefiles\fP
.XE
.sp
.PP
.nh
A user should never have to edit a \fIMakefile\fR
to change a \fBmake\fR definition (for example to change the `-O' option
to `-g').  Changes can be made by either
modifying the \fIImakefile\fR and
then remaking the \fIMakefile\fR, by running \fBmake Makefile\fR,
or by using \fBmake CDEBUGFLAGS=-g\fR.
The user has access to several \fBmake\fR definitions to help
accomplish this task.  Some of the more common
definitions are listed in Table 1.
.KS
.ps 10
.nr PS 10
.vs 12
.nr VS 12
.TS
center box tab(%);
l | l | lw55 .
\fBmake\fP definitions%Default%comments
_
CDEBUGFLAGS%-O%T{
Passed to all compiles.  If a `debug' compile is needed, just change this to
be `-g'.   This definition is used in defining CFLAGS, which is used when
compiling C files, and LDOPTIONS, which is used when loading (linking) a
program, \fIa.out\fR for example.
T}
_
STD_INCLUDES%-I.%T{
\fI$KHOROS_HOME/include\fR is already included elsewhere.  This field
should only be added to in the rare case where an include file is needed
and is not in either of `.' or \fI$KHOROS_HOME/include\fR.  This definition is
used in defining CFLAGS which is used when compiling C files.
T}
_
YFLAGS%%Flags passed to \fByacc\fR
_
LFLAGS%%Flags passed to \fBlex\fR
_
EXTRA_LOAD_FLAGS%%T{
When compiling a program, this
field can be used to pass additional flags to the loader
during the program load phase, for example any additional
libraries that need to be linked in.
This definition is used when loading (linking) a
program, \fIa.out\fR for example.
T}
.TE
.ps 11
.nr PS 11
.vs 13
.nr VS 13
.sp
.ce 
Table 1.  Some common \fBmake\fR definitions the user may change in 
the \fIImakefile\fR or on the \fBmake\fR command line.
.KE
.bp
.NH 2 "EXAMPLES"
.XS
      \*(SN  EXAMPLES
.XE
.sp
.PP
.nh
In this section, several references are made to Khoros utilities which are used
to help manage the system. For a complete description of these utilities
and their exact use consult Section A of this chapter.
\fBkmakeall\fR is basically equivalent to \fBmake\fR
except that \fBkmakeall\fR \fBrsh\fRes to other systems to \fBmake\fR Khoros
on different architectures. \fBksrcconf\fR creates symbolically linked
source trees allowing different architectures to be compiled using
the same source without having to have multiple copies of the source.
It is strongly suggested that the Khoros manual pages
for these utilities be consulted to provide a detailed description
of what these utilities do.
.PP
.nh
There are also references made to `srcmach' trees which are what \fBksrcconf\fR
creates.  For example, in $KHOROS_HOME/srcmach there might contain directories
\fBsrcdecmips\fR and \fBsrcsun4\fR which are source trees, symbolic links
to the real source, created to allow compiles on DEC Mips and Sun 4 based
machines respectively.
.PP
.nh
The rest of this section contains examples of how to add new routines
or programs into a Khoros \fItoolbox\fP (see Volume 2, Chapter 1 
for instructions
on using \fBkraftsman\fP to create and maintain a toolbox). 
The examples that follow will assume that a toolbox
has been previously created and the name of the toolbox is CONTRIB_TOOLBOX.
.sp 2
.NH 3 "Adding a New Routine to an Existing Library"
.XS
              \*(SN  Adding a New Routine to an Existing Library
.XE
.PP
.nh
The following steps show how to install a new routine, source file,
into an already existing library.  For example, assume
that a routine called \fIvfoo\fR (file \fIvfoo.c\fR) is to be added to the
library \fIlibcontrib.a\fR which is located in the toolbox called 
CONTRIB_TOOLBOX. Do not forget to specify the -toolbox option
when using \fBksrcconf\fR and \fBkmakeall\fR.
.in +.5i
.IP 1)
Install the new file, \fIvfoo.c\fR, in the library directory, with
either the \fBmv\fR or \fBcp\fR command.
.IP 2)
Run \fBimkmf\fR in the library directory, to update the
\fIImakefile\fR so that it contains a reference to the newly added file
\fIvfoo.c\fR.
.IP 3)
Run \fBmakemake\fR to update the \fIMakefile\fR to reflect the changes
made to the \fIImakefile\fR in step 2 above.
.IP 4)
If there are no `srcmach' trees, go to step 5b else continue with step 5a.
.sp
.IP 5a)
Run \fBksrcconf -toolbox contrib_toolbox\fR to create the symbolic links 
for the new file in the `srcmach' trees.
.IP 6a)
Run \fBkmakeall -toolbox contrib_toolbox Makefile\fR to update 
the \fIMakefiles\fR in the `srcmach' trees.
.IP 7a)
Run \fBkmakeall -toolbox contrib_toolbox depend\fR to add the file 
dependencies to the \fIMakefiles\fR in the `srcmach' trees.  Do not combine 
this step with step 6a above, i.e. \fBkmakeall -toolbox contrib_toolbox 
Makefile depend\fR, because the \fIMakefile\fR that is used for 
the `depend' would be the old one and not the new one which contains a 
reference to the newly added file \fIvfoo.c\fR.
.IP 8a)
Run \fBkmakeall -toolbox contrib_toolbox install\fR to compile the new 
file in the `srcmach' trees and to install the library in the library 
directory.  Do not combine this step with step 7a above, i.e.  
\fBkmakeall -toolbox contrib_toolbox depend install\fR, because the
\fIMakefile\fR that would be used for the `install' is the old one and not the
one with the dependencies added.
.LP
Adding the routine \fIvfoo\fR to the library is finished.
.sp
.IP 5b)
Run \fBmake depend\fR to add the file dependencies to the \fIMakefile\fR.
Do not combine this step
with step 3 above, i.e. \fBmake Makefile depend\fR, because the
\fIMakefile\fR that is used for the `depend' would be the old one 
and not the new one which contains a reference to the newly added 
file \fIvfoo.c\fR.
.IP 6b)
Run \fBmake install\fR to compile the new file into the library and to
install the library in the library directory.  Do not combine this step
with step 5b above, i.e. \fBmake depend install\fR, because the
\fIMakefile\fR that is used for the `install' would be the old one and not the
one with the dependencies added.
.LP
Adding the routine \fIvfoo\fR to the library is finished.
.in -.5i
.sp 2
.NH 3 "Creating a New Library"
.XS
              \*(SN  Creating a New Library
.XE
.PP
.nh
The following steps show how to install a new library
into the "CONTRIB_TOOLBOX" toolbox.  For example, assume
that the library \fIlibfubar.a\fR is to be added to your toolbox and is
to be placed in \fI$CONTRIB_TOOLBOX/src/Lib\fR.
For clarity, the directory name should be the same as the library name.
For this example since the library will be \fIlibfubar.a\fR, the directory
name should be \fIfubar\fR.
.in +.5i
.IP 1)
Make a directory \fIfubar\fR in \fI$CONTRIB_TOOLBOX/src/Lib\fR.
.IP 2)
Install the files that will make up the new library into the \fIfubar\fR
directory with either the \fBmv\fR or \fBcp\fR command.
.IP 3)
cd into the new directory, \fIfubar\fR.
.IP 4)
Run \fBimkmf -type lib -name fubar -toolbox contrib_toolbox\fR to 
create the \fIImakefile\fR.
The \fIlibname\fR argument should be the name of the library, which in
this example is \fIfubar\fR.
.IP 5)
Run \fBmakemake\fR to create the first \fIMakefile\fR. 
.IP 6)
cd .. (into \fI$CONTRIB_TOOLBOX/src/Lib\fR).
.IP 7)
Run \fBimkmf\fR to update the \fIImakefile\fR in \fI$CONTRIB_TOOLBOX/src/Lib\fR
so that it contains a reference to the new directory \fIfubar\fR.
.IP 8)
Run \fBmake Makefile\fR to update the \fIMakefile\fR to reflect changes made
to the \fIImakefile\fR in step 7 above.
.IP 9)
If there are no `srcmach' trees, go to step 11b else continue with step 11a.
.sp
.IP 10a)
Run \fBksrcconf -toolbox contrib_toolbox\fR to create the symbolic links 
for the new directory in the `srcmach' trees.
.IP 11a)
Run \fBkmakeall -toolbox contrib_toolbox Makefile\fR to update 
the \fIMakefile\fR in the `srcmach' trees.
.IP 12a)
cd into the new directory, \fIfubar\fR.
.IP 13a)
Run \fBkmakeall -toolbox contrib_toolbox install\fR to make, in 
any `srcmach' tree, the new library and to install it.
.IP 14a)
Go to step 15.
.sp
.IP 10b)
cd into the new directory, \fIfubar\fR.
.IP 11b)
Run \fBmake install\fR to make the new library and to install it.
Do not combine this step
with step 11b above, i.e.  \fBmake depend install\fR, because the
\fIMakefile\fR that is used for the `install' is the old one and not the
one with the dependencies added.
.sp .5
Continue with step 15.
.sp
.IP 15)
Now that the library has been compiled and installed, the toolbox imake
definition file needs to be updated so that programs will know about the 
new library.
.sp
cd into \fI$CONTRIB_TOOLBOX/repos/config/imake_conf\fR.
.sp
Edit the file \fIcontrib_toolbox.def\fP adding \f(CW-lfoobar\fP to the 
\f(CWTOOLBOX_LIBRARIES\fP line, and \f(CW$(LIBDIR)/libfoobar.a\fP
to the \f(CWTOOLBOX_DEP_LIBRARIES\fP line.
.br
Note, if the \fIfubar\fR library is a fortran library then modify the
\f(CWFOR_TOOLBOX_LIBRARIES\fP and \f(CWFOR_TOOLBOX_DEP_LIBRARIES\fP lines
rather than the \f(CWTOOLBOX_LIBRARIES\fP and \f(CWTOOLBOX_DEP_LIBRARIES\fP 
lines. If the \fIfubar\fR library makes calls or references any of the
X11 libraries then modify the \f(CWX_TOOLBOX_LIBRARIES\fP and 
\f(CWX_TOOLBOX_DEP_LIBRARIES\fP lines rather than the 
\f(CWTOOLBOX_LIBRARIES\fP and \f(CWTOOLBOX_DEP_LIBRARIES\fP lines.
.IP 17)
At this point, the addition of library \fIfubar\fR to the toolbox is complete;
allowing programs to know about it. Before compiling a program which
needs to link against the new library, the \fImake Makefile\fP
command must be run on the programs \fIMakefile\fP.
.in -.5i
.sp 2
.NH 3 "Creating a New Program (independent of X11)"
.XS
              \*(SN  Creating a New Program (independent of X11)
.XE
.PP
.nh
The following steps show how to install a new program, independent of X11,
into a Khoros toolbox.  For example, assume
that the program, \fIvbar\fR, is a routine and falls under the
\fIarith\fR category.  Also assume that this program needs to call the
library routine \fIlvbar\fR.
For clarity, the directory name should be the same as the program name.
Note, Khoros provides a tool, \fBkinstall\fP, for installing new routines.
For more information on \fBkinstall\fP consult kinstall(1) and
Volume 2, Chapter 1 - Writing Programs.
The method outlined below is for manual installation of a routine, we
recommend that you use \fBkinstall\fP.
.PP
.nh
There are two parts to installing a program.  The first is adding the
routine \fIlvbar\fR to the library located in \fI$CONTRIB_TOOLBOX/src/Lib/bar\fR
and then installing the modified library.  The procedure for doing this
is described above in the above example.  The second part is installing
the ``main'' part
of the program.  The procedure for doing this is described in the steps below.
.PP
.nh
It should be noted that it is very likely that the library module source will
be located in the same directory with the ``main'' source of the program,
requiring that 
steps 1, 2 and 3 below be completed before the library module can be added to
the library, as described in the above example.
.sp
.in +.5i
.IP 1)
Create the directory \fIvbar\fR in \fI$CONTRIB_TOOLBOX/src/arith\fR. Note,
if the \fIarith\fR directory does not exist, you must first create the
\fIarith\fR directory then create the \fIvbar\fR directory. In 
the \fIarith\fR directory you must create an
Imakefile using \fBimkmf -type dir -toolbox contrib_toolbox\fP and a 
Makefile using \fBmakemake\fP. If you created the \fIarith\fR directory, then
\f(CWcd ..\fP and run Run \fBimkmf\fR to update the \fIImakefile\fR in
\fI$CONTRIB_TOOLBOX/src\fR and \fBmake Makefile\fR to update the \fIMakefile\fR.
.IP 2)
Install the files for the new program in the \fIvbar\fR directory
with either the \fBmv\fR or \fBcp\fR command.
.IP 3)
cd into the new directory, \fIvbar\fR.
.sp
If there is a library module associated with the ``main'' source, then
it needs to be installed in the required library as 
described in the above example before continueing.  
In our example, the source for \fIlvbar\fR
needs to be installed in library \fI$CONTRIB_TOOLBOX/src/Lib/bar\fR.
.IP 4)
Run \fBimkmf -type prog -name vbar -toolbox contrib_toolbox\fR to 
create the \fIImakefile\fR.
Note, if the program makes a call to Fortran or any Fortran function
is used, use \fBimkmf -type fprog -name vbar -toolbox contrib_toolbox\fR 
to create a Fortran \fIImakefile\fR.
The \fIprogname\fR argument should be the name of the program, which in
this example is \fIvbar\fR.
.IP 5)
Run \fBmakemake\fR to create the \fIMakefile\fR.
.IP 6)
cd .. (in \fI$CONTRIB_TOOLBOX/src/arith\fR).
.IP 7)
Run \fBimkmf\fR to update the \fIImakefile\fR in
\fI$CONTRIB_TOOLBOX/src/arith\fR so that it contains a reference to
the new directory \fIvbar\fR.
.IP 8)
Run \fBmake Makefile\fR to update the \fIMakefile\fR to reflect changes made
to the \fIImakefile\fR.
.IP 9)
If there are no `srcmach' trees, go to step 10b else continue with step 10a.
.sp
.IP 10a)
Run \fBksrcconf -toolbox contrib_toolbox\fR to create the symbolic links 
for the new directory in the `srcmach' trees.
.IP 11a)
Run \fBkmakeall -toolbox contrib_toolbox  Makefile\fR to update the 
\fIMakefile\fR in the `srcmach'
trees.
.IP 12a)
cd into the new directory, \fIvbar\fR.
.IP 13a)
Run \fBkmakeall -toolbox contrib_toolbox install\fR to make, in 
any `srcmach' tree, the new program and to install it.
.LP
Adding the routine \fIvbar\fR to \fIarith\fR is finished.
.sp
.IP 10b)
cd into the new directory, \fIvbar\fR.
.IP 11b)
Run \fBmake depend\fR to create the file dependences in the \fIMakefile\fR.
.IP 12b)
Run \fBmake install\fR to compile the new files and to install the new program.
Do not combine this step
with step 11b above, i.e.  \fBmake depend install\fR, because the
\fIMakefile\fR used for the `install' would be the old one and not the
one with the dependencies added.
.LP
Adding the routine \fIvbar\fR to \fIarith\fR is finished.
.in -.5i
.sp 2
.NH 3 "Creating a New Program (dependent on X11)"
.XS
              \*(SN  Creating a New Program (dependent on X11)
.XE
.PP
.nh
The steps involved in adding a new program, dependent on X11, is 
exactly the same as described in the above example with the exception that step
4) needs to be:
.in +.5i
.IP 4)
Run \fBimkmf -type xprog -name vbar -toolbox contrib_toolbox\fR to 
create the \fIImakefile\fR. 
The \fIxprogname\fR argument should be the name of the X11 program.
If the routine is dependent on Fortran then use 
\fBimkmf -type fxprog -name xprogname -toolbox contrib_toolbox\fR.
.in -.5i
.sp 2
.NH 3 "Creating a New Shell Script"
.XS
              \*(SN  Creating a New Shell Script
.XE
.PP
.nh
The steps involved in adding a new shell script are exactly the
same as described above in the "Creating a New Program" section
with the exception that step 4) needs to be:
.in +.5i
.IP 4)
Run \fBimkmf -type script -toolbox contrib_toolbox -name\fR 
\fIscriptname\fR to create the \fIImakefile\fR.  
The \fIscriptname\fR argument should be the name of the 
`main' script, assuming that several scripts are needed to help the `main'
script.
.in -.5i
.PP
All script files should end with the suffix ".csh".
.sp 2
.NH 3 "Moving Files within a Khoros Toolbox"
.XS
              \*(SN  Moving Files within a Khoros Toolbox
.XE
.PP
.nh
If the only things being moved are files, no directories, then the following
steps need to be taken to insure that the \fIImakefiles\f located in the
`original' and `destination' directories are up to date.
For example, assume that files \fIlvclip.c\fR and \fIlvtranslat.c\fR need
to be moved from \fI$CONTRIB_TOOLBOX/src/vipl/Lib\fR to
\fI$CONTRIB_TOOLBOX/src/dspl/Lib\fR.
.PP
.nh
In the steps below, if there are no `srcmach' trees, then just use 
\fBmake\fR for the make command otherwise use \fBmake\fP 
followed by \fBkmakeall -toolbox contrib_toolbox\fR.
.in +.5i
.IP 1)
cd into the `original' directory, in our example
\fI$CONTRIB_TOOLBOX/src/vipl/Lib\fR.
.IP 2)
Move the required files from the current directory to
\fI$CONTRIB_TOOLBOX/src/dspl/Lib\fR, for example: \f(CWmv lvclip.c lvtranslat.c
$CONTRIB_TOOLBOX/src/dspl/Lib\fR.
.IP 3)
Remove the object files (\fIlvclip.o\fR and \fIlvtranslat.o\fR)
associated with the files that were moved.  This can be done either running
\fBmake clean\fR, which removes all objects, or they can be removed
by hand, for example: \f(CWrm lvclip.o lvtranslat.o\fR.
.IP 4)
Run \fBimkmf\fR to update the 
\fIImakefile\fR (to remove references to the moved files, \fIlvclip.c\fR, 
\fIlvtranslat.c\fR, \fIlvclip.o\fR, and \fIlvtranslat.o\fR,
from the SRCS, OBJS, FSRCS, FOBJS, HEADERS lists).
.IP 5)
Run \fBmake Makefile\fR to update the \fIMakefile\fR 
to reflect the changes made to the \fIImakefile\fR in step 4 above.
.IP 6)
Run \fBmake depend\fR to add the file
dependencies to the \fIMakefile\fR.  Do not combine this step
with step 5 above, i.e. \fBmake Makefile depend\fR, because the
\fIMakefile\fR that is used for the `depend' would be the old one and not
the new one which has the references to the moved files removed.
.IP 7)
Run \fBmake install\fR to make sure moving the files did not
cause any \fBmake\fR problems.  Do not combine
this step with step 6 above, i.e. \fBmake depend install\fR,
because the \fIMakefile\fR that is used for the `install' would be
the old one and not the one with the dependencies added.
.IP 8)
cd into the `destination' directory, in our example
\fI$CONTRIB_TOOLBOX/src/dspl/Lib\fR.
.IP 9)
Run \fBimkmf\fR to update the 
\fIImakefile\fR (to add references to the moved files,
\fIlvclip.c\fR, \fIlvtranslat.c\fR, \fIlvclip.o\fR, and \fIlvtranslat.o\fR, 
to the SRCS, OBJS, FSRCS, FOBJS, HEADERS lists).
.IP 10)
Run \fBmake Makefile\fR to update the 
\fIMakefile\fR to reflect the changes made to the \fIImakefile\fR in
step 9 above.
.IP 11)
Run \fBmake depend\fR to add the file dependencies to the
\fIMakefile\fR.  Do not combine this step
with step 10 above, i.e. \fBmake Makefile depend\fR, because the
\fIMakefile\fR that is used for the `depend' would be the old one and not
the new one which has references to the moved files inserted.
.IP 12)
Run \fBmake install\fR to make sure moving the files did not
create any unresolved dependencies.  Do not combine this step
with step 11 above, i.e. \fBmake depend install\fR, because the
\fIMakefile\fR that is used for the `install' would be the old one and not the
one with the dependencies added.
.IP 13)
Moving the files, \fIlvclip.c\fR and \fIlvtranslat.c\fR, is finished.
.in -.5i
.sp 2
.NH 3 "Moving a Directory within a Khoros Toolbox"
.XS
              \*(SN  Moving a Directory within a Khoros Toolbox
.XE
.PP
.nh
If a directory is all that is being moved, no individual files, then
the following
steps need to be taken to insure that the \fIImakefile\f located in the
`original' and `destination' directories are up to date.
For example, assume that the directory \fIvadd\fR needs
to be moved from \fI$CONTRIB_TOOLBOX/src/vipl/arith_binary\fR to
\fI$CONTRIB_TOOLBOX/src/vipl/arith_unary\fR.
.PP
.nh
In the steps below, if there are no `srcmach' trees, then just use 
\fBmake\fR for the make command otherwise use both \fBmake\fP and
\fBkmakeall -toolbox contrib_toolbox\fR. Again, it is best to use 
the Khoros utilities, \fBkdinstall\fP, \fBkrmprog\fP, 
and \fBkinstall\fP to remove or
move either programs within the Khoros environment.
The method outlined below should be followed when directories are 
being moved manually.
.in +.5i
.IP 1)
cd into the `original' directory, \fI$CONTRIB_TOOLBOX/src/vipl/arith_binary\fR.
.IP 2)
Move the required directory, \fIvadd\fR from the current directory to
\fI$CONTRIB_TOOLBOX/src/vipl/arith_unary\fR, for example:
.IP  
\f(CWmv vadd $CONTRIB_TOOLBOX/src/vipl/arith_unary\fR.
.IP 3)
Edit the configuration file, \fIvadd.conf\fR, to reflect the
change of location of the sources.
.IP 4)
Run \fBimkmf\fR to update the 
\fIImakefile\fR (to remove the reference to the moved directory, 
\fIarith_binary\fR, from the SUBDIRS list).
.IP 5)
Run \fBmake Makefile\fR to update the `original' directory
\fIMakefile\fR to reflect the changes made to the \fIImakefile\fR
in step 3 above.
.IP 6)
cd into the `destination' directory, \fI$CONTRIB_TOOLBOX/src/vipl/arith_unary\fR.
.IP 7)
Run \fBimkmf\fR to update the 
\fIImakefile\fR (to add a reference to the moved directory,
\fIarith_unary\fR, to the SUBDIRS list).
.IP 8)
Run \fBmake Makefile\fR to update the
\fIMakefile\fR to reflect the changes made to the \fIImakefile\fR in step
6 above.
.IP 9)
Run \fBmake install\fR to make sure moving the directory did not
create any unresolved dependencies.
.IP 10)
If the name of the directory moved was changed, for example from \fIvadd\fR
to \fIaddition\fR, then all files associated with the old name need to
be removed by hand; i.e. remove \fI$CONTRIB_TOOLBOX/bin/vadd\fR.  
If the directory moved was a library, for example
\fI$CONTRIB_TOOLBOX/src/Lib/vrast\fR, and the name was changed
from \fIlibvrast.a \fR to \fIlibvraster.a\fR, then the old library
would need to be removed by hand; i.e. remove \fI$CONTRIB_TOOLBOX/lib/libvrast.a\fR.
.IP 11)
Moving a directory is finished.
.in -.5i
