make -- maintain program-generated and interdependent files

SYNOPSIS

make [-EeiMnpqrstuVvx] [-k|-S] [-c dir] [-f file] [-D macro definition ...] [macro definition ...] [target ...]

make is a command that helps you manage projects that contain a set of interdependent files. Typical examples would be a program with many source and object files, or a document that is built from source files, macro files, and so on. make keeps all the files up-to-date with one another: if one file changes, make updates all the other files that depend on the changed file.

Note:: This implementation of make features the .POSIX special target to provide maximum portability. When you specify this target, make processes the makefile as specified in the POSIX.2 standard. For details, see the description of .POSIX in the Special Target Directives section of this reference page.

Options

-c dir

attempts to change to the specified directory upon startup. If make cannot change the directory, it displays an error message. This is useful for recursive makefiles when building in a different directory.

-D macro definition

defines macro on the command line before reading any makefile. Use the same form as a normal macro definition (macro=string). If you use this option, make assigns the value to the macro before reading the makefile; any definition of the same macro contained in the makefile supersedes this definition. Note that make uses any macros defined in this way before it reads any makefile, including the startup file. This allows you to define a startup file by providing a value for MAKESTARTUP on the command line:

make -D MAKESTARTUP=$HOME/project/startup.mk

-E

suppresses the reading of the environment completely.

-e

reads the environment after reading the makefile. If you do not specify -E or -e, make reads the environment before reading the makefile, except for the SHELL environment variable, which you must explicitly import. This option does not affect the value of MAKEFLAGS.

-f file

uses file as the makefile, ignoring the makefiles specified as prerequisites to the .MAKEFILES special target. If you specify file as dash (-), make reads from standard input.

-i

ignores all errors and continues making other targets. This is equivalent to the .IGNORE attribute or macro.

-k

makes all independent targets, even if an error occurs. If you specify -k, make ignores the error and continue to make as much as possible. make does not attempt to update anything that depends on the target that was being made when the error occurred.

-M

does not copy macro definitions from the command line and the MAKEFLAGS environment variable to the MAKEFLAGS macro.

-n

displays the commands that make would execute to update the chosen targets, but does not actually execute any recipe lines unless they have a plus sign (+) command prefix. make displays recipe lines with an at sign (@) command prefix on the standard output.

With group recipes, make displays the commands it uses to update a give target, but it also executes the commands.

If make finds the string $(MAKE) in a recipe line, it expands it, adds -n to the MAKEFLAGS, and then executes the recipe line. This allows you to see what recursive calls to make do. The output correctly shows line breaks in recipes that are divided into several lines of text using the \<newline> sequence.

-p

displays the digested makefile, including macro and target definitions, in a human readable form useful for debugging. make itself cannot read this output as an input file.

-q

checks whether the target is up-to-date. If it is, make exits with a status of 0; otherwise, it exits with a status of 1 (typically interpreted as an error by other software). make does not run commands associated with the target unless they start with a plus sign (+) command prefix.

-r

does not read the default rules from the startup file.

-S

terminates make if an error occurs when bringing a target up-to-date (opposite of -k). This is the default.

-s

does not display recipe commands, warning messages, or touch messages (see the -t option). This is equivalent to the .SILENT attribute or macro.

-t

touches the targets to mark them as up-to-date, but only execute commands to change a target if the target has a plus sign (+) command prefix. make does not touch up-to-date targets or targets that have prerequisites but do not have recipes. make displays a message for each touched target file indicating the file name.

-u

forces an unconditional update: make behaves as if all the prerequisites of the given target are out-of-date.

-V

displays the version number of make and a list of built-in rules.

-v

displays a detailed account of make's progress, including files read, definition and redefinition of each macro, meta-rule and suffix rule searches, and other information.

-x

exports all macro definitions to the environment. This happens before make begins making targets (but after it reads the entire makefile).

Targets

A target is normally a file that you want to ensure is up-to-date with the files that it is dependent on. For example, you may want to check to see if a is based on the most recent version of the corresponding source code and if not, recompile the source code to get an up-to-date version. In this case, the compiled program file is the target and the corresponding source code files are prerequisites (that is, the files a target is dependent on).

make updates all targets that are specified on the command line. If you do not specify any target, make updates the targets in the first rule of the makefile. A target is out-of-date if it is older than any of its prerequisites (based on modification times) or if it does not exist. To update a target, make first recursively ensures that all the target's prerequisites are up-to-date, processing them in the order they appear in the rule. If the target itself is out-of-date, make then executes the recipe associated with the target. If the target has no associated recipe, make considers it up-to-date.

make also supports another form of targets, known as special targets, described in the following Special Target Directives section.

Makefiles

A makefile is a text file that describes the dependencies between various files. A makefile normally contains a list of targets and identifies the prerequisites each depends on. It also contains a series of instructions, called recipes that describe the actions to be taken if a given target is out-of-date with its prerequisites.

By default, if you do not specify the -f option, make looks for a file in your current directory named makefile. If make does not find this file, and if your file system supports mixed case file names, it searches your current directory for a file named Makefile. If make finds either file, it uses this file as your makefile.

You can change the default makefiles with the .MAKEFILES special target. This target is already specified in the startup.mk file. See the following Special Target Directives section for more information.

Macro Definitions

Macro definitions may take several forms.

macro = string

is the usual form. If string contains macro references, make does not expand them when the macro is defined, but when the macro is itself expanded.

macro := string

expands macros inside string before assigning the value to macro.

macro += string

appends string to the previous value of macro.

You can use any amount of white space on both sides of macro operators. make defines the name macro to have the value string and replaces it with that value whenever it is used as $(macro or ${macro} within the makefile. It is possible to specify a $(macro_name or ${macro_name} macro expansion where macro_name contains more $(...) or ${...} macro expansions itself.

Normally, make does not include white space at the beginning and end of string in the definition of macro; however, it never strips white space from macros imported from the environment.

If you want to include white space in a macro definition specified on the make command line, you must enclose the definition in quotes (" ").

make defines macros in the following order:

Macro definitions in the built-in rules.

Macro definitions on the command line associated with the -D option.

Macro definitions in startup files.

Contents of the environment.

Macro definitions in the makefiles (in the order they appear).

Macro definitions on the command line without the -D option.

Note:: If you specify the -e option, make reads the makefiles before reading the contents of the environment. If you specify the -E option, make does not read the contents of the environment.

If a macro is already defined when make encounters a new definition for it, the new definition replaces the old one. For example, a macro definition for name on the command line (without -D) overrides a definition for name in the makefile. You can use the -v option to display macro assignments, as make performs them.

Macro Modifiers

MKS Make supports macro expansions of the form:

$(macro_name:modifier_list:modifier_list:...)

Possible modifiers are:

^"string": prefix tokens
+"string" suffix tokens b file portion of all path names, without suffix d directory portion of all path names f file portion of all path names, including suffix l all characters mapped to lowercase s/pat/string/ simple pattern substitution; any character can be used to separate the pattern from the substitution text suffix=string suffix replacement t"separator" tokenization with given separator. u all characters mapped to uppercase

You may specify macro modifiers in either uppercase or lowercase.

For example, the following macro assignment

test = D1/D2/d3/a.out f.out d1/k.out

produces the following expansions:

$(test:d)         -> D1/D2/d3 . d1
$(test:b)         -> a f k
$(test:f)         -> a.out f.out k.out
${test:DB}        -> D1/D2/d3/a f d1/k
${test:s/out/in/} -> D1/D2/d3/a.in f.in d1/k.in
$(test:f:t"+")    -> a.out+f.out+k.out
$(test:t"+")      -> D1/D2/d3/a.out+f.out+d1/k.out
$(test:u)         -> D1/D2/D3/A.OUT F.OUT D1/K.OUT
$(test:l)         -> d1/d2/d3/a.out f.out d1/k.out
$(test:^"/rd/")   -> /rd/D1/D2/d3/a.out /rd/f.out /rd/d1/k.out
$(test:+".Z")     -> D1/D2/d3/a.out.Z f.out.Z d1/k.out.Z

Run-time Macros

Run-time macros can take on different values for each target.

$@

When building a normal target, this macro evaluates to the full name of the target. When building a library, it expands to the name of the archive library. For example, if the target is

mylib(member)

$@ expands to

mylib.

$%

When building a normal target, this macro evaluates to the full name of the target. When building a library, it expands to the name of the archive member. For example, if the target is

mylib(member)

$% expands to

member

$>

The name of the library if the current target is a library member.

$*

The target name with no suffix ($(%:db)) or the value of the stem in a meta-rule.

$&

The list of all prerequisites, in all rules that apply to the target. In :: rules, this macro produces a value identical to the $^ macro.

$?

The list of all prerequisites that are newer than the target or do not yet exist and need to be built. In rules using the :: rule operator, this macro expands to the same value as $<.

$^

The list of all prerequisites taken from the list specified on the rule line of the recipe where the $^ symbol appears.

$<

In normal rules, this contains the list of all prerequisites in the rule line where \*MACRO $<] appears that are newer than the target or do not yet exist and need to be built. In inference rules, this contains the single prerequisite that caused the inference to succeed. In rules using the :! rule operator, this macro expands to the current out-of-date prerequisite.

You can modify the run-time macros with the letters B, D and F to indicate only the directory portion of the target name (the current directory is represented by a dot (.)), or only the file portion of the target name. For example, define.h is the only out-of-date prerequisite, the macros $(?B), $(?D) and $(?F) expand to define, dot (.) and to define.h, respectively.

The constructs $$@, $$%, $$>, and $$* yield meaningful results when placed in a prerequisite list as a dynamic prerequisite.

$$@ stands for the target currently being made. The following two examples are equivalent:

fred : $$@.c
fred : fred.c

The construct may be modified:

fred.obj : $$(@:b).c

If you are building a library, $$% stands for the name of the archive member being made. If you are building a normal target, $$% stands for the name of the target currently being made.

$$* stands for the name of the current target being made, but with no suffix.

If you are building a library, $$> stands for the name of the archive library being made. If you are not building a library, its use is invalid.

Comments

Comments begin with the number sign (#) character and extend to the end-of-line. make discards all comment text.

Makefile Contents

Inside makefiles, you can split long lines over several lines of text. To do this, put a backslash (\) at the very end of the line. You can use this technique to extend comments as well as recipe lines and macro definitions for example.

If a rule or macro definition must contain a # character, use \#; otherwise, make mistakes the # for the beginning of a comment. Also, if a macro definition must contain a single $ character, use $$.

File names that contain a colon (:) must always be enclosed in quotes (" "):

"a:target" : "a:prereq"

Rules

The general format of a rule is

targets [attributes] ruleop [prerequisites] [;recipe]
{<tab> recipe}

The parts of the rule are described as follows.

targets: one or more target names.
attributes: a list, possibly empty, of attributes to apply to the list of targets.
ruleop: an operator token, usually :, that separates the target names from the prerequisite names and may also affect the processing of the specified targets.
prerequisites: a list of zero or more names the specified targets depend on.
recipe: command to execute to update targets. It may follow on the same line as the prerequisites, separated from them by a semicolon (;). If such a recipe is present, make takes it as the first in the list of recipe lines defining how to make the named targets. Additional recipe lines may follow the first line of the rule. Each subsequent recipe line must begin with a tab character.

The possible rule operators are described here:

targets : prereqs

simple rule definition. For explicit targets, at most one simple rule may have a recipe, in contrast with the :: rule operator, whose description follows.

targets :! prereqs

executes the recipe for the associated targets once for each out-of-date prerequisite. In simple rules, the recipe is executed only once, for all out-of-date prerequisites at the same time. The $< macro expands to the current prerequisite if it appears in rules with this rule operator.

targets :^ prereqs

inserts the specified prerequisites before any other prerequisites already associated with the specified targets.

targets :- prereqs

clears the previous list of prerequisites before adding the new prerequisites.

targets :: prereqs

is used for multiple rules applying to the same target. Each rule can specify a different set of prerequisites with a different recipe for updating the target. Each rule is treated independently; the target is remade for each rule with out-of-date prerequisites, using the corresponding recipe.

targets :| prereqs

can only be used in meta-rules. It tells make to treat each meta-dependency as an independent meta-rule. For example:

%$O :| archive/%.c rcs/%.c /srcarc/RCS/%.c
	recipe...

is equivalent to

%$O : archive/%.c
	recipe...
%$O : rcs/%.c
	recipe...
%$O : /srcarc/rcs/%.c
	recipe...

This operator is particularly useful for searching for PTC Windchill Requirements and Validation archives. If the RCSPATH variable used by PTC Windchill Requirements and Validation is defined as

archive/%f;rcs/%f;/srcarc/rcs/%f

then the meta-rule

% :| $(RCSPATH:s/%f/%/:s/;/ /)
	co -l $<

searches the path looking for an RCS file and checks it out.

Circular Dependencies

There are two types of circular dependencies: within-rule and between-rule. A within-rule circular dependency occurs when the target's name is included in the list of prerequisites for that target. For example,

c.o : a.o b.o c.o

is a within-rule circular dependency. make detects a within-rule circular dependency when it is parsing the makefile to build the dependency tree.

A between-rule circular dependency occurs when you have two targets, each of which includes the other's name in its prerequisite list. For example,

a.o : b:o
b:o : a.o

is a between-rules circular dependency. make detects a between-rule circular dependency when it is processing the dependency tree built during the parse phase.

Normally make only detects circular dependencies for those targets actually being built. When a circular dependency is encountered, make issues a warning message, removes the offending prerequisite from the list, and continues parsing the makefile. The .CYCLECHECK special target can be used to alter make's treatment of circular dependencies. For details, see the Special Target Directives section of this reference page.

Recipes

You can use a target that has prerequisites but no recipes to add the given prerequisites to that target's list of prerequisites.

You may preface any recipe line with a command prefix immediately following the <tab> character (-, @, + or all three). - indicates that make is to ignore non-zero exit values when it executes this recipe line. @ indicates that make is not to display the recipe line before executing it. + tells make to always execute this line, even when -n, -q, or -t is specified.

Group recipes begin with [ in the first non-white space position of a line, and end with ] in the first non-white space position of a line. Recipe lines in a group recipe need not have a leading tab. make executes a group recipe by feeding it as a single unit to a shell. If you immediately follow the [ at the beginning of a group recipe with one of -, @ or +, they apply to the entire group in the same way that they apply to single recipe lines.

Inference Rules

With inference rules, you can specify general rules for building files rather than creating a specific rule for each target.

MKS Make provides two forms of inference rules: suffix rules and meta-rules. MKS Make includes suffix rules to ensure compatibility with older makefiles. Meta-rules, however, provide a more general mechanism for specifying make's default behavior. They provide a superset of the functionality of suffix rules. make searches all meta-rules before using suffix rules.

make uses the inference rules to infer how it can bring a target up to date. A list of inference rules defines the commands to be executed. The default startup.mk contains a set of inference rules for the most common targets. You can specify additional rules in the makefile.

When make finds no explicit target rule to update a target, it checks the inference rules. If make finds an applicable inference rule with an out-of-date prerequisite, it executes that rule's recipe. (See also the section describing the .DEFAULT special target).

Meta-rules

Meta-rules have one target with a single percent symbol % that matches an arbitrary string called the stem. The % in a dependency stands for the stem.

The inference rule to update a target matching pattern p1%s1, where p1 and s1 are prefix and suffix strings of the target, having a prerequisite p2%s2, where % is the stem from the target, is specified as follows:

p1%s1 : p2%s2 ; recipe...

Either the prefix or suffix string may be empty.

Transitive Closure

Meta-rules provide a mechanism that allows several meta-rules to chain together to eventually infer all the needed prerequisites to create the target.

This is called transitive closure. For example, suppose you have the following two meta-rules

%$O : %.c
	... rule body... 
%.c : %.y
	... rule body ...

When you specify

make file.obj

make uses the first meta-rule to look for file.c. If it cannot find an explicit rule to build file.c, it again looks through the meta-rules for a rule to build %.c. It finds such a rule in

%.c : %.y

Thus, make can rebuild file.obj from file.y.

make considers each meta-rule only once when performing transitive closure to avoid a situation where it loops forever. For example, if you have the rule

% : %.c
	... rule body ...

the command

make file

causes make to look for file.c. If the meta-rules were not restricted and file.c did not exist, then make would look for file.c.c, and then file.c.c.c, and so on. Because make uses each meta-rule only once, this cannot happen.

make computes transitive closure once for each meta-rule head the first time the pattern matches a target. When transitive closure is computed, make adds all the computed rules to the rule set for that meta-rule head. For example, if you have the rules

%$E : %$O
	recipe 1...
%$O : %c
	recipe 2...

and you are making file.exe, this target matches successfully against %$E causing make to compute transitive closure for %$E. As a result of this computation, a new rule is created:

%$E : %.c
	recipe 2...
	recipe 1...
	.REMOVE target recipe for %$O, if not .PRECIOUS

make executes this rule if file$O.obj does not exist. When make finishes the computation for the rule head, it marks the rule head as transitive closure computed. Since make adds all possible new rules to the rule set the first time the computation is done, it is not necessary to do it again -- nothing new is added.

The best way to understand how this works is to experiment with little make files with the -v option specified. This shows you in detail what rules are being searched, when transitive closure is calculated and what rules are added.

Order of Rule Generation

Since transitive closure allows make to generate new rules, it is important to understand the order this is done in:

make searches for explicit rules in the order they appear, so explicit rules always take precedence.

make reads meta-rules in the order they appear in the makefile. The first rule that appears in the makefile is the first one checked.

New explicit meta-rules (as distinct from meta-rules generated by transitive closure) replace old ones. In other words, if your makefile contains an explicit rule like this one, it replaces the default rule in startup.mk:
```
%$O : %.c
        rule1
```
If you use the -v option, make prints a warning when it replaces a meta-rule.

When transitive closure is calculated, the new meta-rules generated are added to the end of the list of possible meta-rules. Thus, make always finds the explicit rules first, so they take precedence over generated rules. You can use the -v option to see what rules make generates and the order they appear in.

make performs two passes through the rules. On the first pass it attempts to find a match with an explicit rule in the makefile; if this does not succeed, make performs a second pass to find a match with an existing file.

Suffix Rules

make treats targets that begin with a period and contain no slashes or percent signs as suffix rules. If there is only one period in the target, it is a single-suffix inference rule. Targets with two periods are double-suffix inference rules. Suffix rules do not have prerequisites but do have commands associated with them.

When make finds no explicit rule to update a target, it checks the suffix of that target (.s1) against the suffix rules. make examines a prerequisite based on the base name of the target with the second suffix (.s2) appended, and if the target is out-of-date with respect to this prerequisite, make executes the recipe for that inference rule.

If the target to be built does not contain a suffix and there is no rule for the target, make checks the single suffix inference rules. The single suffix inference rules define how to build a target 'br 'ne 5v if make finds a rule with one of the single suffixes appended. A rule with one suffix .s2 defines how to build target from target.s2.

Any suffixes used in a suffix rule must appear as a prerequisite of the special target .SUFFIXES. The order that the suffixes appear in the .SUFFIXES rule determines the order make checks the suffix rules in. New suffixes and suffix rules are added to the existing list. To turn off the suffix rules, place

.SUFFIXES:

in your makefile. This clears the prerequisites of the .SUFFIXES target and prevents the enaction of any suffix rules.

The search algorithm used for suffix rules depends on whether or not the .POSIX special target is specified. When .POSIX is specified, the following steps describe the search algorithm for suffix rules:

Extract the suffix from the target. If that target has no suffix, go to step 6.

Is it in the .SUFFIXES list? If not, then quit the search.

If it is in the .SUFFIXES list, look for a double suffix rule that matches the target suffix.

If you find one, then extract the base name of the file, add on the second suffix and see if the resulting file exists. If it does not, then keep searching the double suffix rules. If it does exist, then use the recipe for this rule.

If no successful match is made, then the inference has failed.

If the target did not have a suffix, then check the single suffix rules in the order that the suffixes are specified in the .SUFFIXES target.

For each single suffix rule, add the suffix to the target name and see if the resulting file name exists.

If the file exists, then execute the recipe associated with that suffix rule. If the file does not exist, continue trying the rest of the single suffix rules.

If no successful match is made, then the inference has failed.

When the .POSIX special target is not specified, make handles suffix rules in the same manner as traditional implementations of make. The following steps describe the search algorithm for suffix rules in this situation.

Extract the suffix from the target. If that target has no suffix, go to step 8.

Is it in the .SUFFIXES list? If not, then quit the search.

If it is in the .SUFFIXES list, look for a double suffix rule that matches the target suffix.

If you find one, then extract the base name of the file, add on the second suffix and see if the resulting file exists. If it does, go to step 7. If not, continue with step 5.

Is there an inference rule for the resulting file? If yes, execute the recipe associated with that rule (that should describe how to make the file exist) and go to step 7.

Search for the next double suffix rule that matches the target suffix and return to step 4. If the double suffix rules are exhausted then the inference has failed.

Use the recipe for the target rule.

If the target did not have a suffix, then check the single suffix rules in the order that the suffixes are specified in the .SUFFIXES target.

For each single suffix rule, add the suffix to the target name and see if the resulting file name exists.

If the file exists, then execute the recipe associated with that suffix rule. If the file does not exist, continue trying the rest of the single suffix rules.

If no successful match is made, then the inference has failed.

MKS Make also provides a special feature in the suffix rule mechanism for archive library handling, useful mainly for compatibility with System V Make. If you specify a suffix rule of the form

.suf.a:
		recipe

the rule matches any target specified as a library member, regardless of what the actual library suffix is. For example, suppose your makefile contains the following rules:

.SUFFIXES: .a .obj
.obj.a:
	echo adding $< to library $@

If mem.obj exists, then the following command

make -r "mylib(mem)"

causes make to print this message:

adding mem.obj to library mylib

Refer to Making Libraries in the User's Guide for more information about libraries.

Attributes

make defines several target attributes. Attributes may be assigned to a single target, a group of targets, or to all targets in the makefile. Attributes affect what make does when it needs to update a target. You can associate attributes with targets by specifying a rule of the following form:

attribute_list : target ...

This assigns the attributes in attribute_list to the given targets. If you do not specify any targets, the attributes apply to every target in the makefile. You can also put attributes inside a normal rule, as in:

targets attribute_list : prerequisite ...

These are the recognized attributes:

.EPILOG: Insert shell epilog code when executing a group recipe associated with any target having this attribute set.
.IGNORE: Ignore an error when trying to make any target with this attribute set.
.LIBRARY: Target is a library.
.PRECIOUS: Do not remove this target under any circumstances. Any automatically inferred prerequisite inherits this attribute.
.PROLOG: Insert shell prolog code when executing a group recipe associated with any target having this attribute set.
.SETDIR: Change current working directory to specified directory when making associated targets. The syntax of this attribute is .SETDIR=path, where path is the path name of desired working directory. If path contains any colon (:) characters, the entire attribute string must be quoted, not just the path name.
.SILENT: Do not echo the recipe lines when making any target with this attribute set, and do not issue any warnings.

You can use any attribute with any target, including special targets.

Special Target Directives

Special Target Directives are called targets because they appear in the target position of rules; however, they are really keywords, not targets. The rules they appear in are directives that control the behavior of make.

The special target must be the only target in a special rule--you cannot list other normal or special targets.

Some special targets are affected by some attributes. Any special target can be given any attribute, but often the combination is meaningless and the attribute has no effect.

.BRACEEXPAND

This target may have no prerequisites and no recipe associated with it. If set, the target enables the outdated brace expansion feature used in older versions of MKS Make. (This target is ignored if the .POSIX special target is set.) Older versions of make use brace expansion to expand a token list of this form:

string1{token_list}string2

make adds string1 to the front, and string2 to the end, of each token in the token_list. To include brace brackets while this target is set, use {{ and }}; you cannot include literal brace brackets in the token list. You can achieve the same kind of brace expansion in modern versions of make by using macro expansion with prefix and suffix modifiers:

$(TOKEN_BASE:^"prefix":+"suffix")

Note that the double quotes are required. Future versions of MKS Make may dispense with brace expansion completely.

.CYCLECHECK

This special target may have no prerequisites and no recipe associated with it. If set, it determines how make treats circular dependencies (for more information, see the Circular Dependencies section of this reference page). You can specify one of five attributes with this target. If you specify more than one attribute, an error message results. The five attributes are:

.SILENT

make remains silent about any within-rule and between-rule circular dependencies, removes the offending dependency from the list of prerequisites, and continues.

.WARNTARG

make issues warnings for named targets with circular dependencies. If the name of the dependency is the same as the named target, it is removed from the list of prerequisites and make continues. This is the default behavior if .CYCLECHECK is not specified or is specified with no attributes.

.WARNALL

make issues warnings for all within-rule circular dependencies regardless of whether the target is being built or not and for all between-rule circular dependencies for the named targets. The offending dependency is removed from the list of prerequisites and make continues.

.FATALTARG

make treats all circular dependencies for named targets as fatal errors. It issues an error message and exits.

.FATALALL

make treats all within-rule circular dependencies as fatal errors whether the target is being built or not. It also treats all between-rule circular dependencies for named targets as fatal errors. make issues an error message and exits.

For example, to set the circular dependency check to make's default, use the rule:

.CYCLECHECK .WARNTARG:

.DEFAULT

This target has no prerequisites, but it does have a recipe. If make can apply no other rule to produce a target, it uses this rule if it has been defined.

.ERROR

make executes the recipe associated with this target whenever it detects an error condition.

.EXPORT

All prerequisites associated with this target that correspond to macro names are exported to the environment at the point in the makefile where this target appears. If you do not specify any prerequisites for this target, all macros are exported.

.GROUPEPILOG

make adds the recipe associated with this target after any group recipe for a target that has the .EPILOG attribute.

.GROUPPROLOG

make adds the recipe associated with this target before any group recipe for a target that has the .PROLOG attribute.

.IMPORT

make searches in the environment for prerequisite names specified for this target and defines them as macros with their value taken from the environment. If the prerequisite .EVERYTHING is given, make reads in the entire environment (also, see the -e and -E options).

.INCLUDE

make reads one or more additional makefiles (specified in the prerequisite list), as if their contents had been inserted at this point. If the prerequisite list contains more than one file, make reads them in order from left to right.

make uses the following rules to search for extra makefiles:

If a relative file name is enclosed in quotes, or is not enclosed with angle brackets (< and >), make looks in the current directory. If the file is not present, make then looks for it in each directory specified by the .INCLUDEDIRS special target.

If a relative name is enclosed with angle brackets (< and >), make only searches in the directories specified by the .INCLUDEDIRS special target.

If an absolute path name is given, make looks for that file, and ignores the list associated with the .INCLUDEDIRS special target.

.INCLUDEDIRS

The list of prerequisites specified for this target defines the set of directories to search when including a makefile.

.MAKEFILES

The list of prerequisites is the set of files to try to read as the user makefile. These files are made in the order they are specified (from left to right) until one is found to be up to date. This is the file that is used.

.NOAUTODEPEND

Disable the autodependency feature when building libraries. When this special target is used, only library members that have been explicitly given as dependents are considered prerequisites.

.POSIX

Process the makefile as specified in the POSIX.2 draft standard. This special target must appear before the first non-comment line in the makefile, and may have no prerequisite list, or recipe, associated with it. The target does the following:

causes make to use the shell when executing all recipe lines; make invokes one shell per line, regardless of the setting of SHELLMETAS.

disables brace expansion (the .BRACEEXPAND special target is ignored).

disables meta-rule inferencing.

disables conditionals.

disables dynamic prerequisites generation for libraries.

disables group recipes.

disables library autodependency.

make does not check for the string $(MAKE) when run with the -n options specified.

make always prints a message if no work is done.

When attempting to do suffix rule inference, the inference succeeds only if the the inference prerequisite file exists.

.REMOVE

make uses the recipe of this target to remove any intermediate files that it creates if an error is encountered before creating the final target. This .REMOVE target only deletes a file that satisfies all of the following criteria:

the file did not exist when make began running

the file is named as an intermediate target, produced by invoking a meta-rule that was produced by transitive closure

the file is not explicitly named in the makefile

the generated target does not have the .PRECIOUS attribute

the file is a prerequisite of a rule that is actually used

.SOURCE

The prerequisite list of this target defines a set of directories to check when trying to locate a target file name.

.SOURCE.x

Same as .SOURCE, except that make searches the .SOURCE.x list first when trying to locate a file matching a target with a name that ends in the suffix .x.

.SUFFIXES

make appends the prerequisite list of this target to the set of suffixes used when trying to infer a prerequisite for making a target using suffix rules. If you specify no prerequisites, make clears the list of suffixes, effectively disabling suffix rules from that point on.

Control Macros

make defines a number of control macros that, like special target directives and attributes, alter its behavior. A control macro that has the same function as a special target or attribute also has the same name.

Macros that are said to be defined internally are automatically created by make and you can use them with the usual $(name construct. For example, you can use $(PWD) to obtain the current directory name.

Recognized control macros are:

DIRSEPSTR

Contains the characters used to separate parts in a path name and can be set by the user. make uses the first character in this string to build path names when necessary.

Note:: The DIRSEPSTR macro must be set in your environment before running make, so that the MAKEDIR macro is aware of its value. This is necessary because MAKEDIR is set before the makefile or command-line flags are looked at.

.EPILOG

If assigned a non-empty value, the .EPILOG attribute is given to every target.

GROUPFLAGS

Specifies options to pass to GROUPSHELL when make invokes it to execute a group recipe.

GROUPSHELL

Gives the path name of the command interpreter (shell) that make calls to process group recipes.

GROUPSUFFIX

Specifies a string for make to use as a suffix when creating group recipe files to be handed to the command interpreter. This must be .bat or .cmd for cmd.exe.

.IGNORE

If this is assigned a non-null value, make assigns the .IGNORE attribute to every target.

INCDEPTH

The current depth of makefile inclusion. This is set internally.

MAKE

This is set by the startup file and may be changed by the user. The standard startup file defines it as

$(MAKECMD) $(MFLAGS)

The MAKE macro is not used by make itself, but the string $(MAKE) is recognized when using the -n option for single line recipes.

MAKECMD

The name that make was invoked with.

MAKEDIR

Full path name of the initial directory where make began execution.

MAKEFLAGS

The MAKEFLAGS macro contains all the options and macros specified in the MAKEFLAGS environment variable plus all the options specified on the command line, with the following exceptions:

The options -c, -D, -f, and -p are silently ignored if they are found in the MAKEFLAGS environment variable.

Any of options -c, -D, -f, -p, -v, or -V, when specified on the command line, are not added to the MAKEFLAGS macro.

When the -M option is specified, macro definitions from the MAKEFLAGS environment variable are not added to the MAKEFLAGS macro.

added

Options in the MAKEFLAGS environment variable may have leading minus signs and can be separated by spaces. These are stripped out when the MAKEFLAGS macro is constructed.

Note:: make always reads the MAKEFLAGS environment variable before reading the makefile. The -E and -e options do not affect this.

MAKESTARTUP

Has the default value ROOTDIR/etc/startup.mk on Windows systems. (On UNIX and POSIX systems, the $ROOTDIR is omitted.) To change this value, you can set the MAKESTARTUP environment variable before running make. You can also specify a value for this control macro on the command line, if you use the -D option:

make -DMAKESTARTUP=$HOME/project/startup.mk

MFLAGS

Same as MAKEFLAGS, except that it includes the leading option character (-).

NULL

Permanently defined to be the empty string.

OS

Name of the operating system that this version of make is compiled for.

NT      on 8.1/2012R2/10/2016/2019/11/2022
unix    on UNIX systems
POSIX   on POSIX systems

.PRECIOUS

If this is assigned a non-empty value, make assigns the .PRECIOUS attribute to every target.

.PROLOG

If this is assigned a non-empty value, make assigns the .PROLOG attribute to every target.

PWD

Full path name of the current directory where make is executing.

SHELL

Specifies the full path name of the command interpreter that make calls to process single line recipes if they contain one or more of the characters given in SHELLMETAS. Otherwise, make executes these commands directly. By default, the value of the SHELL environment variable does not affect the value of this macro; however, you can use the .IMPORT special target to assign the environment variable's value to this macro. You can also use the EXPORT special target to assign this macro's value to the SHELL environment variable.

SHELLFLAGS

Specifies options to pass to the shell when invoking it to execute a single line recipe.

SHELLMETAS

Specifies a list of metacharacters that can appear in single recipe lines. If make finds any metacharacter, it invokes the recipe using the shell specified by SHELL; otherwise, it executes the recipe without the shell.

.SILENT

If this is assigned a non-empty value, make assigns the .SILENT attribute to every target.

SWITCHAR

The character currently being used to mark options in command lines.

Making Libraries

A library is a file containing a collection of object files. To make a library, you specify it as a target with the .LIBRARY attribute and list its prerequisites. The prerequisites should be the object members that are to go into the library. When make makes the library target, it looks for the prerequisites in the library if it cannot find an appropriate object file.

When make finds lib(member), it declares the lib portion as a target with the .LIBRARY attribute and automatically declares the member portion as a prerequisite of the lib target. When make finds lib((entry)), it declares the lib portion as a target with the .LIBRARY attribute and automatically declares the module defining entry as lib's associated prerequisite.

This autodependency can be turned off by the .NOAUTODEPEND special target. Since autodependency is not POSIX compatible, it is also disabled by the .POSIX special target.

Conditionals

Conditional expressions use the following form:

.IF expression
... if text ...
{.ELSIF expression2
... elsif text ...}
[.ELSE
... else text ...]
.END

You can nest the conditionals (that is, the text may contain another conditional). The .IF, .ELSE, .ELSIF, and .END must start in the first column of the line. expression or expression 2 can have one of three forms:

string

is true if the given string is non-empty,

string == string

is true if the two strings are equal, and

string != string

is true if the two strings are not equal.

Typically, one or both strings contain macros that make expands before comparing. make also discards white space at the start and end of the text portion before the comparison. This means that a macro that expands to nothing but white space is considered an empty value for the purpose of the comparison. If a macro expression needs to be compared to an empty string, compare it to the value of the macro NULL for readability.

The text enclosed in the conditional construct must have the same format that it would have outside the conditional. In particular, make assumes that anything that starts with a tab inside the conditional is a recipe line. This means that you cannot use tabs to indent text inside the conditional (except, of course, for recipe lines that always begin with tabs).

Functions

make supports the following function:

$(shell shell_cmd)

performs the same function that backquotes (`shell_cmd`) do in most shells. That is, it performs command substitution, returning the output of the specified shell command, shell_cmd and substituting it into the surrounding text, after first replacing each newline or carriage-return/newline pair with a single space and removing any trailing newline or carriage-return/newline pair.

The command specified with the shell function is run when the the function call is expanded. Because this function involves spawning a new shell, you should carefully consider the performance implications of using the shell function within recursively expanded variables as opposed to simply expanded variables.

Software Configuration Management Integration

make provides integration with a variety of Software Configuration Management (SCM) applications.

The SCM environment variable determines not only if SCM integration is enabled, but also which SCM application is to be used. The following are the valid values for SCM:

CC         Rational Clearcase
CVS        CVS (Concurrent Versions System)
RCS        RCS (Revision Control System)
SIE        PTC Windchill Source Code Management
SS         Microsoft SourceSafe

If SCM is unset or set to a value other than those listed, no SCM integration is used.

make uses the $ROOTDIR/etc/makescm.ksh script and the built-in rules in $ROOTDIR/etc/startup.mk to determine if a possible prerequisite file name is a versioned object in the current SCM repository. When SCM integration is enabled, make checks out and uses the most recent version of each prerequisite file on the appropriate branch in the current SCM repository. However, if a writable version of the prerequisite file exists in the working directory, a newer version is not checked out. To help the SCM application determine the most recent version of versioned files, the UPDFLAGS variable in $ROOTDIR/etc/startup.mk can be set to a string of options to be used with the SCM application's command for retrieving file versions.

ENVIRONMENT VARIABLES

COFLAGS

specifies the options to be used with the RCS co command when RCS integration is enabled with the HAVERCS environment variable. This variable is supported primarily for backwards compatibility with earlier versions of make. You should use the SCM and UPDFLAGS environment variables as described in the Software Configuration Management Integration section.

HAVERCS

when set to yes, enables RCS integration. This variable is supported primarily for backwards compatibility with earlier versions of make. You should use the SCM and UPDFLAGS environment variables as described in the Software Configuration Management Integration section.

Note:: You should not have both the HAVERCS variable set to yes and the SCM variable set to a valid value as this may lead to unexpected results.

MAKEFLAGS

contains a series of make options that are used as the default options for any make command. You may specify the options with or without leading minus signs (-) and blanks between them. It may also include macro definitions of the form usually found on the command line.

MAKESTARTUP

contains the path name of the make startup file. By default, make uses the file ROOTDIR/etc/startup.mk as its startup file. To use a different file, set this environment variable before running make.

SCM

when set to an appropriate value, enables Software Configuration Management Integration and specifies which SCM application to use. For details on SCM integration and appropriate values for this environment variable, see the Software Configuration Management Integration section.

Note:: You should not have both the HAVERCS variable set to yes and the SCM variable set to a valid value as this may lead to unexpected results.

SHELL

contains the name of a command interpreter. To assign this value to the control macro SHELL, use the .IMPORT special target. You can also use the .EXPORT special target to assign the value of the SHELL macro to this environment variable for commands run from recipes.

TK_CC_UNIX_DEF

when set, the default startup.mk file redefines various definitions to their UNIX system values. The extensions for object and assembler files are redefined to .o and .s rather than the Windows values of .obj and .asm. In addition, the compiler, linker, and assembler are set to be the MKS Toolkit cc, ld, and cc, respectively as opposed to the Windows settings of cl, link, and masm.

TK_USE_SFX_RULE

when set, allows suffix rules in the makefile to override the pre-defined meta-rules specified in the startup.mk file.

UPDFLAGS

when SCM integration is enabled, helps the SCM application specified by the SCM environment variable determine the most version of a version of version files. This variable is set in $ROOTDIR/etc/startup.mk and contains a string of options to be used with the SCM application's command for retrieving file versions. For details on SCM integration, see the Software Configuration Management Integration section.

make automatically imports all other environment variables, unless you specify the -E option.

FILES

ROOTDIR/etc/makescm.ksh: is used in conjunction with the built-in rules in ROOTDIR/etc/startup.mks to implement SCM integration. See the Software Configuration Management Integration for details.
ROOTDIR/etc/startup.mk: default startup file containing default rules.

DIAGNOSTICS

If a command in a recipe line fails (exits with a non-zero status), Make returns the exit status of the failed command. Since most commands use exit statuses between 0 and 10, Make uses exit status values below 10 only for failures that do not run recipe lines.

Possible exit status values for Make are:

0

Successful completion.

1

Returned if you specified -q and file is not up to date.

2

Failure due to any of the following:

— unknown command-line option

— missing argument to option, such as no file name for -f

126

Recipe command not executable.

127

Recipe command not found.

128

Make called a program that crashed.

129-254

Make, or a program that Make called, was interrupted by a signal; the error code is the signal number OR'ed with 128. For example, SIGINT ( CTRL-C) is frequently signal 1: the return code from Make is 128|1, or 129.

255

Failure because of any of the following:

— Macro cannot be redefined

— Macro variables must be assigned with :=

— Special target cannot be a prerequisite

— Too many makefiles specified

— Configuration file not found

— No makefile present

— Missing .END for .IF

— No target

— Unable to return to directory

— Too many open files

— Open failed

— File not found

— Unable to change directory

— No more memory

— Line too long

— Detected circular macro definition

— Unterminated pattern string

— Unterminated replacement string

— Token separator string must be quoted

— Unterminated separator string

— Expansion too long

— Suffix too long

— Unmatched quote

— .IF nesting too deep

— .ELSE without .IF

— Unmatched .END

— Inference rules result in circular dependency

— No macro name specified

— Write error on temp file

— Target not found, and cannot be made

— Do not know how to make <target>

— <+ diversion unterminated

— <+ diversion cannot be nested

— <+ missing before +>

— Incomplete recipe group

— Mixed single and group recipe lines

— Unmatched ]

— Expecting macro or rule definition, found neither

— Name too long

— Unable to determine current directory

— Only one NAME attribute allowed in rule line

— Multiple targets are not allowed in % rules

— Special target must appear alone

— Duplicate entry in target list

— Syntax error in % rule, missing % target

— Duplicate entry in prerequisite list

— Missing targets or attributes in rule

— Multiply defined recipe for target

— Empty recipe for special target

— Imported macro NAME not found in environment

— No .INCLUDE file(s) specified

— Include file NAME, not found

— NAME ignored on special target

— Attributes possibly ignored

— Cannot find member defining symbol ((NAME)

— Invalid library format

— Cannot touch library member

— SHELL macro not defined

— Too many arguments

— Could not export NAME

— Cannot open file

— Detected circular dependency

— Unable to stat /

— Unable to stat .

— Cannot open ..

— Read error in ..

— Metarule too long: "rule"

PORTABILITY

POSIX.2. x/OPEN Portability Guide 4.0. All UNIX systems. Windows 8.1. Windows Server 2012 R2. Windows 10. Windows Server 2016. Windows Server 2019. Windows 11. Windows Server 2022.

The following features of MKS Make are enhancements to POSIX.2:

The options; -c dir, -D macro_def'n, -E, -M, -u, -V, -v, -x.

The -n option has enhanced functionality not covered by the standard; for more information see the explanations of the -n option and the .POSIX special target in this reference page.

The run-time macros: $&, $^, $>.

The dynamic prerequisites: $$%, $$>, $$*, $$@.

All macro expansion modifiers except for suffix replacement.

Macro assignments of the following forms:

	macroname := stringassigned
	macroname += stringassigned

Brace expansion.

Backslash continuation.

The quoting mechanism, as in the following example:
```
	"a:target" : "a:prerequisite"
```

All rule operators except the colon (:).

Conditionals.

Meta-Rules.

All MKS Make attributes except .IGNORE, .PRECIOUS, .SILENT.

All MKS Make special targets except .DEFAULT, .POSIX, .SUFFIXES.

All MKS Make control macros except SHELL (referred to in POSIX.2 as control macros).

The search algorithm for suffix rule follows the POSIX.2 rules when the .POSIX special target is specified, but behaves like traditional implementations when it is not specified.

LIMITS

The maximum length of a script line is 16834 characters.

In some environments, the length of an argument string is restricted.

NOTES

When the .SETDIR special target is used, MKS Make checks the file attributes of targets and prerequisites on every pass through a rule. This can significantly increase the number of file system accesses.

AVAILABILITY

PTC MKS Toolkit for Developers
PTC MKS Toolkit for Interoperability
PTC MKS Toolkit for Professional Developers
PTC MKS Toolkit for Professional Developers 64-Bit Edition
PTC MKS Toolkit for Enterprise Developers
PTC MKS Toolkit for Enterprise Developers 64-Bit Edition
PTC Windchill Requirements and Validation

make
maintain program-generated and interdependent files

Command