The purpose of this class is to support C and Fortran include files.
The C ones are no problem, it's the Fortran ones that cause the hassle.
All ASTERIX Fortran uses the old VMS style logical names for include
files. These are translated by the v2u_include script into
absolute UNIX file names. This process is performed by the Starlink
forconv program which reads in a file called include.sub
which is a two column text file containing the mappings from VMS style
include file names to UNIX ones. The file of these mappings is constructed
on the fly by v2u_include, and destroyed after translation (although
their is a persistent mode to support bulk compilation). The mapping
file is made by concatenating all the mapping files generated for each
of the ASTERIX inc directories. These mapping files are stored
in $AST_ROOT/$SYSTEM/etc/sys in the built system.
It is worth mentioning that C modules in ASTERIX have to have their
include file paths specified somehow. This is done in two ways. Include
paths which are system dependent are included in the mk script
using the CFLAGS environment variable. The replace script
in dev/scripts then adds the current directory, the ASTERIX library
include directory and the Starlink include directory to the include
path list, ie.the equivalent of
-I. -I$AST_ROOT/kernel/lib/inc -I/star/includeon the command line. The strategy of C use in ASTERIX has been to restrict it to the kernel routines -- there are only two exceptions,
fit__misc_c.c in the spectral fitting and htrace_int.c
in the HSD editor packages. If it became necessary to start adding more
C routines then there might then be a case for a local GEN_make token
containing local C include directives to give the same flexibility as
is already implemented in the Fortran case.
In summary there are only two tokens in this directory class, namely
F_INCS and C_INCS. The only built file is the Fortran
mapping file which ends up in $AST_ETC/sys/<subsystem>.includes
where subsystem is the full subsystem name of the include file diretory.