Macros

Order of precedence of make macros and environment variables

By default, the order of precedence of macros and environment variables is as follows:

1. Target-dependent macro definitions
2. Macros specified on the clearmake command line
3. Make macros set in a BOS file
4. Make macro definitions in a makefile
5. Environment variables

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 environment of a build script. If a build script recursively invokes clearmake:

• The higher-level BOS file setting (now transformed into an EV) is overridden by a make macro set in the lower-level makefile. However, if the recursive invocation uses the -e option of clearmake, the BOS file setting prevails.
• If another BOS file (associated with another makefile) is read at the lower level, its make macros override those from the higher-level BOS file.

For a list of all environment variables, see the env_ccase reference page.

Make macros

A macro definition takes this form:

macro_name = string

Macros can appear in the makefile, on the command line, or in a build options specification file. (For more information, 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 are 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:

% 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

Internal macros

Internal macro is a type of macro.

clearmake maintains these macros internally. They are useful in rules for building targets.

$*

(Defined only for inference rules) The file name part of the inferred dependency, with the file name extension deleted.

$@

The full target name of the current target.

$<

(Defined only for inference rules) The file name of the implicit dependency.

$?

(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.

When a dependency is an archive library member of the form lib(file.o), the name of the member, file.o, appears in the list.

$%

(Defined only when the target is an archive library member) For a target of the form lib(file.o), $@ evaluates to lib and $% evaluates to the library member, file.o.

MAKE

The name of the make processor (that is, clearmake). This macro is useful for the recursive invocation of clearmake.

MAKEFILE

During makefile parsing, this macro expands to the path name of the current makefile. After makefile parsing is complete, it expands to the path name of the last makefile that was parsed. This holds only for top-level makefiles, not for included makefiles or for built-in rules; in these cases, it echoes the name of the including makefile.

Use this macro as an explicit dependency to include the version of the makefile in the CR produced by a target rebuild. For example:

supersort: main.o sort.o cmd.o $(MAKEFILE)

cc -o supersort ...

For more information, see Including a makefile version in a configuration record.

MAKEFLAGS

This macro passes flags to sub-makes, including flags that take arguments and macro definitions. clearmake reads the contents of MAKEFLAGS at startup and amends it to include any flags not specific to HCL VersionVault passed at the command line. Any flags specific to VersionVault are passed through CCASE_MAKEFLAGS and if clearmake detects these flags in MAKEFLAGS, it moves them to CCASE_MAKEFLAGS. You can use the CCASE_MAKEFLAGS environment variable as an alternative mechanism for specifying clearmake commands. CCASE_MAKEFLAGS allows clearmake to be used in recursive builds that use both clearmake and native makefile programs. Options of the clearmake command line override the CCASE_MAKEFLAGS environment variable.

Flags passed through MAKEFLAGS:

-I, -p, -N, -w, -e, -r, -i, -k, -n, -q, -s

Flags passed through CCASE_MAKEFLAGS:

-A, -B, -N, -b, -v, -C, -U, -M, -V, -O, -T, -F, -R, -c, -u, -d

This functionality is available for all compatibility modes.

VPATH macro

This is a type of macro.

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 colon-separated list of directory path names. (In the Gnu compatibility mode, you can also use spaces as separators.)

As clearmake qualifies makefile dependencies (explicit dependencies in the makefile), the process of configuration lookup is VPATH-sensitive. 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 might affect the expansion of internal macros, such as $<.