Previous: RTL Differences Up: Porting C Next: VMS-Specific Code

Include Files

The standards for accessing include files have changed. The changes are necessary to ensure portability across platforms. On the VAX, there was not that much difference between putting an include filename in double quotes, angle brackets, or without any delimiter at all. To be portable, attention must be paid to which of these methods you use. Note that the include file standards have changed since the first draft edition of this Porting Guide.

There are five major classes of include files you will use. They are system, VICAR main, VICAR system, VICAR subroutine, and local.

Please keep track of which include files you actually need, and include only those. Some includes require that others be included first, but try to achieve the minimum set. Extra includes in your program don't gain you anything, and they slow down your compiles. They also make system maintenance much tougher, since the source code must occasionally be searched to see what programs use an include, and all programs that use an include must be recompiled when it changes (even if it's not really used).

System include files are provided by the operating system. Many of them are OS-specific, but there are a few that are standard across platforms. Make sure the ones you need are available in both operating systems, or isolate them in machine-dependent code. System include files should be enclosed in angle brackets and have the ``.h'' extension. As examples, some of the known portable includes are listed below.

#include <varargs.h>
#include <math.h>
#include <ctype.h>
#include <stdio.h>

One known non-portable file is <unistd.h>. If you need symbolic constants for the lseek() arguments (which are often contained there), use the definitions provided in xvmaininc.h.

The VICAR main include file, which all VICAR programs should start with, must be in lower case, with double quotes. The name of the main include has changed to ``vicmain_c'', with no directory specifiers and no ``.h'' extension. Any modules other than the main program module that need VICAR definitions should include xvmaininc.h, in lower case, with double quotes and the ``.h'' extension (xvmaininc.h is automatically included with vicmain_c).

#include "vicmain_c"
   - or -
#include "xvmaininc.h"

VICAR system includes are those provided as part of the RTL. Their names should be in lower case, with quotes and the ``.h'' extension. The valid ones are listed below. Only a few of these should ever be used in application code, notably ftnbridge.h, errdefs.h, and applic.h. The rest should only be needed in very unusual circumstances. They should generally be in the order listed below. Please include only the ones you need. Extraneous include files you don't use will only slow down your compile and make system maintenance harder. TAE includes are handled as specified in the TAE documentation. They should be in double quotes, with the ``.inc'' or ``.inp'' extensions as appropriate. The first four listed below are TAE includes.

#include "taeconf.inp"
#include "symtab.inc"
#include "parblk.inc"
#include "pgminc.inc"
#include "defines.h"
#include "declares.h"
#include "externs.h"
#include "applic.h"
#include "errdefs.h"
#include "ftnbridge.h"
#include "xviodefs.h"

VICAR subroutine include files (class 2 and 3 SUBLIB, VRDI, etc.) should be in double quotes, with no pathnames, and should include the ``.h'' extension, just like for VICAR system includes. For these includes, the directories containing the includes must be available to the compiler. This is normally handled transparently, but some libraries will require a LIB_* macro in the imakefile to access the includes. See the descriptions in Section , vimake, for details.

#include "vmachdep.h"
#include "gll_ssi_edr.h"
#include "xderrors.h"

Local includes, which are delivered as part of the COM file and are used only by that application, should be in double quotes, with no pathnames, and should include the ``.h'' extension, just like for VICAR system and subroutine includes. However, local includes must be listed in the INCLUDE_LIST macro in the imakefile so they can be cleaned up properly. See Section , vimake, for details.

#include "my_inc.h"