If you don't understand clearmake's build-avoidance decisions, use the -v (somewhat verbose) or -d (extremely verbose) option. Equivalently, set environment variable CLEARCASE_BLD_VERBOSITY to 1 or 2, respectively.

Typically, you do not edit a target's build script in the makefile very often. But you may often change the effective build script by specifying overrides for make macros, either on the command line or in the UNIX environment. For example, suppose target hello.o is specified as follows in the makefile.

hello.o: hello.c hello.h
      rm -f hello.o
      cc -c $(CFLAGS) hello.c

When it executes this build script, clearmake enters the effective build script, after macro substitution, into the config rec. The command:

% clearmake hello.o CFLAGS="-g -O1"
... produces this configuration record entry:
--------------------------------
Build script:
--------------------------------
        cc -c -g -O1 hello.c

So would this command:

env CFLAGS="-g -O1" clearmake -e hello

The clearmake build-avoidance algorithm compares effective build scripts. If you subsequently issue the command clearmake hello.o without specifying CFLAGS="-g -O1", clearmake will reject the existing derived object, which was built with those flags. The same mismatch would be caused by creating a CFLAGS environment variable (EV) with a different value, and invoking clearmake with the –e option.

clearmake's inclination to compare build scripts may produce undesirable results if your build environment includes more than one way to build a particular target. For example, there might be a test_prog_3 target in two directories:

... in its source directory, util_src:
test_prog_3: ...
      cc -o test_prog_3 ...
... and in another nearby directory, app_src:
../util_src/test_prog_3: ...
      cd ../util_src ; cc -o test_prog_3

Derived objects built with these scripts are potentially equivalent, because they are built at the same file name (test_prog_3) in the same VOB directory (util_src). But by default, a build in the app_src directory will never reuse or wink-in a DO built in the util_src directory, because build-script comparison fails.

You can suppress build-script comparison for this target using a clearmake special build target, either in the makefile or in an associated BOS file:

.NO_CMP_SCRIPT: ../util_src/test_prog_3

For a one-time suspension of build-script comparison, you can use clearmake -O.

It is easy to eliminate the different-build-scripts problem described in the preceding section. Figure 10-1 shows the recursive invocation of clearmake.

Figure 10-1. Recursive Invocation of clearmake

Now, target test_prog_3 is built the same way in both directories. You can turn build-script comparison on again, by removing the .NO_CMP_SCRIP special target.

Changes of this kind may cause unexpected encounters with another clearmake build-avoidance feature, however. Whenever clearmake executes the build script of a lower-level target, it always rebuilds all higher-level targets that depend on it. (Many make variants are not as insistent as clearmake in this regard.) In this example, the execution of the build script for target ../util_src/test_prog_3 may or may not actually build a new test_prog_3; but because clearmake has executed the build script, it will always rebuild a higher-level target that depends on ../util_src/test_prog_3:

TESTPROGS = ../util_src/test_prog_3 ../util_src/test_prog_7
TESTDATA  = test_input.1 test_input.2 test_input.3

test_output: $(TESTPROGS) $(TESTDATA)
	rm test_output
	../util_src/test_prog_3 test_input.1 >> test_output
	../util_src/test_prog_3 test_input.2 >> test_output
	../util_src/test_prog_3 test_input.3 >> test_output

Like other make variants, clearmake always executes the build script for a pseudo-target, a target that does not name a file system object built by the script. For example, in the preceding section, you might be tempted to use a pseudo-target in the app_src directory's makefile. Figure 10-2 provides an example of :

Figure 10-2. Build Script Example

A build of any higher-level target that has test_prog_3 as a build dependency will always build a new test_prog_3, which in turn triggers a rebuild of the higher-level target. If the rebuild of test_prog_3 was not really necessary, then the rebuild of the higher-level target may not have been necessary, either. Such unnecessary rebuilds decrease the extent to which you can take advantage of ClearCase's derived object sharing capability.

The fact that the ClearCase build utility has a unique name, “clearmake”, may conflict with existing build procedures that implement recursive builds. Most make variants automatically define the make macro $(MAKE) to be the name of the build program, as it was typed on the command line:

% make hello.o           .. sets MAKE to “make”
% clearmake hello.o      .. sets MAKE to “clearmake”
% my_make hello.o        .. sets MAKE to “my_make”

This enables recursive builds to use $(MAKE) to invoke the same build program at each level. The preceding section includes one such example; here is another one:

SUBDIRS = lib util src
all:
for DIR in $(SUBDIRS) ; do ( cd $$DIR ; $(MAKE) all ) ; done

Executing this build script with clearmake will recursively invoke clearmake all in each subdirectory.

Avoid “breaking” this mechanism by explicitly setting a particular build program in the makefile, or in a BOS file:

MAKE = make

With the above setting, executing the build script above with clearmake would recursively invoke make all (instead of clearmake all) in each subdirectory. Presumably, this would be an error.

Your view's view_server process interprets time rules with respect to the create version event record written by the checkin command. The checkin is read from the system clock on the host where the VOB resides. If that clock is seriously out-of-sync with the clock on your host (where the view_server runs), your attempt to roll back the clock may fail. Thus, don't strive for extreme precision with time rules: select a time that is well before the actual cutoff time (for example, a full hour before, or in the middle of the night).

Do not use time rules to “freeze” a view to the current time just before starting a build. Just allow clearmake's reference time facility to perform this service automatically. Here's an inappropriate use scenario: