Prev | Next | Up | Title | Contents

2.2 Valid vimake Commands

This Section lists all the valid vimake macros. Although the order doesn't matter to vimake (since they are all preprocessor defines), you should keep entries in the order presented here for consistency.

There are nine broad classes of macros, which are listed in separate sections below.

2.2.1 Module Type Macros

These macros define the type of the module. One and only one of these macros must appear. Note: Do not use a tab between the macro and the name on any of these; use only spaces. make can be quite sensitive about tab characters in the module type names.
Only one of PROGRAM, SUBROUTINE, and PROCEDURE may be defined.

2.2.2 Name List Macros

These macros list the files used in the imakefile. MODULE_LIST must always be given for anything other than PROCEDURE. Others are optional.
Although some of those functions can be overridden with other lists, normally only MODULE_LIST will be used. MODULE_LIST must be defined. MODULE_LIST can only handle about 150 to 200 characters (2. 5 lines) worth of filenames. The limit is lower on VMS than on UNIX.

If you have more files than MODULE _LIST can handle by itself, use the list extension macros MODULE_LIST2, MODULE_LIST3, and MODULE_LIST4. Define MODULE_LIST in any case; the extensions are also used if present. They should be used in order. Each of the extensions can handle about 200 characters. If you need more than three extensions, contact the VICAR system programmer to add more extensions.
If there are no local includes, then do not define INCLUDE_LIST. System includes, or includes from SUBLIB, should not be in the list. This list is used for the source cleaning operation and makefile dependencies.
If there are no FORTRAN system or SUBLIB includes, then do not define FTNINC_LIST. This list is used to create logical names or symbolic links to the includes before the compile step.
The names in CLEAN_OBJ_LIST must have source code filename extensions. vimake will convert them to standard object module names automatically. CLEAN_OBJ_LIST may be extended with CLEAN_OBJ_LIST2, CLEAN_OBJ_LIST3, and CLEAN_OBJ_LIST4 in the same way as MODULE_LIST. See MODULE_LIST for details.
If any files are unpacked or created during the build process that are used only during the build process and that not covered by MODULE_LIST or INCLUDE_LIST (or automatically deleted as the .bld, .make, and .imakefiles are), then they should be listed in CLEAN_OTHER_LIST.

These files are typically source code files that are used only on other machines, if MODULE_LIST or INCLUDE_LIST are defined conditionally. If there are no extra files (the usual case), then do not define CLEAN_OTHER_LIST. There are currently no extension macros defined for CLEAN_OTHER_LIST.
If not given, this list defaults to the value for MODULE_LIST (which is automatically converted to object-name format), so LINK_LIST should rarely be used. LINK_LIST may be extended with LINK_LIST2, LINK_LIST3, and LINK_LIST4 in the same way as MODULE_LIST. See MODULE_LIST for details.
SCRIPT_LIST is not implemented on VMS though, so it should not be set by the user (i.e. use MODULE_LIST). Scripts are "built" depending on the type of script, often nothing but a chmod +x is done to them, but it depends on the script type. They're all listed in various USES_x below. Scripts should only be defined for type PROCEDURE (as opposed to PROGRAM or SUBROUTINE). Note that if a PROCEDURE has no MODULE_LIST, it automatically gets "PROCEDURE.pdf" where PROCEDURE is the name defined in the PROCEDURE #define. This is for backwards compatibility. So for example, pdf procedure imake's should now #define MODULE_LIST x.pdf and also #define USES_PDF. 
#define SYMBOL_LIST SYMBOL(zvzinit) SYMBOL(zzinit) \

SYMBOL(zvpinit) SYMBOL(zv_rtl_init) SYMBOL(sc2for) SYMBOL(sc2for_array)\

SYMBOL(sfor2c) SYMBOL(sfor2c_array) SYMBOL(sfor2len) SYMBOL(sfor2ptr) \

FSYMBOL(abend) SYMBOL(zabend) FSYMBOL(qprint) SYMBOL(zqprint) \

FSYMBOL(xladd) SYMBOL(zladd) FSYMBOL(xldel) SYMBOL(zldel) \

...
Where SYMBOL defines a C symbol, and FSYMBOL defines a Fortran-callable symbol (underscores are added where necessary). See for example librtl.com or librtlf.com in rtl, or for a smaller one, script_glue.com in gui/prog.

2.2.3 Main Language Macros

These macros define the language of the main program. One and only one of these must be present for type PROGRAM. They are not needed for any other type.

2.2.4 Languages Used Macros

These macros define which languages are used by source files in this imakefile. All the "USES_*" macros indicate that the named language is used in MODULE_LIST; the extension indicates which language it is (e.g. .cc is C++, .c is C, .csh is C-shell, etc.).
USES_ANSI_C may or may not accept non-ANSI constructs, depending on the machine implementation, but it should generate warnings if non-ANSI constructs are used. USES_ANSI_C is valid for types PROGRAM and SUBROUTINE. If any C code is to be compiled, either USES_C or USES_ANSI_C must be defined, but not both.

Only one version of C may be used at a time, so all of the C modules in the imakefile must be either ANSI or K&R C. All C source modules must have a filename extension of ". c". Any number of other USES flags may be defined, if needed. All C modules have the RTL and TAE include files available. Other include directories can included via the LIB macros or the class macros (R2LIB, P2_SUBLIB, etc.). main programs written in ANSI C still use the MAIN_LANG_C macro.
USES_C is valid for types PROGRAM and SUBROUTINE. If any C code is to be compiled, either USES_C or USES_ANSI_C must be defined, but not both. Only one version of C may be used at a time, so all of the C modules in the imakefile must be either ANSI or K&R C. All C source modules must have a filename extension of ".c". Any number of other USES flags may be defined, if needed. All C modules have the RTL and TAE include files available. Other include directories can be included via the LIB macros or the class macros(R2LIB, P2_SUBLIB, etc.). 
#define MODULE_LIST EXTRACT(xvzinit.o,rtl) \ EXTRACT_TAE(xqgenbr.o,tae) EXTRACT_TAE(xqtaskbr.o,tae)
The only difference between EXTRACT and EXTRACT_TAE is that EXTRACT looks for its library in $V2OLB (v2$olb), while EXTRACT_TAE looks in $TAELIB ($taelib).
VAX Macro code is not portable, so in a portable application a portable version of the same function must be available. Typically, MODULE_LIST will be defined differently for the VMS and UNIX versions (see the examples in the previous Section). All VAX Macro source modules must have a filename extension of ".mar". Any number of USES flags may be defined, if needed.
At the present time, VFC code is not portable, so in a portable application a portable version of the same function must be available. Typically, MODULE_LIST will be defined differently for the VMS and UNIX versions. All VFC source modules must have a filename extension of ".vfc". Any number of USES flags may be defined, if needed.

2.2.5 Build Flag Macros

These macros set up various flags for the compilation or link steps. Define them as needed.
They are available only from C. Some operating systems (notably Sun-4) require that modules using these routines be compiled with a lower level of optimization. If none of the string conversion routines are called, then do not define this flag. FTN_STRING must be defined if a C routine merely accepts a FORTRAN string, even if a subroutine ultimately calls the conversion routine. The same routine normally accepts the string and calls the conversion routine.
C_ OPTIONS is intended for program development use only. A program or subroutine should not be delivered with C_ OPTIONS defined. If it is, the C_OPTIONS must be defined in a machine-dependent conditional. 
#pragma define_template SL_List<SptParamBase *>
The template's .h file should include the .cc file for VMS and AXP_UNIX. Appropriate symbols have not yet been defined system wide; contact the VICAR System Programmer for assistance if you need to use this.
FORTRAN_OPTIONS is intended for program development use only. A program or subroutine not be delivered with FORTRAN_OPTIONS defined. If it is, the FORTRAN_OPTIONS must be defined in a machine-dependent conditional.
Under VMS, the options are placed after any vimake-generated options; under UNIX the options are placed at the beginning of the command line. LINK_ OPTIONS is intended for program development use only. A program or subroutine should not be delivered with LINK_ OPTIONS defined. If it is, the LINK_ OPTIONS must be defined in a machine-dependent conditional.
For UNIX machines that do have conditional macros, simply use the "debug" target in the standard generated makefile; the DEBUG flag is not needed. For VMS, you can use the "DEBUG" secondary option in the standard build file, so the DEBUG flag is not needed. A program or subroutine should never be delivered with DEBUG defined.
For UNIX machines that do have conditional macros, you can simply use the "profile" target in the standard generated makefile, so the PROFILE flag is not needed. For VMS, you can use the "PROFILE" secondary option in the standard build file, so the PROFILE flag is not needed. A program or subroutine should never be delivered with PROFILE defined.

2.2.6 Program Class Macros

These macros define what class the program is in. Valid for type PROGRAM only. They specify how to link the library for PROGRAM. One (and only one) of these must be defined.

2.2.7 Subroutine Class Macros

These macros define what class the subroutine is in. Valid for type SUBROUTINE only. They specify how to link the library for SUBROUTINE. One (and only one) of these must be defined.

2.2.8 Documentation Macros

These macros describe documentation that must be built. Use them if needed.
The file must be named according t o standard TAE conventions: " name fac.msg", where name is the facility part of the message key (the part before the "-"), usually the name of the program. The value x must not include the ".msg" extension. So, TAE_ERRMSG might be set to "sffac" or "bidrsfac". The message files are built with the TAE program msgbld.

2.2.9 Library Macros

These macros define the libraries needed for the compile and link steps. LIB_*'s specify how to link the library for PROGRAM, and where to find include files to both PROGRAM and SUBROUTINE. Almost all PROGRAMs and some SUBROUTINEs will define several. Define as many as are needed. They are not useful for type PROCEDURE. LOCAL_LIBRARY is special so it is listed first; the others are in alphabetical order.

Seehttp://rushmore.JPL.NASA.GOV/install/externalsoftware_old.html for a list of external software packages (below) with infomation about each.
For SUBROUTINEs, LOCAL_LIBRARY is the name of the object library that the modules are inserted into during a non-system build (system builds go directly to the appropriate system library). This is typically used during development and debugging.

For PROGRAMs, LOCAL_LIBRARY is the name of the object library included in the link statement when the LIB_LOCAL flag is set. It is used only during development and debugging. A program or subroutine is never delivered with LOCAL_LIBRARY defined, since the program or subroutine must build in directories other than yours. LOCAL_LIBRARY is provided merely as a convenience during program development.
LIB_C3JPEG is not available on all platforms. Currently, it is available only on Sun-4 platforms, as the library is hardware-dependent. If the library is not available (specified by the C3JPEG_AVAIL_OS flag defined in xvmaininc.h), then the LIB_C3JPEG flag is ignored.
The LIB_ FORTRAN flag is needed when linking a C main program to a subroutine written in FORTRAN that uses I/O statements (such as WRITE to a string). This subroutine may be hidden in a library such as P2SUB, so if you get unexplained link errors, you may need this flag.

The FORTRAN library is automatically included under VMS (flag is ignored), so you will not know if you need it unless you link the program on a UNIX system
The HWSUB_DEBUG library has not yet been implemented. This flag also makes the HW includes available to the C compiler.
LIB_MATRACOMP is currently available only on Sun-4 platforms. If the library is not available, then the LIB_MATRACOMP flag is ignored. As a temporary measure, the C3JPEG_AVAIL_OS flag defined in xvmaininc.h may be used to determine availability of the Matra software. This will change in the future (when linkgroups for subroutines are implemented), so if you use C3JPEG_AVAIL_OS for the Matra library, put in a comment marking this usage as temporary.
Currently, the Multinet network support libraries for VMS require a different include syntax. For example, instead of "rpc/rpc.h" the syntax would simply be "rpc.h". A conditional compile should take care of this. It is hoped that this difference will be resolved in the future.
The P1SUB_DEBUG library has not yet been implemented. This flag also makes the class 1 SUBLIB includes available to the C compiler.
The P2SUB_DEBUG library has not yet been implemented. This flag also makes the class 2 SUBLIB includes available to the C compiler.
The P3SUB_DEBUG library has not yet been implemented. This flag also makes the class 3 SUBLIB includes available to the C compiler.

Prev | Next | Up | Title | Contents