Previous: Creating Applications Up: Creating Applications Next: Application Packer
Most Unix programs come with a ``makefile'' that is run through the standard Unix command make to compile and link the program. The makefile escribes everything needed to build the program, including what options to use for the compiler, what libraries are needed for the linker, and where to install the manual pages. Using make has many advantages, including compiling only what has changed since the last compile.
Unfortunately, VMS does not come with a make program. There is a layered product available, called MMS, that performs the same function with very similar makefiles, but it spawns a subprocess to do the compilation, which is very slow under VMS. It is also not available on all systems. Therefore, it is not practical for VICAR applications or subroutines.
Previously, VICAR programs were built in one of two basic ways. The first, and older, method was to have compile and link statements directly in the ``.COM'' file that contained all the application pieces. The pieces would be extracted, and the compiles performed, all in one step. The second method was to have a separate compile and link file, typically named ``CLapp.COM'' (for Compile and Link the application). This file was packaged in the application COM file along with the source code. It could then be executed independently of the application COM file to build the program.
The use of an independent command procedure to build the program under VMS has many advantages. It allows the application COM file to be separate. It works on all VMS machines, since DCL is standard. And, it is fast, since no subprocesses need to be created. The old CL files suffer from a terrible lack of standardization, and are not the easiest things to use, but the basic concept is a good one.
So, it boils down to this. To build applications under Unix, it is highly desirable to use make with a makefile. To build them under VMS, it is highly desirable to use DCL with a command procedure. Obviously, these two files (the makefile and the command procedure) are going to be incompatible. Worse yet, there is quite a bit of variation required for makefiles on different Unix machines. The commands used often vary, and sometimes there are differences in the format and capabilities of make itself.
It would be very cumbersome to require the VICAR application programmer to maintain two sets of build files for every application (for VMS and Unix). Furthermore, the differences in Unix makefiles would make it almost impossible to come up with a single makefile for all Unix systems. Fortunately, a program called imake has been written to solve these problems.
imake is used extensively in the X-windows system to allow building the system on many different platforms. TAE uses it as well. It is a program that makes makefiles. imake makes use of the C preprocessor for macros and conditional statements in order to customize the makefile for a particular platform. The input ``imakefile'' is a reduced makefile that contains only the program-specific parts, not the system-specific parts. A template file provides the system-specific parts of the makefile for each machine type. The imake program does some minor cleanup on the imakefile, runs it and the template through the C preprocessor, and does some cleanup on the output. The result is a makefile that is customized for the system you are on.
This helps to create Unix makefiles, but what about VMS? If you are familiar with imake, you know that the imakefiles typically look quite a bit like a makefile. There is a set of rules and definitions that are set up at the top of the makefile, but basically the structure of the imakefile is retained in the makefile. It would be impossible to generate a VMS command procedure from a typical imakefile.
The VICAR program vimake takes the concept of imake and goes one step further. Since the compile and link statements for all VICAR programs are quite similar, they do not need to be specified at all in the imakefile. In fact, vimake extracts all of the control out of the imakefile, leaving only C preprocessor commands.
The VICAR imakefile contains only a description of what is to be built, not how to build it.
A VICAR imakefile consists only of C preprocessor statements, mostly #define's and a few #if's. These #define statements set up the filenames used in the program, and select various options on how to build the program. The vimake program uses this information and a system-specific template to create a build file for any system. Under VMS, it creates a DCL command file that will build the program. Under Unix, it creates a makefile instead. The makefile and DCL command file are never delivered with the program; only the imakefile is.
There are many advantages to this scheme. First of all, the programmer need only create one imakefile, instead of separate build files for each system. Second, it is much easier to create the imakefile than it would be to create a full-blown build file. Third, all build files are standardized, since they are created entirely by the vimake templates. They all operate the same, and can be fairly complex since the application programmer never modifies them directly. Fourth, locations of libraries and other files are standardized, since the imakefile doesn't specify where the library is, just what library it wants. Finally, changing the way applications are built is easy. Only the templates need to change, and all applications will be built the new way.
___________________________________________________