imake - C preprocessor interface to the make utility
imake [-Ddefine] [-Idir] [-Ttemplate]
[-f filename] [-s filename] [-e ] [ -v]
The imake(1) utility is used to generate Makefiles from a template, a set of cpp(1) macro functions, and a per-directory input file called an Imakefile. This allows computer dependencies (such as compiler options, alternate command names, and special make rules) to be kept separate from the descriptions of the various items to be built.
The following command-line options may be passed to imake(1):
The imake(1) utility invokes cpp(1) with any -I or -D flags passed on the command line and passes it the following 3 lines:
#define IMAKE_TEMPLATE "Imake.tmpl"
#define INCLUDE_IMAKEFILE "Imakefile"
#include IMAKE_TEMPLATE
where Imake.tmpl and Imakefile may be overridden by
the -T and -f command options, respectively.
The IMAKE_TEMPLATE typically reads in a file containing machine-dependent parameters (specified as cpp(1) symbols), a site-specific parameters file, a file defining variables, a file containing cpp(1) macro functions for generating make rules, and finally the Imakefile (specified by INCLUDE_IMAKEFILE) in the current directory. The Imakefile uses the macro functions to indicate what targets should be built; imake(1) takes care of generating the appropriate rules.
The imake(1) utility configuration files contain two types of variables: imake variables and make variables. The imake variables are interpreted by cpp when imake(1) is run. By convention they are mixed case. The make variables are written into the Makefile for later interpretation by make. By convention make variables are upper case.
The rules file (usually named Imake.rules in the configuration directory) contains a variety of cpp(1) macro functions that are configured according to the current platform. The imake(1) utility replaces any occurrences of the string @@ with a newline to allow macros that generate more than one line of make rules. For example, the macro
#define program_target(program, objlist) @@\
program: objlist @@\
$(CC) -o $@ objlist $(LDFLAGS)
foo: foo1.o foo2.o
$(CC) -o $@ foo1.o foo2.o $(LDFLAGS)
On systems whose cpp(1) reduces multiple tabs and spaces to a single space, imake(1) attempts to put back any necessary tabs (make(1) is very picky about the difference between tabs and spaces). For this reason, colons (:) in command lines must be preceded by a backslash (\).
The X Window System uses imake(1) extensively, for both full builds within the source tree and external software. As mentioned previously, two special variables, TOPDIR and CURDIR, are set to make referencing files using relative path names easier. For example, the following command is generated automatically to build the Makefile in the directory lib/X/ (relative to the top of the sources):
% ../.././config/imake -I../.././config \
-DTOPDIR=../../. -DCURDIR=./lib/X
When building X programs outside the source tree, a special symbol UseInstalled is defined and TOPDIR and CURDIR are omitted. If the configuration files have been properly installed, the script xmkmf(1) may be used.
Here is a summary of the files read by imake(1) as used by X. The indentation shows what files include what other files.
Imake.tmpl generic variables
site.def site-specific, BeforeVendorCF defined
*.cf machine-specific
*Lib.rulesshared library rules
site.def site-specific, AfterVendorCF defined
Project.tmplX-specific variables
*Lib.tmplshared library variables
Imake.rules rules
Imakefile
Library.tmpllibrary rules
Server.tmpl server rules
Note that site.def gets included twice, once before the *.cf file and once after. Although most site customizations should be specified after the *.cf file, some, such as the choice of compiler, need to be specified before, because other variable settings may depend on them.
The first time site.def is included, the variable BeforeVendorCF is defined, and the second time, the variable AfterVendorCF is defined. All code in site.def should be inside an #ifdef for one of these symbols.
The imake(1) utility uses the following files:
The following environment variables may be set; however, their use is not recommended as they introduce dependencies that are not readily apparent when imake(1) is run:
Todd Brunhoff, Tektronix and MIT Project Athena; Jim Fulton, MIT X Consortium
S. I. Feldman, Make A Program for Maintaining Computer Programs