Handling temporary changes in the build procedure

Learn how to handle temporary changes in the build procedure.

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

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

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

% clearmake hello.o CFLAGS="-g -O1"

It produces this configuration record entry:

--------------------------------
Build script:
--------------------------------        cc -c -g -O1 hello.c

So does this command:

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

The clearmake build-avoidance algorithm compares effective build scripts. If you then use the command clearmake hello.o without specifying CFLAGS="-g -O1", clearmake rejects the existing derived object, which was built with those flags. The same mismatch occurs if you create a CFLAGS environment variable with a different value, and then invoke clearmake with the -e option.

Specifying build options

To manage temporary overrides for make macros and environment variables, place macro definitions in build options specification (BOS) files. clearmake provides several ways for using a BOS file. For example, if your makefile is named project.mk, macro definitions are read from project.mk.options. You can also keep a BOS file in your home directory or specify one or more BOS files with clearmake -A. For more information, see Build options specification files.

Using a BOS file to specify make macro overrides preserves these options, which makes it easier to reuse them. If you do not modify the BOS file frequently, derived objects in your view are not disqualified for reuse on the basis of build script discrepancies.