make

Command

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.

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.

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

-ffile

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

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.

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.

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.

+"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

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.

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 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:

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.

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.

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 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:

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:

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.