(Defined only when explicit rules from the makefile are evaluated) The list of dependencies that are out of date with respect to the target. When configuration lookup is enabled (default), it expands to the list of all dependencies, unless that behavior is modified with the .INCREMENTAL_TARGET special target. In that case, $? expands to the list of all dependencies different from the previously recorded versions.
A makefile contains a sequence of entries, each of which specifies a build target, some dependencies, and the build scripts of commands to be executed. A makefile can also contain make macro definitions, target-dependent macro definitions, and build directives (special targets.)
The list of dependencies may not need to include source objects, such as header files, because clearmake detects these dependencies. However, the list must include build-order dependencies, for example, object modules and libraries that must be built before executables.
A build script ends at the first nonempty line that does not begin with a <TAB> or number sign (#); this begins a new target/dependencies line or a make macro definition.
Build scripts must use standard path names only. Do not include view-extended or version-extended path names in a build script.
Executing a build script updates the target and is called a target rebuild. The commands in a build script are executed one at a time, each in its own instances of the subshell or command interpreter.
clearmake always completely eliminates a \<NL> sequence, even in its compatibility modes. Some other make programs sometimes preserve such a sequence—for example, in a UNIX and Linux sed(1) insert command:
You can use macros in makefiles or in BOS files. For more information, see BOS file entries.
A build options specification (BOS) file is a text file that contains macro definitions and/or ClearCase special targets. You can place temporary macros (such as CFLAGS=–g (UNIX and Linux) and CFLAGS=/Zi (Windows) ) into a BOS file rather than specifying them on the clearmake command line.
By default, clearmake reads BOS files in this order:
If you specify –N, clearmake does not read default BOS files.
clearmake displays the names of the BOS files it reads if you specify the –v or –d option, or if CCASE_VERBOSITY is set to 1.
For information about the contents of BOS files, see BOS file entries.
The following sections describe the special considerations for using makefiles with clearmake.
If a target or dependency name contains parentheses, it is assumed to be an archive (library) created by ar(1) (UNIX and Linux), lib (Windows), or some other librarian. The string within parentheses refers to a member (object module) within the library. Use of function names within parentheses is not supported.
lib.a : lib.a(mod1.o) lib.a(mod2.o)
Thus, lib.a(mod1.o) refers to an archive that contains object module mod1.o. The expression lib.a(mod1.o mod2.o) is not valid.
hello.lib : hello.lib(mod1.obj) hello.lib(mod2.obj)
hello.lib(mod1.obj) refers to an archive that contains mod1.obj. The expression hello.lib(mod1.obj mod2.obj) is not valid.
Inference rules for archive libraries have the form
where sfx is the file name extension (suffix) from which the archive member is to be made.
The way in which clearmake handles incremental archive construction differs from other make variants.
You can control the echoing of commands and the handling of errors that occur during command execution on a line-by-line basis, or on a global basis.
You can prefix one or two characters to any command, as follows:
The –k option provides for partial recovery from errors. If an error occurs, execution of the current target (that is, the set of commands for the current target) stops, but execution continues on other targets that do not depend on that target.
File name extensions (suffixes) and their associated rules in the makefile override any identical file name extensions in the built-in rules. clearmake reads built-in rules from the file builtin.mk when you run in standard compatibility mode. In other compatibility modes, other files are read.
If a line in a makefile starts with the string include or sinclude followed by white space (at least one <SPACE> or <TAB> character), the rest of the line is assumed to be a file name. (This name can contain macros.) The contents of the file are placed at the current location in the makefile.
For include, a fatal error occurs if the file is not readable. For sinclude, a nonreadable file is silently ignored.
By default, the order of precedence of macros and environment variables is as follows:
For example, target-dependent macro definitions override all other macro definitions, and macros specified on the clearmake command line override those set in a BOS file.
If you use the –e option to clearmake, environment variables override macro definitions in the makefile.
All BOS file macros (except those overridden on the command line) are placed in the build script's environment. If a build script recursively invokes clearmake:
For a list of build-related environment variables, see the IBM Rational ClearCase Guide to Building Software.
A macro definition takes this form:
Macros can appear in the makefile, on the command line, or in a build options specification file. (See Build options specification files.)
Macro definitions require no quotes or delimiters, except for the equal sign (=), which separates the macro name from the value. Leading and trailing white space characters are stripped. Lines can be continued using a \<NL> sequence; this sequence and all surrounding white space is effectively converted to a single <SPACE> character. macro_name cannot include white space, but string can; it includes all characters up to an unescaped <NL> character.
clearmake performs macro substitution whenever it encounters either of the following in the makefile:
$(macro_name)
$(macro_name:subst1=subst2)
It substitutes string for the macro invocation. In the latter form, clearmake performs an additional substitution within string: all occurrences of subst1 at the end of a word within string are replaced by subst2. If subst1 is empty, subst2 is appended to each word in the value of macro_name. If subst2 is empty, subst1 is removed from each word in the value of macro_name.
For example, on UNIX or Linux:
% cat Makefile
C_SOURCES = one.c two.c three.c four.c
test:
echo "OBJECT FILES are: $(C_SOURCES:.c=.o)"
echo "EXECUTABLES are: $(C_SOURCES:.c=)"
% clearmake test
OBJECT FILES are: one.o two.o three.o four.o
EXECUTABLES are: one two three four
z:\myvob> type Makefile
C_SOURCES = one.c two.c three.c four.c
test:
echo OBJECT FILES are: $(C_SOURCES:.c=.obj)
echo EXECUTABLES are: $(C_SOURCES:.c=.exe)
z:\myvob> clearmake test
OBJECT FILES are: one.obj two.obj three.obj four.obj
EXECUTABLES are: one.exe two.exe three.exe four.exe
clearmake maintains these macros internally. They are useful in rules for building targets.
The VPATH macro specifies a search path for targets and dependencies. clearmake searches directories in VPATH when it fails to find a target or dependency in the current working directory. clearmake searches only in the current view. The value of VPATH can be one directory path name or a list of directory path names separated by colons (UNIX and Linux) or semicolons (Windows). (In Gnu compatibility mode, you can also use spaces as separators.)
Configuration lookup is VPATH-sensitive when qualifying makefile dependencies (explicit dependencies in the makefile). Thus, if a newer version of a dependent file appears in a directory on the search path before the path name in the CR (the version used in the previous build), clearmake rejects the previous build and rebuilds the target with the new file.
The VPATH setting may affect the expansion of internal macros, such as $<.
Like other build tools, clearmake interprets certain target names as declarations. Some of these special targets accept lists of patterns as their dependents, as noted in the description of the target. Pattern lists may contain the pattern character, %. When evaluating whether a name matches a pattern, the tail of the prefix of the name (subtracting directory names as appropriate) must match the part of the pattern before the %; the file name extension of the name must match the part of the pattern after the %. For example:
|
/dir/subdir/x.o |
%.o x.o subdir/%.o subdir/x.o |
/dir/subdir/otherdir/x.o |
|
\dir\subdir\x.obj |
%.obj x.obj subdir\%.obj subdir\x.obj |
\dir\subdir\otherdir\x.obj |
The following targets accept lists of patterns:
You can use the following special targets in the makefile.
You can use the following special targets either in the makefile itself or in a build options specification file. See Build options specification files.
You can specify the list of files with a tail-matching pattern; for example, Templates.DB/%.module (UNIX and Linux) or %.module (Windows).
Unlike the files listed in most special targets, the files on this list refer to the names of dependencies and not the names of targets. As such, the special target may apply to the dependencies of many targets at once. This special target is most useful when identifying a class of dependencies found in a particular toolset for which common behavior is desired across all targets that have that dependency.
This target takes one or more (white-space-separated) directory path names. You can specify the path names with a %tail-matching pattern.
This target takes one or more (white-space-separated) directory path names. You can specify the path names with a %tail-matching pattern.
This special target has an equivalent environment variable called CCASE_DIR_IGNORED_REUSE, which takes no arguments, but is either on or off. If on, this environment variable overrides the build avoidance treatment of all declared directory dependencies.
You can specify the list of files with a tail-matching pattern; for example, %.pdb.
Unlike the files listed in most special targets, the files on this list refer to the names of sibling objects and not the names of targets. As such, the special target may apply to the siblings of many targets at once. This special target is most useful when identifying a class of siblings found in a particular toolset for which common behavior is desired across all targets that have that sibling.
You can specify the list of files with a tail-matching pattern; for example, %.a or %.lib.
The general guideline is that if you're not building a library in a single makefile rule and you're not building an executable using an incremental linker, then you should not use .INCREMENTAL_TARGET.
In the makefile, any file name that matches the pattern allows a $ to be escaped by another $. For example, to specify a$x.class:
.JAVA_TGTS: %.class
.java.class:
javac $<
a$$x.class: a.class
Note that $$ mapping to a single $ is default behavior in Gnu make compatibility mode.
You can specify the list of files with a tail-matching pattern; for example, %.class.
Use this special target to enable clearmake to use heuristics on audits of Java builds to accurately evaluate .class dependencies. These dependencies are then stored in .class.dep files for future clearmake runs, and they enable those runs to build .class targets in the same order that the Java compiler does.
This special target must be used with no dependencies and no build script:
JAVAC:
Other than that, makefiles must use implicit suffix or pattern rules. For example:
.SUFFIXES: .java .class .java.class:
rm -f $@
$(JAVAC) $(JFLAGS) $<
For compatibility modes that support them, use implicit pattern rules. For example:
%.class: %.java
rm -f $@
$(JAVAC) $(JFLAGS) $?
The makefiles must also use absolute paths for .class targets. Clearmake contains a built-in macro function you can use to specify absolute paths:
$(javaclasses)
By default, makefiles recorded by using the .MAKEFILES_IN_CONFIG_REC special target do not affect DO reuse. You can use the .MAKEFILES_AFFECT_REUSE target to enable recorded makefiles to affect DO reuse. (If you want to have some recorded makefiles affect reuse, but not all, you can also use the .DEPENDENCY_IGNORED_FOR_REUSE special target in conjunction with this target.)
Makefiles recorded in a configuration record are labeled by mklabel -config. Makefiles that were recorded in a configuration record but not recorded by using .MAKEFILES_AFFECT_REUSE are ignored by catcr -critical_only and diffcr -critical_only.
You can use this special target to record the versions of makefiles in the configuration records of derived objects.
This target takes an optional dependency list, which might be a pattern. When used without a dependency list, this target causes all makefiles read by a build session to be recorded in the configuration record of all derived objects built during that build session.
To conserve disk space, you may want to supply a dependency list to this target so that, for example, only DOs built for top-level targets have the makefiles recorded in their configuration records.
You can specify the list of files with a tail-matching pattern; for example, %.o.
You can specify the list of files with a tail-matching pattern; for example, %.o.
This special target takes one or more (white-space-separated) target path names. You can specify the path names with a %tail-matching pattern.
You can specify the list of files with a tail-matching pattern; for example, %.o.
You can specify the list of files with a tail-matching pattern; for example, ptrepository/_% (UNIX and Linux) or %.tmp (Windows).
Unlike the files listed in most special targets, the files on this list refer to the names of sibling objects and not to the names of targets. As such, the special target may apply to the siblings of many targets at once. This special target is most useful when identifying a class of siblings found in a particular toolset for which common behavior is desired across all targets that have that sibling.
This special target suppresses the creation of derived object for any file that lives in or beneath a specified directory. For example, if the makefile has the following targets:
.NO_SIBLING_DO_CONTAINED_IN: sun5/%
objs/sun5/a.o: src/a.c
cc -o $@ -c $<
objs/sun5/subdir/a2.o: src/a2.c
cc -o $@ -c $<
objs/b.o: src/b.c
cc -o $@ -c $<
then the written files named a.o and a2.o do not become DOs, but the file b.o does.
If a makefile contains the following:
.NO_SIBLING_DO_CONTAINED_IN: subdir%
all: subdir1/T1 subdir2/T2
subdir1/T1:
touch $@
touch $@.sibling
subdir2/T2:
touch $@
touch $@.sibling
then subdir1/T1 and subdir2/T2 become derived objects, but subdir1/T1.sibling and subdir2/T2.sibling do not.
This target takes one or more (white space-separated) directory path names. You can specify the path names with a %tail-matching pattern.
You can specify the list of files with a tail-matching pattern; for example, %.o.
You can specify the list of files with a tail-matching pattern; for example, Templates.DB/%.module (UNIX and Linux) or %.sbr (Windows).
Unlike the files listed in most special targets, the files on this list refer to the names of sibling objects and not the names of targets. As such, the special target may apply to the siblings of many targets at once. This directive is most useful when identifying a class of siblings found in a particular toolset for which common behavior is desired across all targets that have that sibling.
You can use the following target only in BOS files or makefiles on UNIX or Linux.
.NOTPARALLEL:%.a
NOTPARALLEL:foobar
clearmake does not build any .a file in parallel with any other .a file, and foo is not built in parallel with bar. However, clearmake may build .a files in parallel with foo or bar.
.NOTPARALLEL does not affect lower-level builds in a recursive make, unless you specify it in the makefiles for those builds or include it in a BOS file.
You can specify the list of files with a tail-matching pattern; for example, %.a.
Because snapshot views do not make use of the MVFS, absolute VOB path names (for example, /vobs/tools/foo.h) are not supported in snapshot views on UNIX or Linux. For that reason, your makefiles must not include absolute VOB path names.
To eliminate absolute VOB path names from makefiles, use the pwv –root command to get the value of the current view-root directory. Use that value in one of the following methods:
VWROOT=‘cleartool pwv -root‘
TOOLS=$(VWROOT)/vobs/tools
The method shown in this example works for any clearmake compatibility mode. There are also methods specific to each compatibility mode. See your make documentation for more information.
clearmake is available on both Windows and UNIX or Linux. In principle, you can write portable makefiles, but in practice, the obstacles are substantial. The variations in tool and argument names between systems makes writing portable build scripts particularly challenging. If you choose to pursue portable makefiles, use the following general procedures to produce usable results:
There are several rules to follow when constructing, or converting, makefiles for use by clearmake on a Windows host. Note that, as a general rule, your makefiles must match the syntax required by clearmake on UNIX or Linux.
The following sections describe how you must specify build macros, targets, and dependencies in makefiles to avoid case problems.
clearmake is case-sensitive with respect to makefile macros. Consider a makefile macro reference, $(CPU). There are numerous input sources from which to satisfy this macro:
For any macro to be expanded correctly from any of these sources, the macro definition and macro reference must be in the same case. For example, $(CPU) is not replaced by the value of an EV named CPU.
When you write makefiles, you must be aware of the MVFS setting on your computer and specify targets and dependencies accordingly. If the MVFS is case-preserving, you must use case-correct path names in makefiles to guarantee the consistency of the resulting config records. Even if your MVFS is not case-preserving, use case-correct path names so that users on case-preserving computers can share the makefile.
Table 1 describes makefile requirements for the different MVFS settings.
It is possible, but not trivial, to prepare makefiles that can be used with either omake or clearmake. The general approach is to supply omake-specific macro definitions in the makefile, and to supply clearmake-specific macro overrides in a build options specification (BOS) file; clearmake reads the BOS file, but omake does not. When clearmake executes, it looks for macro definitions in two locations:
BOS files at other locations can be passed to clearmake with the –A option.
On Windows, clearmake accepts either slashes ( / ) or backslashes ( \) in path names. However, clearmake uses a backslash as the separator in any path names that it constructs in build scripts (for example, as a result of VPATH directory searching). This can cause problems with command shells that require slashes in any path names supplied to them in command lines.
If you are using such a shell (for example, by setting the SHELL makefile variable accordingly), you can force clearmake to use slashes when constructing path names. To do this, set the CMAKE_PNAME_SEP variable:
CMAKE_PNAME_SEP = /
You can set CMAKE_PNAME_SEP in the makefile, in the BOS file, on the command line, or as an environment variable.
The following sections describe the entries you can put in BOS files.
A standard macro definition has the same form as a make macro defined in a makefile:
For example, on UNIX or Linux:
and on Windows:
A target-dependent macro definition takes this form:
target-pattern-list := macro_name = string
Any standard macro definition can follow the := operator; the definition takes effect only when targets matching patterns in target-pattern-list and their dependencies are processed. Patterns in the target-pattern-list must be separated by white space. For example, on UNIX or Linux:
On Windows:
foo.o bar.o := CDEBUGFLAGS=/Zi
Two or more higher-level targets can have a common dependency. If the targets have different target-dependent macro definitions, the dependency is built using the macros for the first higher-level target clearmake considered building (whether or not clearmake actually built it).
A shell command macro definition replaces a macro name with the output of a shell command:
This defines the value of macro_name to be the output of string, any shell command. In command output, <NL> characters are replaced by <SPACE> characters. For example, on UNIX or Linux:
On Windows:
You can use some ClearCase special targets in a build options spec. See Special targets.
clearmake, clearmake.options, makefile_aix, makefile_gnu, makefile_sun, omake, IBM Rational ClearCase Guide to Building Software