I assume my readers are familiar with the UNIX make utility which is widely used for software maintenance. Here I use a dialect of the make language called cake. I never could have succeeded in getting the job done with make.
The main strategy is to isolate the reusable code in two files, SEP.defs that I ``include'' at the beginning of each figure-making cakefile and SEP.idoc.rules that I include at the end. Each of my cakefiles starts with
#define USRLIBS SEPCLASSLIB
#include <SEP.defs>
The first line says that linking must include the library used in all my classes. If you need additional libraries, add them to the end of this line. SEP.defs also sets up a default location for my figures because it contains the line
#define FIGDIR ./../Fig
which means a sister directory to any of my figure-building directories is named Fig (which is generally a symbolic link to a nonprecious area). Not everyone at SEP organizes their directories as I do. I put in one directory all files needed to create a family of figures except for the final plot files which go in FIGDIR. A rare few of my directories install programs in the official places for system-wide executables and I use Dave's methods for that.
My typical default behavior when I come into a directory is to type cake and view a succession of figures emerging from the tube program. In the skeleton cakefile below, typing cake will show me two figures named data and spectrum, and it will build them first if they are out-of-date.
#define USRLIBS SEPCLASSLIB
#include <SEP.defs>
#define FIGLIST data spectrum
default& : tube
$ comment
$ Application dependent stuff described later belongs here.
$
clean& : jclean
#include <SEP.obj.rules>
#include <SEP.prog.rules>
#include <SEP.idoc.rules>
I have a bunch of file names that I have universally decided to be dregs that can always be removed by a cake clean. Thus, all my cakefiles contain:
clean& : jclean
This line means that when someone types cake clean that jclean must be built. Neither clean nor jclean are files; they are abstract and the & is a signal for cake not to complain when no file named clean appears after the completion of cake clean. The rule for building jclean is found in SEP.idoc.rules and it consists of rm commands for the many file types that I consider to be dregs. You probably agree with my definition of dregs but maybe you should check. (Earlier versions considered fortran files to be dregs!)
At the bottom of my cakefiles I included the compilation and linking rules of Dave Nichols, and I include SEP.idoc.rules, which is about two pages of cake rules that are common to all my figure building and whose content is our main subject here. First, however, I need to tell you our naming conventions:
NAME.rst source code needing saw,sat, ratfor and fortran passes NAME.rs source code needing saw, ratfor and fortran passes NAME.rt source code needing sat, ratfor and fortran passes NAME.r source code needing ratfor and fortran passes NAME.f fortran NAME.o object file, ready to be linked NAME.x executable (sometimes without .x) NAME.ps postscript NAME.ps.save precious postscript, not to be burned. NAME.v vplot (intermediate plot language) NAME.v.save precious vplot, not to be burned. NAME.H data history file. NAME.p process parameter file NAME.A history file of movie (or Animator) bytes.
SEP.obj.rules and SEP.prog.rules are smart enough that simple linking jobs are done for you with no futher assistance. Thanks to Dave Nichols, these rules know about the different compiler flags and library names on different machines. For example, if the rule for building the figure named spectrum is
#define DATA /q2/wz/wz.26.H
FIGDIR/spectrum.v : DATA myspectrum.x
<DATA myspectrum.x | Graph > junk.H out=FIGDIR/spectrum.v
and your directory contains a fortran source file named myspectrum.f, then the included rules will compile myspectrum.f and link it to the libraries. In the above rule you can use myspectrum in the place of myspectrum.x. I prefer myspectrum.x because my jclean rule knows about .x files whereas jclean does not know how to identify myspectrum as something that needs to be removed at cleaning time.
Often several files must be separately compiled and linked together. Below is how I create the executable myprog.x which links a fortran main with some .o files.
#define MYPROG mymainprog.o sub.o fun.o
myprog.x : MYPROG
FLINK(MYPROG, myprog.x)
Each of my figure-building cakefiles contains the definition of a list of figures that it can build and manipulate. Above, that definition is
#define FIGLIST data spectrum
The application-specific rules in the cakefile should make FIGDIR/data.v and FIGDIR/spectrum.v (or possibly corresponding postscript files, but for now nearly all my figures are made in the vplot intermediate plot language, and SEP.idoc.rules builds the postscript for me). Because I always include SEP.idoc.rules in any of my figure-building directories I can issue the following commands:
cake burn # Remove vplot and postscript figures cake burnps # Remove only postscript figures cake figures # build postscript for all figs cake vplot # build vplot for all figs cake tube # view all the vplot files cake NAME.tube # view with tube the file FIGDIR/NAME.v cake NAME.idoc # do the electronic book action of figure NAME cake install # install programs in official place