The imake utility, distributed with many UNIX variants and available free-of-charge from MIT, provides an alternative to the scheme described in the preceding section. The imake methodology also involves architecture-specific make-macros, but in a different way. imake generates an architecture-specific makefile by running cpp on an architecture-independent template file, typically named imakefile.

A typical imakefile contains a series of cpp macros, each of which expands to a build target line and its corresponding multiline build script. Typically, the expansion itself is architecture-independent:

MakeObjectFromSrc(main)                (macro in `imakefile')
                               (expansion in actual makefile)
main.o: $(SRC)/main.c
       $(CC) -c $(CFLAGS) $(SRC)/main.c

imake places architecture-specific make-macro settings at the top of the generated makefile. For example:

SRC    = ..
CC     = /usr/5bin/cc
CFLAGS = -fsingle
RM     = rm -f

An idiosyncrasy of imake usage is that makefiles are derived objects, not source files. The architecture-independent template file (imakefile) is the source file, and should maintained as a ClearCase element.

Each variant of an application can be built in its own subdirectory of the source directory. For example, if executable monet's source files are located in directory /usr/monet/src, then the variants might be built in subdirectories /usr/monet/src/sun4, /usr/monet/src/irix5, and so on. It is simplest to have the makefile create view-private subdirectories for this purpose. But if you wish to use different derived object storage pools for the different variants, you must create the sudirectories as elements (mkdir command) and then adjust their storage pool assignments (chpool command).

Since the derived objects for the different variants are built at different pathnames (for example, /usr/monet/src/sun4/main.o), they are guaranteed to be segregated by variant, and clearmake will never wink-in an object built for another architecture.

This approach has several advantages:

But this approach may have the disadvantage of requiring build script changes: the binaries for a build are no longer in the source directory, but in a subdirectory. Note, however, that the build script in <Emphasis>Alternative Approach, Using `imake' is structured for just this situation:

main.o: $(SRC)/main.c
 .
 .

Perform builds for different platforms in different views (sun4_bld_vu, irix_bld_vu, and so on). A group of developers working on the same variant can share a view, or each can work in his or her own architecture-specific view.

In most cases, the build script that creates a derived object varies from variant to variant, as discussed in “Handling Build Procedure Differences”. If so, clearmake automatically prevents wink-in of derived objects built for another architecture. If this is not the case, force the build script to be architecture-specific by including a well-chosen message or comment. For example, if BLD_ARCH is used as described the “Handling Build Procedure Differences” section, you might include this message:

@echo "Building $@ for $(BLD_ARCH)"

This approach has the disadvantage that when an element is checked out, the developer can build only one variant of the application. Since the checked-out version is visible only in one view, builds of other variants (which take place in other views) do not “see” the checked-out version. The developer must checkin the element before building other variants.

Another disadvantage of this approach is a “combinatoric explosion” — if seven developers all wish to maintain their own views in which to build four variants, 28 views are required.

We will show how to set up multiple-architecture development in the /proj/monet/src directory. A developer will be able to perform a build for a particular architecture as follows:

The sections below describe the way in which imake is involved in each of these steps.

Step #1 places the developer in an environment where the C preprocessor, cpp, defines one or more architecture-specific symbols. On an SunOS–4 host, cpp defines the symbols sun and sparc. This, in turn, causes imake to generate many architecture-specific (“machine-dependent”) cpp macros (See Figure 14-1):

Figure 14-1. Defining Architecture-Specific CPP Macros

Additional Sun-specific cpp macros are read in from the auxiliary file sun.cf.

A file named Imakefile in the source directory is the imake input file. This file drives the creation of Makefiles both in the source directory itself, and in the architecture-specific subdirectories where software is actually built:

#ifndef InMachineDepSubdir
 .
 <code to generate Makefile in source directory>
 .
#else
 .
 <code to generate Makefile in an architecture-specific subdirectory>
 .
#endif

The Imakefile code used in the source directory simply defines a symbol to record the fact that builds will not take place in this directory:

#define IHaveMachineDepSubdirs

The resulting Makefile generated by imake includes a Makefiles target that populates an architecture-specific subdirectory with its own Makefile:

Makefiles::
    @echo "Making Makefiles in $(CURRENT_DIR)/$$CPU"
    -@if [ ! -d $$CPU ]; then \
        mkdir $$CPU; \
        chmod g+w $$CPU; \
    else exit 0; fi
    @$(IMAKE_CMD) -s $$CPU/Makefile \
    -DInMachineDepSubdir \
    -DTOPDIR=$(TOP) -DCURDIR=$(CURRENT_DIR)/$$CPU

---

Note: CPU environment variable determines name of architecture-specific subdirectory

---

The command clearmake Makefiles invokes imake once again, using the same Imakefile for input. This time, however, the symbol InMachineDepSubdir is defined, causing the actual build code to be generated.

The Imakefile in /proj/monet/src contains these macros:

OBJS = cmd.o main.o opt.o prs.o
LOCAL_LIBRARIES = ../../lib/libpub/libpub.a
MakeObjectFromSrc(cmd)
MakeObjectFromSrc(main)
MakeObjectFromSrc(opt)
MakeObjectFromSrc(prs)
ComplexProgramTarget(monet)

The resulting Makefile generated in the build directory, /proj/monet/src/sun4, includes this build script:

$(AOUT): $(OBJS) $(LOCAL_LIBRARIES)
    @echo "linking $@"
    -@if [ ! -w $@ ]; then $(RM) $@; else exit 0; fi
    $(CC) -o $@ $(OBJS) $(LOCAL_LIBRARIES) \
        $(LDFLAGS) $(EXTRA_LOAD_FLAGS)