1MAKE(P) POSIX Programmer's Manual MAKE(P)
2
6 make - maintain, update, and regenerate groups of programs (DEVELOP‐
7 MENT)
8
10 make [-einpqrst][-f makefile]...[ -k| -S][macro=value]...
11 [target_name...]
12
14 The make utility shall update files that are derived from other files.
15 A typical case is one where object files are derived from the corre‐
16 sponding source files. The make utility examines time relationships and
17 shall update those derived files (called targets) that have modified
18 times earlier than the modified times of the files (called prerequi‐
19 sites) from which they are derived. A description file (makefile) con‐
20 tains a description of the relationships between files, and the com‐
21 mands that need to be executed to update the targets to reflect changes
22 in their prerequisites. Each specification, or rule, shall consist of
23 a target, optional prerequisites, and optional commands to be executed
24 when a prerequisite is newer than the target. There are two types of
25 rule:
26 1. Inference rules, which have one target name with at least one
28 period ( '.' ) and no slash ( '/' )
29 2. Target rules, which can have more than one target name
31 In addition, make shall have a collection of built-in macros and infer‐
33 ence rules that infer prerequisite relationships to simplify mainte‐
34 nance of programs.
35 To receive exactly the behavior described in this section, the user
37 shall ensure that a portable makefile shall:
38 * Include the special target .POSIX
40 * Omit any special target reserved for implementations (a leading
42 period followed by uppercase letters) that has not been specified by
43 this section
44 The behavior of make is unspecified if either or both of these condi‐
46 tions are not met.
47
49 The make utility shall conform to the Base Definitions volume of
50 IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.
51 The following options shall be supported:
53 -e Cause environment variables, including those with null values,
55 to override macro assignments within makefiles.
56 -f makefile
58 Specify a different makefile. The argument makefile is a path‐
59 name of a description file, which is also referred to as the
60 makefile. A pathname of '-' shall denote the standard input.
61 There can be multiple instances of this option, and they shall
62 be processed in the order specified. The effect of specifying
63 the same option-argument more than once is unspecified.
64 -i Ignore error codes returned by invoked commands. This mode is
66 the same as if the special target .IGNORE were specified without
67 prerequisites.
68 -k Continue to update other targets that do not depend on the cur‐
70 rent target if a non-ignored error occurs while executing the
71 commands to bring a target up-to-date.
72 -n Write commands that would be executed on standard output, but do
74 not execute them. However, lines with a plus sign ( '+' ) prefix
75 shall be executed. In this mode, lines with an at sign ( '@' )
76 character prefix shall be written to standard output.
77 -p Write to standard output the complete set of macro definitions
79 and target descriptions. The output format is unspecified.
80 -q Return a zero exit value if the target file is up-to-date; oth‐
82 erwise, return an exit value of 1. Targets shall not be updated
83 if this option is specified. However, a makefile command line
84 (associated with the targets) with a plus sign ( '+' ) prefix
85 shall be executed.
86 -r Clear the suffix list and do not use the built-in rules.
88 -S Terminate make if an error occurs while executing the commands
90 to bring a target up-to-date. This shall be the default and the
91 opposite of -k.
92 -s Do not write makefile command lines or touch messages (see -t)
94 to standard output before executing. This mode shall be the same
95 as if the special target .SILENT were specified without prereq‐
96 uisites.
97 -t Update the modification time of each target as though a touch
99 target had been executed. Targets that have prerequisites but no
100 commands (see Target Rules ), or that are already up-to-date,
101 shall not be touched in this manner. Write messages to standard
102 output for each target file indicating the name of the file and
103 that it was touched. Normally, the makefile command lines asso‐
104 ciated with each target are not executed. However, a command
105 line with a plus sign ( '+' ) prefix shall be executed.
106 Any options specified in the MAKEFLAGS environment variable shall be
109 evaluated before any options specified on the make utility command
110 line. If the -k and -S options are both specified on the make utility
111 command line or by the MAKEFLAGS environment variable, the last option
112 specified shall take precedence. If the -f or -p options appear in the
113 MAKEFLAGS environment variable, the result is undefined.
114
116 The following operands shall be supported:
117 target_name
119 Target names, as defined in the EXTENDED DESCRIPTION section. If
120 no target is specified, while make is processing the makefiles,
121 the first target that make encounters that is not a special tar‐
122 get or an inference rule shall be used.
123 macro=value
125 Macro definitions, as defined in Macros .
126 If the target_name and macro= value operands are intermixed on the make
129 utility command line, the results are unspecified.
130
132 The standard input shall be used only if the makefile option-argument
133 is '-' . See the INPUT FILES section.
134
136 The input file, otherwise known as the makefile, is a text file con‐
137 taining rules, macro definitions, and comments. See the EXTENDED
138 DESCRIPTION section.
139
141 The following environment variables shall affect the execution of make:
142 LANG Provide a default value for the internationalization variables
144 that are unset or null. (See the Base Definitions volume of
145 IEEE Std 1003.1-2001, Section 8.2, Internationalization Vari‐
146 ables for the precedence of internationalization variables used
147 to determine the values of locale categories.)
148 LC_ALL If set to a non-empty string value, override the values of all
150 the other internationalization variables.
151 LC_CTYPE
153 Determine the locale for the interpretation of sequences of
154 bytes of text data as characters (for example, single-byte as
155 opposed to multi-byte characters in arguments and input files).
156 LC_MESSAGES
158 Determine the locale that should be used to affect the format
159 and contents of diagnostic messages written to standard error.
160 MAKEFLAGS
162 This variable shall be interpreted as a character string repre‐
164 senting a series of option characters to be used as the default
165 options. The implementation shall accept both of the following
166 formats (but need not accept them when intermixed):
167 * The characters are option letters without the leading hyphens
169 or <blank> separation used on a make utility command line.
170 * The characters are formatted in a manner similar to a portion
172 of the make utility command line: options are preceded by
173 hyphens and <blank>-separated as described in the Base Defi‐
174 nitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility
175 Syntax Guidelines. The macro= value macro definition oper‐
176 ands can also be included. The difference between the con‐
177 tents of MAKEFLAGS and the make utility command line is that
178 the contents of the variable shall not be subjected to the
179 word expansions (see Word Expansions ) associated with pars‐
180 ing the command line values.
181 NLSPATH
183 Determine the location of message catalogs for the processing of
184 LC_MESSAGES .
185 PROJECTDIR
187 Provide a directory to be used to search for SCCS files not
189 found in the current directory. In all of the following cases,
190 the search for SCCS files is made in the directory SCCS in the
191 identified directory. If the value of PROJECTDIR begins with a
192 slash, it shall be considered an absolute pathname; otherwise,
193 the value of PROJECTDIR is treated as a user name and that
194 user's initial working directory shall be examined for a subdi‐
195 rectory src or source. If such a directory is found, it shall be
196 used. Otherwise, the value is used as a relative pathname.
197 If PROJECTDIR is not set or has a null value, the search for SCCS files
199 shall be made in the directory SCCS in the current directory.
200 The setting of PROJECTDIR affects all files listed in the remainder of
202 this utility description for files with a component named SCCS.
203 The value of the SHELL environment variable shall not be used as a
206 macro and shall not be modified by defining the SHELL macro in a make‐
207 file or on the command line. All other environment variables, including
208 those with null values, shall be used as macros, as defined in Macros .
209
211 If not already ignored, make shall trap SIGHUP, SIGTERM, SIGINT, and
212 SIGQUIT and remove the current target unless the target is a directory
213 or the target is a prerequisite of the special target .PRECIOUS or
214 unless one of the -n, -p, or -q options was specified. Any targets
215 removed in this manner shall be reported in diagnostic messages of
216 unspecified format, written to standard error. After this cleanup
217 process, if any, make shall take the standard action for all other sig‐
218 nals.
219
221 The make utility shall write all commands to be executed to standard
222 output unless the -s option was specified, the command is prefixed with
223 an at sign, or the special target .SILENT has either the current target
224 as a prerequisite or has no prerequisites. If make is invoked without
225 any work needing to be done, it shall write a message to standard out‐
226 put indicating that no action was taken. If the -t option is present
227 and a file is touched, make shall write to standard output a message of
228 unspecified format indicating that the file was touched, including the
229 filename of the file.
230
232 The standard error shall be used only for diagnostic messages.
233
235 Files can be created when the -t option is present. Additional files
236 can also be created by the utilities invoked by make.
237
239 The make utility attempts to perform the actions required to ensure
240 that the specified targets are up-to-date. A target is considered out-
241 of-date if it is older than any of its prerequisites or if it does not
242 exist. The make utility shall treat all prerequisites as targets them‐
243 selves and recursively ensure that they are up-to-date, processing them
244 in the order in which they appear in the rule. The make utility shall
245 use the modification times of files to determine whether the corre‐
246 sponding targets are out-of-date.
247 After make has ensured that all of the prerequisites of a target are
249 up-to-date and if the target is out-of-date, the commands associated
250 with the target entry shall be executed. If there are no commands
251 listed for the target, the target shall be treated as up-to-date.
252 Makefile Syntax
254 A makefile can contain rules, macro definitions (see Macros ), and com‐
255 ments. There are two kinds of rules: inference rules and target rules.
256 The make utility shall contain a set of built-in inference rules. If
257 the -r option is present, the built-in rules shall not be used and the
258 suffix list shall be cleared. Additional rules of both types can be
259 specified in a makefile. If a rule is defined more than once, the value
260 of the rule shall be that of the last one specified. Macros can also be
261 defined more than once, and the value of the macro is specified in
262 Macros . Comments start with a number sign ( '#' ) and continue until
263 an unescaped <newline> is reached.
264 By default, the following files shall be tried in sequence: ./makefile
266 and ./Makefile. If neither ./makefile or ./Makefile are found, other
267 implementation-defined files may also be tried. On XSI-conformant
268 systems, the additional files ./s.makefile, SCCS/s.makefile, ./s.Make‐
269 file, and SCCS/s.Makefile shall also be tried.
270 The -f option shall direct make to ignore any of these default files
272 and use the specified argument as a makefile instead. If the '-' argu‐
273 ment is specified, standard input shall be used.
274 The term makefile is used to refer to any rules provided by the user,
276 whether in ./makefile or its variants, or specified by the -f option.
277 The rules in makefiles shall consist of the following types of lines:
279 target rules, including special targets (see Target Rules ), inference
280 rules (see Inference Rules ), macro definitions (see Macros ), empty
281 lines, and comments.
282 When an escaped <newline> (one preceded by a backslash) is found any‐
284 where in the makefile except in a command line, it shall be replaced,
285 along with any leading white space on the following line, with a single
286 <space>. When an escaped <newline> is found in a command line in a
287 makefile, the command line shall contain the backslash, the <newline>,
288 and the next line, except that the first character of the next line
289 shall not be included if it is a <tab>.
290 Makefile Execution
292 Makefile command lines shall be processed one at a time by writing the
293 makefile command line to the standard output (unless one of the condi‐
294 tions listed under '@' suppresses the writing) and executing the com‐
295 mand(s) in the line. A <tab> may precede the command to standard out‐
296 put. Command execution shall be as if the makefile command line were
297 the argument to the system() function. The environment for the command
298 being executed shall contain all of the variables in the environment of
299 make.
300 By default, when make receives a non-zero status from the execution of
302 a command, it shall terminate with an error message to standard error.
303 Makefile command lines can have one or more of the following prefixes:
305 a hyphen ( '-' ), an at sign ( '@' ), or a plus sign ( '+' ). These
306 shall modify the way in which make processes the command. When a com‐
307 mand is written to standard output, the prefix shall not be included in
308 the output.
309 - If the command prefix contains a hyphen, or the -i option is
311 present, or the special target .IGNORE has either the current
312 target as a prerequisite or has no prerequisites, any error
313 found while executing the command shall be ignored.
314 @ If the command prefix contains an at sign and the make utility
316 command line -n option is not specified, or the -s option is
317 present, or the special target .SILENT has either the current
318 target as a prerequisite or has no prerequisites, the command
319 shall not be written to standard output before it is executed.
320 + If the command prefix contains a plus sign, this indicates a
322 makefile command line that shall be executed even if -n, -q, or
323 -t is specified.
324 Target Rules
327 Target rules are formatted as follows:
328 target [target...]: [prerequisite...][;command]
331 [<tab>command<tab>command...]
332 line that does not begin with <tab>
334 Target entries are specified by a <blank>-separated, non-null list of
336 targets, then a colon, then a <blank>-separated, possibly empty list of
337 prerequisites. Text following a semicolon, if any, and all following
338 lines that begin with a <tab>, are makefile command lines to be exe‐
339 cuted to update the target. The first non-empty line that does not
340 begin with a <tab> or '#' shall begin a new entry. An empty or blank
341 line, or a line beginning with '#' , may begin a new entry.
342 Applications shall select target names from the set of characters con‐
344 sisting solely of periods, underscores, digits, and alphabetics from
345 the portable character set (see the Base Definitions volume of
346 IEEE Std 1003.1-2001, Section 6.1, Portable Character Set). Implementa‐
347 tions may allow other characters in target names as extensions. The
348 interpretation of targets containing the characters '%' and '' is
349 implementation-defined.
350 A target that has prerequisites, but does not have any commands, can be
352 used to add to the prerequisite list for that target. Only one target
353 rule for any given target can contain commands.
354 Lines that begin with one of the following are called special targets
356 and control the operation of make:
357 .DEFAULT
359 If the makefile uses this special target, the application shall
360 ensure that it is specified with commands, but without prerequi‐
361 sites. The commands shall be used by make if there are no other
362 rules available to build a target.
363 .IGNORE
365 Prerequisites of this special target are targets themselves;
366 this shall cause errors from commands associated with them to be
367 ignored in the same manner as specified by the -i option. Subse‐
368 quent occurrences of .IGNORE shall add to the list of targets
369 ignoring command errors. If no prerequisites are specified, make
370 shall behave as if the -i option had been specified and errors
371 from all commands associated with all targets shall be ignored.
372 .POSIX The application shall ensure that this special target is speci‐
374 fied without prerequisites or commands. If it appears as the
375 first non-comment line in the makefile, make shall process the
376 makefile as specified by this section; otherwise, the behavior
377 of make is unspecified.
378 .PRECIOUS
380 Prerequisites of this special target shall not be removed if
381 make receives one of the asynchronous events explicitly
382 described in the ASYNCHRONOUS EVENTS section. Subsequent occur‐
383 rences of .PRECIOUS shall add to the list of precious files. If
384 no prerequisites are specified, all targets in the makefile
385 shall be treated as if specified with .PRECIOUS.
386 .SCCS_GET
388 The application shall ensure that this special target is speci‐
389 fied without prerequisites. If this special target is included
390 in a makefile, the commands specified with this target shall
391 replace the default commands associated with this special target
392 (see Default Rules ). The commands specified with this target
393 are used to get all SCCS files that are not found in the current
394 directory.
395 When source files are named in a dependency list, make shall treat them
397 just like any other target. Because the source file is presumed to be
398 present in the directory, there is no need to add an entry for it to
399 the makefile. When a target has no dependencies, but is present in the
400 directory, make shall assume that that file is up-to-date. If, however,
401 an SCCS file named SCCS/s. source_file is found for a target
402 source_file, make compares the timestamp of the target file with that
403 of the SCCS/s.source_file to ensure the target is up-to-date. If the
404 target is missing, or if the SCCS file is newer, make shall automati‐
405 cally issue the commands specified for the .SCCS_GET special target to
406 retrieve the most recent version. However, if the target is writable by
407 anyone, make shall not retrieve a new version.
408 .SILENT
410 Prerequisites of this special target are targets themselves;
411 this shall cause commands associated with them not to be written
412 to the standard output before they are executed. Subsequent
413 occurrences of .SILENT shall add to the list of targets with
414 silent commands. If no prerequisites are specified, make shall
415 behave as if the -s option had been specified and no commands or
416 touch messages associated with any target shall be written to
417 standard output.
418 .SUFFIXES
420 Prerequisites of .SUFFIXES shall be appended to the list of
421 known suffixes and are used in conjunction with the inference
422 rules (see Inference Rules ). If .SUFFIXES does not have any
423 prerequisites, the list of known suffixes shall be cleared.
424 The special targets .IGNORE, .POSIX, .PRECIOUS, .SILENT, and .SUFFIXES
427 shall be specified without commands.
428 Targets with names consisting of a leading period followed by the
430 uppercase letters "POSIX" and then any other characters are reserved
431 for future standardization. Targets with names consisting of a leading
432 period followed by one or more uppercase letters are reserved for
433 implementation extensions.
434 Macros
436 Macro definitions are in the form:
437 string1 = [string2]
440 The macro named string1 is defined as having the value of string2,
442 where string2 is defined as all characters, if any, after the equal
443 sign, up to a comment character ( '#' ) or an unescaped <newline>. Any
444 <blank>s immediately before or after the equal sign shall be ignored.
445 Applications shall select macro names from the set of characters con‐
447 sisting solely of periods, underscores, digits, and alphabetics from
448 the portable character set (see the Base Definitions volume of
449 IEEE Std 1003.1-2001, Section 6.1, Portable Character Set). A macro
450 name shall not contain an equals sign. Implementations may allow other
451 characters in macro names as extensions.
452 Macros can appear anywhere in the makefile. Macro expansions using the
454 forms $( string1) or ${ string1} shall be replaced by string2, as fol‐
455 lows:
456 * Macros in target lines shall be evaluated when the target line is
458 read.
459 * Macros in makefile command lines shall be evaluated when the command
461 is executed.
462 * Macros in the string before the equals sign in a macro definition
464 shall be evaluated when the macro assignment is made.
465 * Macros after the equals sign in a macro definition shall not be
467 evaluated until the defined macro is used in a rule or command, or
468 before the equals sign in a macro definition.
469 The parentheses or braces are optional if string1 is a single charac‐
471 ter. The macro $$ shall be replaced by the single character '$' . If
472 string1 in a macro expansion contains a macro expansion, the results
473 are unspecified.
474 Macro expansions using the forms $( string1 [: subst1 =[ subst2 ]]) or
476 ${ string1 [: subst1 =[ subst2 ]]} can be used to replace all occur‐
477 rences of subst1 with subst2 when the macro substitution is performed.
478 The subst1 to be replaced shall be recognized when it is a suffix at
479 the end of a word in string1 (where a word, in this context, is defined
480 to be a string delimited by the beginning of the line, a <blank>, or a
481 <newline>). If string1 in a macro expansion contains a macro expansion,
482 the results are unspecified.
483 Macro expansions in string1 of macro definition lines shall be evalu‐
485 ated when read. Macro expansions in string2 of macro definition lines
486 shall be performed when the macro identified by string1 is expanded in
487 a rule or command.
488 Macro definitions shall be taken from the following sources, in the
490 following logical order, before the makefile(s) are read.
491 1. Macros specified on the make utility command line, in the order
493 specified on the command line. It is unspecified whether the inter‐
494 nal macros defined in Internal Macros are accepted from this
495 source.
496 2. Macros defined by the MAKEFLAGS environment variable, in the order
498 specified in the environment variable. It is unspecified whether
499 the internal macros defined in Internal Macros are accepted from
500 this source.
501 3. The contents of the environment, excluding the MAKEFLAGS and SHELL
503 variables and including the variables with null values.
504 4. Macros defined in the inference rules built into make.
506 Macro definitions from these sources shall not override macro defini‐
508 tions from a lower-numbered source. Macro definitions from a single
509 source (for example, the make utility command line, the MAKEFLAGS envi‐
510 ronment variable, or the other environment variables) shall override
511 previous macro definitions from the same source.
512 Macros defined in the makefile(s) shall override macro definitions that
514 occur before them in the makefile(s) and macro definitions from source
515 4. If the -e option is not specified, macros defined in the makefile(s)
516 shall override macro definitions from source 3. Macros defined in the
517 makefile(s) shall not override macro definitions from source 1 or
518 source 2.
519 Before the makefile(s) are read, all of the make utility command line
521 options (except -f and -p) and make utility command line macro defini‐
522 tions (except any for the MAKEFLAGS macro), not already included in the
523 MAKEFLAGS macro, shall be added to the MAKEFLAGS macro, quoted in an
524 implementation-defined manner such that when MAKEFLAGS is read by
525 another instance of the make command, the original macro's value is
526 recovered. Other implementation-defined options and macros may also be
527 added to the MAKEFLAGS macro. If this modifies the value of the MAKE‐
528 FLAGS macro, or, if the MAKEFLAGS macro is modified at any subsequent
529 time, the MAKEFLAGS environment variable shall be modified to match the
530 new value of the MAKEFLAGS macro. The result of setting MAKEFLAGS in
531 the Makefile is unspecified.
532 Before the makefile(s) are read, all of the make utility command line
534 macro definitions (except the MAKEFLAGS macro or the SHELL macro) shall
535 be added to the environment of make. Other implementation-defined vari‐
536 ables may also be added to the environment of make.
537 The SHELL macro shall be treated specially. It shall be provided by
539 make and set to the pathname of the shell command language interpreter
540 (see sh ). The SHELL environment variable shall not affect the value of
541 the SHELL macro. If SHELL is defined in the makefile or is specified on
542 the command line, it shall replace the original value of the SHELL
543 macro, but shall not affect the SHELL environment variable. Other
544 effects of defining SHELL in the makefile or on the command line are
545 implementation-defined.
546 Inference Rules
548 Inference rules are formatted as follows:
549 target:
552 <tab>command
553 [<tab>command]...
554 line that does not begin with <tab> or #
557 The application shall ensure that the target portion is a valid target
559 name (see Target Rules ) of the form .s2 or .s1.s2 (where .s1 and .s2
560 are suffixes that have been given as prerequisites of the .SUFFIXES
561 special target and s1 and s2 do not contain any slashes or periods.) If
562 there is only one period in the target, it is a single-suffix inference
563 rule. Targets with two periods are double-suffix inference rules.
564 Inference rules can have only one target before the colon.
565 The application shall ensure that the makefile does not specify prereq‐
567 uisites for inference rules; no characters other than white space shall
568 follow the colon in the first line, except when creating the empty
569 rule, described below. Prerequisites are inferred, as described below.
570 Inference rules can be redefined. A target that matches an existing
572 inference rule shall overwrite the old inference rule. An empty rule
573 can be created with a command consisting of simply a semicolon (that
574 is, the rule still exists and is found during inference rule search,
575 but since it is empty, execution has no effect). The empty rule can
576 also be formatted as follows:
577 rule: ;
580 where zero or more <blank>s separate the colon and semicolon.
582 The make utility uses the suffixes of targets and their prerequisites
584 to infer how a target can be made up-to-date. A list of inference rules
585 defines the commands to be executed. By default, make contains a built-
586 in set of inference rules. Additional rules can be specified in the
587 makefile.
588 The special target .SUFFIXES contains as its prerequisites a list of
590 suffixes that shall be used by the inference rules. The order in which
591 the suffixes are specified defines the order in which the inference
592 rules for the suffixes are used. New suffixes shall be appended to the
593 current list by specifying a .SUFFIXES special target in the makefile.
594 A .SUFFIXES target with no prerequisites shall clear the list of suf‐
595 fixes. An empty .SUFFIXES target followed by a new .SUFFIXES list is
596 required to change the order of the suffixes.
597 Normally, the user would provide an inference rule for each suffix.
599 The inference rule to update a target with a suffix .s1 from a prereq‐
600 uisite with a suffix .s2 is specified as a target .s2.s1. The internal
601 macros provide the means to specify general inference rules (see Inter‐
602 nal Macros ).
603 When no target rule is found to update a target, the inference rules
605 shall be checked. The suffix of the target ( .s1) to be built is com‐
606 pared to the list of suffixes specified by the .SUFFIXES special tar‐
607 gets. If the .s1 suffix is found in .SUFFIXES, the inference rules
608 shall be searched in the order defined for the first .s2.s1 rule whose
609 prerequisite file ( $*.s2) exists. If the target is out-of-date with
610 respect to this prerequisite, the commands for that inference rule
611 shall be executed.
612 If the target to be built does not contain a suffix and there is no
614 rule for the target, the single suffix inference rules shall be
615 checked. The single-suffix inference rules define how to build a target
616 if a file is found with a name that matches the target name with one of
617 the single suffixes appended. A rule with one suffix .s2 is the defini‐
618 tion of how to build target from target.s2. The other suffix ( .s1) is
619 treated as null.
620 A tilde ( '~' ) in the above rules refers to an SCCS file in the cur‐
622 rent directory. Thus, the rule .c~.o would transform an SCCS C-language
623 source file into an object file ( .o). Because the s. of the SCCS files
624 is a prefix, it is incompatible with make's suffix point of view.
625 Hence, the '~' is a way of changing any file reference into an SCCS
626 file reference.
627 Libraries
629 If a target or prerequisite contains parentheses, it shall be treated
630 as a member of an archive library. For the lib( member .o) expression
631 lib refers to the name of the archive library and member .o to the mem‐
632 ber name. The application shall ensure that the member is an object
633 file with the .o suffix. The modification time of the expression is the
634 modification time for the member as kept in the archive library; see ar
635 . The .a suffix shall refer to an archive library. The .s2.a rule shall
636 be used to update a member in the library from a file with a suffix
637 .s2.
638 Internal Macros
640 The make utility shall maintain five internal macros that can be used
641 in target and inference rules. In order to clearly define the meaning
642 of these macros, some clarification of the terms target rule, inference
643 rule, target, and prerequisite is necessary.
644 Target rules are specified by the user in a makefile for a particular
646 target. Inference rules are user-specified or make-specified rules for
647 a particular class of target name. Explicit prerequisites are those
648 prerequisites specified in a makefile on target lines. Implicit prereq‐
649 uisites are those prerequisites that are generated when inference rules
650 are used. Inference rules are applied to implicit prerequisites or to
651 explicit prerequisites that do not have target rules defined for them
652 in the makefile. Target rules are applied to targets specified in the
653 makefile.
654 Before any target in the makefile is updated, each of its prerequisites
656 (both explicit and implicit) shall be updated. This shall be accom‐
657 plished by recursively processing each prerequisite. Upon recursion,
658 each prerequisite shall become a target itself. Its prerequisites in
659 turn shall be processed recursively until a target is found that has no
660 prerequisites, at which point the recursion stops. The recursion shall
661 then back up, updating each target as it goes.
662 In the definitions that follow, the word target refers to one of:
664 * A target specified in the makefile
666 * An explicit prerequisite specified in the makefile that becomes the
668 target when make processes it during recursion
669 * An implicit prerequisite that becomes a target when make processes
671 it during recursion
672 In the definitions that follow, the word prerequisite refers to one of
674 the following:
675 * An explicit prerequisite specified in the makefile for a particular
677 target
678 * An implicit prerequisite generated as a result of locating an appro‐
680 priate inference rule and corresponding file that matches the suffix
681 of the target
682 The five internal macros are:
684 $@ The $@ shall evaluate to the full target name of the current
686 target, or the archive filename part of a library archive tar‐
687 get. It shall be evaluated for both target and inference rules.
688 For example, in the .c.a inference rule, $@ represents the out-of-date
690 .a file to be built. Similarly, in a makefile target rule to build
691 lib.a from file.c, $@ represents the out-of-date lib.a.
692 $% The $% macro shall be evaluated only when the current target is
694 an archive library member of the form libname( member .o). In
695 these cases, $@ shall evaluate to libname and $% shall evaluate
696 to member .o. The $% macro shall be evaluated for both target
697 and inference rules.
698 For example, in a makefile target rule to build lib.a( file.o), $% rep‐
700 resents file.o, as opposed to $@, which represents lib.a.
701 $? The $? macro shall evaluate to the list of prerequisites that
703 are newer than the current target. It shall be evaluated for
704 both target and inference rules.
705 For example, in a makefile target rule to build prog from file1.o,
707 file2.o, and file3.o, and where prog is not out-of-date with respect to
708 file1.o, but is out-of-date with respect to file2.o and file3.o, $?
709 represents file2.o and file3.o.
710 $< In an inference rule, the $< macro shall evaluate to the file‐
712 name whose existence allowed the inference rule to be chosen for
713 the target. In the .DEFAULT rule, the $< macro shall evaluate to
714 the current target name. The meaning of the $< macro shall be
715 otherwise unspecified.
716 For example, in the .c.a inference rule, $< represents the prerequisite
718 .c file.
719 $* The $* macro shall evaluate to the current target name with its
721 suffix deleted. It shall be evaluated at least for inference
722 rules.
723 For example, in the .c.a inference rule, $*.o represents the out-of-
725 date .o file that corresponds to the prerequisite .c file.
726 Each of the internal macros has an alternative form. When an uppercase
729 'D' or 'F' is appended to any of the macros, the meaning shall be
730 changed to the directory part for 'D' and filename part for 'F' . The
731 directory part is the path prefix of the file without a trailing slash;
732 for the current directory, the directory part is '.' . When the $?
733 macro contains more than one prerequisite filename, the $(?D) and $(?F)
734 (or ${?D} and ${?F}) macros expand to a list of directory name parts
735 and filename parts respectively.
736 For the target lib( member .o) and the s2.a rule, the internal macros
738 shall be defined as:
739 $< member .s2
741 $* member
743 $@ lib
745 $? member .s2
747 $% member .o
749 Default Rules
752 The default rules for make shall achieve results that are the same as
753 if the following were used. Implementations that do not support the C-
754 Language Development Utilities option may omit CC, CFLAGS, YACC,
755 YFLAGS, LEX, LFLAGS, LDFLAGS, and the .c, .y, and .l inference rules.
756 Implementations that do not support FORTRAN may omit FC, FFLAGS, and
757 the .f inference rules. Implementations may provide additional macros
758 and rules.
759 SPECIAL TARGETS
762 .SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@
765 .SUFFIXES: .o .c .y .l .a .sh .f .c~ .y~ .l~ .sh~ .f~
770 MACROS
773 MAKE=make
775 AR=ar
776 ARFLAGS=-rv
777 YACC=yacc
778 YFLAGS=
779 LEX=lex
780 LFLAGS=
781 LDFLAGS=
782 CC=c99
783 CFLAGS=-O
784 FC=fort77
785 FFLAGS=-O 1
786 GET=get
788 GFLAGS=
789 SCCSFLAGS=
790 SCCSGETFLAGS=-s
791 SINGLE SUFFIX RULES
795 .c:
797 $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $<
798 .f:
801 $(FC) $(FFLAGS) $(LDFLAGS) -o $@ $<
802 .sh:
805 cp $< $@
806 chmod a+x $@
807 .c~:
811 $(GET) $(GFLAGS) -p $< > $*.c
812 $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $*.c
813 .f~:
816 $(GET) $(GFLAGS) -p $< > $*.f
817 $(FC) $(FFLAGS) $(LDFLAGS) -o $@ $*.f
818 .sh~:
821 $(GET) $(GFLAGS) -p $< > $*.sh
822 cp $*.sh $@
823 chmod a+x $@
824 DOUBLE SUFFIX RULES
828 .c.o:
830 $(CC) $(CFLAGS) -c $<
831 .f.o:
834 $(FC) $(FFLAGS) -c $<
835 .y.o:
838 $(YACC) $(YFLAGS) $<
839 $(CC) $(CFLAGS) -c y.tab.c
840 rm -f y.tab.c
841 mv y.tab.o $@
842 .l.o:
845 $(LEX) $(LFLAGS) $<
846 $(CC) $(CFLAGS) -c lex.yy.c
847 rm -f lex.yy.c
848 mv lex.yy.o $@
849 .y.c:
852 $(YACC) $(YFLAGS) $<
853 mv y.tab.c $@
854 .l.c:
857 $(LEX) $(LFLAGS) $<
858 mv lex.yy.c $@
859 .c~.o:
863 $(GET) $(GFLAGS) -p $< > $*.c
864 $(CC) $(CFLAGS) -c $*.c
865 .f~.o:
868 $(GET) $(GFLAGS) -p $< > $*.f
869 $(FC) $(FFLAGS) -c $*.f
870 .y~.o:
873 $(GET) $(GFLAGS) -p $< > $*.y
874 $(YACC) $(YFLAGS) $*.y
875 $(CC) $(CFLAGS) -c y.tab.c
876 rm -f y.tab.c
877 mv y.tab.o $@
878 .l~.o:
881 $(GET) $(GFLAGS) -p $< > $*.l
882 $(LEX) $(LFLAGS) $*.l
883 $(CC) $(CFLAGS) -c lex.yy.c
884 rm -f lex.yy.c
885 mv lex.yy.o $@
886 .y~.c:
889 $(GET) $(GFLAGS) -p $< > $*.y
890 $(YACC) $(YFLAGS) $*.y
891 mv y.tab.c $@
892 .l~.c:
895 $(GET) $(GFLAGS) -p $< > $*.l
896 $(LEX) $(LFLAGS) $*.l
897 mv lex.yy.c $@
898 .c.a:
902 $(CC) -c $(CFLAGS) $<
903 $(AR) $(ARFLAGS) $@ $*.o
904 rm -f $*.o
905 .f.a:
908 $(FC) -c $(FFLAGS) $<
909 $(AR) $(ARFLAGS) $@ $*.o
910 rm -f $*.o
911
913 When the -q option is specified, the make utility shall exit with one
914 of the following values:
915 0 Successful completion.
917 1 The target was not up-to-date.
919 >1 An error occurred.
921 When the -q option is not specified, the make utility shall exit with
924 one of the following values:
925 0 Successful completion.
927 >0 An error occurred.
929
932 Default.
933 The following sections are informative.
935
937 If there is a source file (such as ./source.c) and there are two SCCS
938 files corresponding to it ( ./s.source.c and ./SCCS/s.source.c), on
939 XSI-conformant systems make uses the SCCS file in the current direc‐
940 tory. However, users are advised to use the underlying SCCS utilities (
941 admin, delta, get, and so on) or the sccs utility for all source files
942 in a given directory. If both forms are used for a given source file,
943 future developers are very likely to be confused.
944 It is incumbent upon portable makefiles to specify the .POSIX special
946 target in order to guarantee that they are not affected by local exten‐
947 sions.
948 The -k and -S options are both present so that the relationship between
950 the command line, the MAKEFLAGS variable, and the makefile can be con‐
951 trolled precisely. If the k flag is passed in MAKEFLAGS and a command
952 is of the form:
953 $(MAKE) -S foo
956 then the default behavior is restored for the child make.
958 When the -n option is specified, it is always added to MAKEFLAGS . This
960 allows a recursive make -n target to be used to see all of the action
961 that would be taken to update target.
962 Because of widespread historical practice, interpreting a '#' number
964 sign inside a variable as the start of a comment has the unfortunate
965 side effect of making it impossible to place a number sign in a vari‐
966 able, thus forbidding something like:
967 CFLAGS = "-D COMMENT_CHAR='#'"
970 Many historical make utilities stop chaining together inference rules
972 when an intermediate target is nonexistent. For example, it might be
973 possible for a make to determine that both .y.c and .c.o could be used
974 to convert a .y to a .o. Instead, in this case, make requires the use
975 of a .y.o rule.
976 The best way to provide portable makefiles is to include all of the
978 rules needed in the makefile itself. The rules provided use only fea‐
979 tures provided by other parts of this volume of IEEE Std 1003.1-2001.
980 The default rules include rules for optional commands in this volume of
981 IEEE Std 1003.1-2001. Only rules pertaining to commands that are pro‐
982 vided are needed in an implementation's default set.
983 Macros used within other macros are evaluated when the new macro is
985 used rather than when the new macro is defined. Therefore:
986 MACRO = value1NEW = $(MACRO)
989 MACRO = value2
990 target:
992 echo $(NEW)
993 would produce value2 and not value1 since NEW was not expanded until it
995 was needed in the echo command line.
996 Some historical applications have been known to intermix target_name
998 and macro=name operands on the command line, expecting that all of the
999 macros are processed before any of the targets are dealt with. Conform‐
1000 ing applications do not do this, although some backwards-compatibility
1001 support may be included in some implementations.
1002 The following characters in filenames may give trouble: '=' , ':' , '`'
1004 , '" , and '@' . For inference rules, the description of $< and $? seem
1005 similar. However, an example shows the minor difference. In a makefile
1006 containing:
1007 foo.o: foo.h
1010 if foo.h is newer than foo.o, yet foo.c is older than foo.o, the built-
1012 in rule to make foo.o from foo.c is used, with $< equal to foo.c and $?
1013 equal to foo.h. If foo.c is also newer than foo.o, $< is equal to foo.c
1014 and $? is equal to foo.h foo.c.
1015
1017 1. The following command:
1018 make
1021 makes the first target found in the makefile.
1023 2. The following command:
1025 make junk
1028 makes the target junk.
1030 3. The following makefile says that pgm depends on two files, a.o and
1032 b.o, and that they in turn depend on their corresponding source
1033 files ( a.c and b.c), and a common file incl.h:
1034 pgm: a.o b.o
1037 c99 a.o b.o -o pgm
1038 a.o: incl.h a.c
1039 c99 -c a.c
1040 b.o: incl.h b.c
1041 c99 -c b.c
1042 4. An example for making optimized .o files from .c files is:
1044 .c.o:
1047 c99 -c -O $*.c
1048 or:
1050 .c.o:
1053 c99 -c -O $<
1054 5. The most common use of the archive interface follows. Here, it is
1056 assumed that the source files are all C-language source:
1057 lib: lib(file1.o) lib(file2.o) lib(file3.o)
1060 @echo lib is now up-to-date
1061 The .c.a rule is used to make file1.o, file2.o, and file3.o and insert
1063 them into lib.
1064 The treatment of escaped <newline>s throughout the makefile is histori‐
1066 cal practice. For example, the inference rule:
1067 .c.o\
1070 :
1071 works, and the macro:
1073 f= bar baz\
1076 biz
1077 a:
1078 echo ==$f==
1079 echoes "==bar baz biz==" .
1081 If $? were:
1083 /usr/include/stdio.h /usr/include/unistd.h foo.h
1086 then $(?D) would be:
1088 /usr/include /usr/include .
1091 and $(?F) would be:
1093 stdio.h unistd.h foo.h
1096 6. The contents of the built-in rules can be viewed by running:
1098 make -p -f /dev/null 2>/dev/null
1101
1103 The make utility described in this volume of IEEE Std 1003.1-2001 is
1104 intended to provide the means for changing portable source code into
1105 executables that can be run on an IEEE Std 1003.1-2001-conforming sys‐
1106 tem. It reflects the most common features present in System V and BSD
1107 makes.
1108 Historically, the make utility has been an especially fertile ground
1110 for vendor and research organization-specific syntax modifications and
1111 extensions. Examples include:
1112 * Syntax supporting parallel execution (such as from various multi-
1114 processor vendors, GNU, and others)
1115 * Additional "operators" separating targets and their prerequisites
1117 (System V, BSD, and others)
1118 * Specifying that command lines containing the strings "${MAKE}" and
1120 "$(MAKE)" are executed when the -n option is specified (GNU and Sys‐
1121 tem V)
1122 * Modifications of the meaning of internal macros when referencing
1124 libraries (BSD and others)
1125 * Using a single instance of the shell for all of the command lines of
1127 the target (BSD and others)
1128 * Allowing spaces as well as tabs to delimit command lines (BSD)
1130 * Adding C preprocessor-style "include" and "ifdef" constructs (System
1132 V, GNU, BSD, and others)
1133 * Remote execution of command lines (Sprite and others)
1135 * Specifying additional special targets (BSD, System V, and most oth‐
1137 ers)
1138 Additionally, many vendors and research organizations have rethought
1140 the basic concepts of make, creating vastly extended, as well as com‐
1141 pletely new, syntaxes. Each of these versions of make fulfills the
1142 needs of a different community of users; it is unreasonable for this
1143 volume of IEEE Std 1003.1-2001 to require behavior that would be incom‐
1144 patible (and probably inferior) to historical practice for such a com‐
1145 munity.
1146 In similar circumstances, when the industry has enough sufficiently
1148 incompatible formats as to make them irreconcilable, this volume of
1149 IEEE Std 1003.1-2001 has followed one or both of two courses of action.
1150 Commands have been renamed ( cksum, echo, and pax) and/or command line
1151 options have been provided to select the desired behavior ( grep, od,
1152 and pax).
1153 Because the syntax specified for the make utility is, by and large, a
1155 subset of the syntaxes accepted by almost all versions of make, it was
1156 decided that it would be counter-productive to change the name. And
1157 since the makefile itself is a basic unit of portability, it would not
1158 be completely effective to reserve a new option letter, such as make
1159 -P, to achieve the portable behavior. Therefore, the special target
1160 .POSIX was added to the makefile, allowing users to specify "standard"
1161 behavior. This special target does not preclude extensions in the make
1162 utility, nor does it preclude such extensions being used by the make‐
1163 file specifying the target; it does, however, preclude any extensions
1164 from being applied that could alter the behavior of previously valid
1165 syntax; such extensions must be controlled via command line options or
1166 new special targets. It is incumbent upon portable makefiles to specify
1167 the .POSIX special target in order to guarantee that they are not
1168 affected by local extensions.
1169 The portable version of make described in this reference page is not
1171 intended to be the state-of-the-art software generation tool and, as
1172 such, some newer and more leading-edge features have not been included.
1173 An attempt has been made to describe the portable makefile in a manner
1174 that does not preclude such extensions as long as they do not disturb
1175 the portable behavior described here.
1176 When the -n option is specified, it is always added to MAKEFLAGS . This
1178 allows a recursive make -n target to be used to see all of the action
1179 that would be taken to update target.
1180 The definition of MAKEFLAGS allows both the System V letter string and
1182 the BSD command line formats. The two formats are sufficiently differ‐
1183 ent to allow implementations to support both without ambiguity.
1184 Early proposals stated that an "unquoted" number sign was treated as
1186 the start of a comment. The make utility does not pay any attention to
1187 quotes. A number sign starts a comment regardless of its surroundings.
1188 The text about "other implementation-defined pathnames may also be
1190 tried" in addition to ./makefile and ./Makefile is to allow such exten‐
1191 sions as SCCS/s.Makefile and other variations. It was made an implemen‐
1192 tation-defined requirement (as opposed to unspecified behavior) to
1193 highlight surprising implementations that might select something unex‐
1194 pected like /etc/Makefile. XSI-conformant systems also try ./s.make‐
1195 file, SCCS/s.makefile, ./s.Makefile, and SCCS/s.Makefile.
1196 Early proposals contained the macro NPROC as a means of specifying that
1198 make should use n processes to do the work required. While this feature
1199 is a valuable extension for many systems, it is not common usage and
1200 could require other non-trivial extensions to makefile syntax. This
1201 extension is not required by this volume of IEEE Std 1003.1-2001, but
1202 could be provided as a compatible extension. The macro PARALLEL is used
1203 by some historical systems with essentially the same meaning (but with‐
1204 out using a name that is a common system limit value). It is suggested
1205 that implementors recognize the existing use of NPROC and/or PARALLEL
1206 as extensions to make.
1207 The default rules are based on System V. The default CC= value is c99
1209 instead of cc because this volume of IEEE Std 1003.1-2001 does not
1210 standardize the utility named cc. Thus, every conforming application
1211 would be required to define CC= c99 to expect to run. There is no
1212 advantage conferred by the hope that the makefile might hit the "pre‐
1213 ferred" compiler because this cannot be guaranteed to work. Also, since
1214 the portable makescript can only use the c99 options, no advantage is
1215 conferred in terms of what the script can do. It is a quality-of-imple‐
1216 mentation issue as to whether c99 is as valuable as cc.
1217 The -d option to make is frequently used to produce debugging informa‐
1219 tion, but is too implementation-defined to add to this volume of
1220 IEEE Std 1003.1-2001.
1221 The -p option is not passed in MAKEFLAGS on most historical implementa‐
1223 tions and to change this would cause many implementations to break
1224 without sufficiently increased portability.
1225 Commands that begin with a plus sign ( '+' ) are executed even if the
1227 -n option is present. Based on the GNU version of make, the behavior of
1228 -n when the plus-sign prefix is encountered has been extended to apply
1229 to -q and -t as well. However, the System V convention of forcing com‐
1230 mand execution with -n when the command line of a target contains
1231 either of the strings "$(MAKE)" or "${MAKE}" has not been adopted. This
1232 functionality appeared in early proposals, but the danger of this
1233 approach was pointed out with the following example of a portion of a
1234 makefile:
1235 subdir:
1238 cd subdir; rm all_the_files; $(MAKE)
1239 The loss of the System V behavior in this case is well-balanced by the
1241 safety afforded to other makefiles that were not aware of this situa‐
1242 tion. In any event, the command line plus-sign prefix can provide the
1243 desired functionality.
1244 The double colon in the target rule format is supported in BSD systems
1246 to allow more than one target line containing the same target name to
1247 have commands associated with it. Since this is not functionality
1248 described in the SVID or XPG3 it has been allowed as an extension, but
1249 not mandated.
1250 The default rules are provided with text specifying that the built-in
1252 rules shall be the same as if the listed set were used. The intent is
1253 that implementations should be able to use the rules without change,
1254 but will be allowed to alter them in ways that do not affect the pri‐
1255 mary behavior.
1256 The best way to provide portable makefiles is to include all of the
1258 rules needed in the makefile itself. The rules provided use only fea‐
1259 tures provided by other portions of this volume of
1260 IEEE Std 1003.1-2001. The default rules include rules for optional
1261 commands in this volume of IEEE Std 1003.1-2001. Only rules pertaining
1262 to commands that are provided are needed in the default set of an
1263 implementation.
1264 One point of discussion was whether to drop the default rules list from
1266 this volume of IEEE Std 1003.1-2001. They provide convenience, but do
1267 not enhance portability of applications. The prime benefit is in
1268 portability of users who wish to type make command and have the command
1269 build from a command.c file.
1270 The historical MAKESHELL feature was omitted. In some implementations
1272 it is used to let a user override the shell to be used to run make com‐
1273 mands. This was confusing; for a portable make, the shell should be
1274 chosen by the makefile writer or specified on the make command line and
1275 not by a user running make.
1276 The make utilities in most historical implementations process the pre‐
1278 requisites of a target in left-to-right order, and the makefile format
1279 requires this. It supports the standard idiom used in many makefiles
1280 that produce yacc programs; for example:
1281 foo: y.tab.o lex.o main.o
1284 $(CC) $(CFLAGS) -o $@ t.tab.o lex.o main.o
1285 In this example, if make chose any arbitrary order, the lex.o might not
1287 be made with the correct y.tab.h. Although there may be better ways to
1288 express this relationship, it is widely used historically. Implementa‐
1289 tions that desire to update prerequisites in parallel should require an
1290 explicit extension to make or the makefile format to accomplish it, as
1291 described previously.
1292 The algorithm for determining a new entry for target rules is partially
1294 unspecified. Some historical makes allow blank, empty, or comment lines
1295 within the collection of commands marked by leading <tab>s. A conform‐
1296 ing makefile must ensure that each command starts with a <tab>, but
1297 implementations are free to ignore blank, empty, and comment lines
1298 without triggering the start of a new entry.
1299 The ASYNCHRONOUS EVENTS section includes having SIGTERM and SIGHUP,
1301 along with the more traditional SIGINT and SIGQUIT, remove the current
1302 target unless directed not to do so. SIGTERM and SIGHUP were added to
1303 parallel other utilities that have historically cleaned up their work
1304 as a result of these signals. When make receives any signal other than
1305 SIGQUIT, it is required to resend itself the signal it received so that
1306 it exits with a status that reflects the signal. The results from
1307 SIGQUIT are partially unspecified because, on systems that create core
1308 files upon receipt of SIGQUIT, the core from make would conflict with a
1309 core file from the command that was running when the SIGQUIT arrived.
1310 The main concern was to prevent damaged files from appearing up-to-date
1311 when make is rerun.
1312 The .PRECIOUS special target was extended to affect all targets glob‐
1314 ally (by specifying no prerequisites). The .IGNORE and .SILENT special
1315 targets were extended to allow prerequisites; it was judged to be more
1316 useful in some cases to be able to turn off errors or echoing for a
1317 list of targets than for the entire makefile. These extensions to make
1318 in System V were made to match historical practice from the BSD make.
1319 Macros are not exported to the environment of commands to be run. This
1321 was never the case in any historical make and would have serious conse‐
1322 quences. The environment is the same as the environment to make except
1323 that MAKEFLAGS and macros defined on the make command line are added.
1324 Some implementations do not use system() for all command lines, as
1326 required by the portable makefile format; as a performance enhancement,
1327 they select lines without shell metacharacters for direct execution by
1328 execve(). There is no requirement that system() be used specifically,
1329 but merely that the same results be achieved. The metacharacters typi‐
1330 cally used to bypass the direct execve() execution have been any of:
1331 = | ^ ( ) ; & < > * ? [ ] : $ ` ' " \ \n
1334 The default in some advanced versions of make is to group all the com‐
1336 mand lines for a target and execute them using a single shell invoca‐
1337 tion; the System V method is to pass each line individually to a sepa‐
1338 rate shell. The single-shell method has the advantages in performance
1339 and the lack of a requirement for many continued lines. However, con‐
1340 verting to this newer method has caused portability problems with many
1341 historical makefiles, so the behavior with the POSIX makefile is speci‐
1342 fied to be the same as that of System V. It is suggested that the spe‐
1343 cial target .ONESHELL be used as an implementation extension to achieve
1344 the single-shell grouping for a target or group of targets.
1345 Novice users of make have had difficulty with the historical need to
1347 start commands with a <tab>. Since it is often difficult to discern
1348 differences between <tab>s and <space>s on terminals or printed list‐
1349 ings, confusing bugs can arise. In early proposals, an attempt was made
1350 to correct this problem by allowing leading <blank>s instead of <tab>s.
1351 However, implementors reported many makefiles that failed in subtle
1352 ways following this change, and it is difficult to implement a make
1353 that unambiguously can differentiate between macro and command lines.
1354 There is extensive historical practice of allowing leading spaces
1355 before macro definitions. Forcing macro lines into column 1 would be a
1356 significant backwards-compatibility problem for some makefiles. There‐
1357 fore, historical practice was restored.
1358 The System V INCLUDE feature was considered, but not included. This
1360 would treat a line that began in the first column and contained INCLUDE
1361 <filename> as an indication to read <filename> at that point in the
1362 makefile. This is difficult to use in a portable way, and it raises
1363 concerns about nesting levels and diagnostics. System V, BSD, GNU, and
1364 others have used different methods for including files.
1365 The System V dynamic dependency feature was not included. It would sup‐
1367 port:
1368 cat: $$@.c
1371 that would expand to;
1373 cat: cat.c
1376 This feature exists only in the new version of System V make and, while
1378 useful, is not in wide usage. This means that macros are expanded twice
1379 for prerequisites: once at makefile parse time and once at target
1380 update time.
1381 Consideration was given to adding metarules to the POSIX make. This
1383 would make %.o: %.c the same as .c.o:. This is quite useful and avail‐
1384 able from some vendors, but it would cause too many changes to this
1385 make to support. It would have introduced rule chaining and new substi‐
1386 tution rules. However, the rules for target names have been set to
1387 reserve the '%' and '' characters. These are traditionally used to
1388 implement metarules and quoting of target names, respectively. Imple‐
1389 mentors are strongly encouraged to use these characters only for these
1390 purposes.
1391 A request was made to extend the suffix delimiter character from a
1393 period to any character. The metarules feature in newer makes solves
1394 this problem in a more general way. This volume of IEEE Std 1003.1-2001
1395 is staying with the more conservative historical definition.
1396 The standard output format for the -p option is not described because
1398 it is primarily a debugging option and because the format is not gener‐
1399 ally useful to programs. In historical implementations the output is
1400 not suitable for use in generating makefiles. The -p format has been
1401 variable across historical implementations. Therefore, the definition
1402 of -p was only to provide a consistently named option for obtaining
1403 make script debugging information.
1404 Some historical implementations have not cleared the suffix list with
1406 -r.
1407 Implementations should be aware that some historical applications have
1409 intermixed target_name and macro= value operands on the command line,
1410 expecting that all of the macros are processed before any of the tar‐
1411 gets are dealt with. Conforming applications do not do this, but some
1412 backwards-compatibility support may be warranted.
1413 Empty inference rules are specified with a semicolon command rather
1415 than omitting all commands, as described in an early proposal. The lat‐
1416 ter case has no traditional meaning and is reserved for implementation
1417 extensions, such as in GNU make.
1418
1420 None.
1421
1423 Shell Command Language , ar , c99 , get , lex , sccs , sh , yacc , the
1424 System Interfaces volume of IEEE Std 1003.1-2001, exec, system()
1425
1427 Portions of this text are reprinted and reproduced in electronic form
1428 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
1429 -- Portable Operating System Interface (POSIX), The Open Group Base
1430 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
1431 Electrical and Electronics Engineers, Inc and The Open Group. In the
1432 event of any discrepancy between this version and the original IEEE and
1433 The Open Group Standard, the original IEEE and The Open Group Standard
1434 is the referee document. The original Standard can be obtained online
1435 at http://www.opengroup.org/unix/online.html .
1436IEEE/The Open Group 2003 MAKE(P)