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.