👤
Home Man
Search
Today's Posts
Register

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

Linux 2.6 - man page for make (linux section 1posix)

MAKE(P) 			    POSIX Programmer's Manual				  MAKE(P)

NAME
       make - maintain, update, and regenerate groups of programs (DEVELOPMENT)

SYNOPSIS
       make [-einpqrst][-f makefile]...[ -k| -S][macro=value]...
	      [target_name...]

DESCRIPTION
       The  make  utility shall update files that are derived from other files. A typical case is
       one where object files are derived from the corresponding source files. The  make  utility
       examines  time  relationships  and  shall update those derived files (called targets) that
       have modified times earlier than the modified times of the  files  (called  prerequisites)
       from  which  they are derived. A description file (makefile) contains a description of the
       relationships between files, and the commands that need to be executed to update the  tar-
       gets  to  reflect changes in their prerequisites.  Each specification, or rule, shall con-
       sist of a target, optional prerequisites, and optional commands to be executed when a pre-
       requisite is newer than the target. There are two types of rule:

	1. Inference  rules,  which  have one target name with at least one period ( '.' ) and no
	   slash ( '/' )

	2. Target rules, which can have more than one target name

       In addition, make shall have a collection of built-in  macros  and  inference  rules  that
       infer prerequisite relationships to simplify maintenance of programs.

       To  receive  exactly  the behavior described in this section, the user shall ensure that a
       portable makefile shall:

	* Include the special target .POSIX

	* Omit any special target reserved for implementations	(a  leading  period  followed  by
	  uppercase letters) that has not been specified by this section

       The behavior of make is unspecified if either or both of these conditions are not met.

OPTIONS
       The  make  utility  shall  conform to the Base Definitions volume of IEEE Std 1003.1-2001,
       Section 12.2, Utility Syntax Guidelines.

       The following options shall be supported:

       -e     Cause environment variables, including those with null values,  to  override  macro
	      assignments within makefiles.

       -f  makefile
	      Specify  a different makefile. The argument makefile is a pathname of a description
	      file, which is also referred to as the makefile. A pathname of '-' shall denote the
	      standard	input.	There can be multiple instances of this option, and they shall be
	      processed in the order specified. The effect of specifying the same option-argument
	      more than once is unspecified.

       -i     Ignore  error  codes  returned by invoked commands. This mode is the same as if the
	      special target .IGNORE were specified without prerequisites.

       -k     Continue to update other targets that do not depend on the current target if a non-
	      ignored error occurs while executing the commands to bring a target up-to-date.

       -n     Write  commands that would be executed on standard output, but do not execute them.
	      However, lines with a plus sign ( '+' ) prefix shall be  executed.  In  this  mode,
	      lines with an at sign ( '@' ) character prefix shall be written to standard output.

       -p     Write  to standard output the complete set of macro definitions and target descrip-
	      tions. The output format is unspecified.

       -q     Return a zero exit value if the target file is  up-to-date;  otherwise,  return  an
	      exit value of 1. Targets shall not be updated if this option is specified. However,
	      a makefile command line (associated with the targets) with a plus sign ( '+' ) pre-
	      fix shall be executed.

       -r     Clear the suffix list and do not use the built-in rules.

       -S     Terminate  make  if  an error occurs while executing the commands to bring a target
	      up-to-date. This shall be the default and the opposite of -k.

       -s     Do not write makefile command lines or touch messages (see -t) to  standard  output
	      before executing. This mode shall be the same as if the special target .SILENT were
	      specified without prerequisites.

       -t     Update the modification time of each target as though a touch target had been  exe-
	      cuted. Targets that have prerequisites but no commands (see Target Rules ), or that
	      are already up-to-date, shall not be touched in  this  manner.  Write  messages  to
	      standard	output	for  each target file indicating the name of the file and that it
	      was touched. Normally, the makefile command lines associated with each  target  are
	      not  executed.   However,  a  command line with a plus sign ( '+' ) prefix shall be
	      executed.

       Any options specified in the MAKEFLAGS environment variable shall be evaluated before  any
       options	specified  on  the  make  utility command line. If the -k and -S options are both
       specified on the make utility command line or by the MAKEFLAGS environment  variable,  the
       last  option  specified shall take precedence. If the -f or -p options appear in the MAKE-
       FLAGS environment variable, the result is undefined.

OPERANDS
       The following operands shall be supported:

       target_name
	      Target names, as defined in the EXTENDED DESCRIPTION section. If no target is spec-
	      ified,  while  make is processing the makefiles, the first target that make encoun-
	      ters that is not a special target or an inference rule shall be used.

       macro=value
	      Macro definitions, as defined in Macros .

       If the target_name and macro= value operands are intermixed on the  make  utility  command
       line, the results are unspecified.

STDIN
       The  standard  input  shall  be used only if the makefile option-argument is '-' . See the
       INPUT FILES section.

INPUT FILES
       The input file, otherwise known as the makefile, is a text file	containing  rules,  macro
       definitions, and comments. See the EXTENDED DESCRIPTION section.

ENVIRONMENT VARIABLES
       The following environment variables shall affect the execution of make:

       LANG   Provide  a  default  value for the internationalization variables that are unset or
	      null. (See the Base Definitions volume of IEEE Std 1003.1-2001, Section 8.2, Inter-
	      nationalization Variables for the precedence of internationalization variables used
	      to determine the values of locale categories.)

       LC_ALL If set to a non-empty string value, override the values of all the  other  interna-
	      tionalization variables.

       LC_CTYPE
	      Determine  the  locale for the interpretation of sequences of bytes of text data as
	      characters (for example, single-byte as opposed to multi-byte characters	in  argu-
	      ments and input files).

       LC_MESSAGES
	      Determine the locale that should be used to affect the format and contents of diag-
	      nostic messages written to standard error.

       MAKEFLAGS

	      This variable shall be interpreted as a character string representing a  series  of
	      option  characters  to  be  used	as  the default options. The implementation shall
	      accept both of the following formats (but need not accept them when intermixed):

	       * The characters are option letters without the leading hyphens or <blank> separa-
		 tion used on a make utility command line.

	       * The  characters are formatted in a manner similar to a portion of the make util-
		 ity command line: options are	preceded  by  hyphens  and  <blank>-separated  as
		 described  in the Base Definitions volume of IEEE Std 1003.1-2001, Section 12.2,
		 Utility Syntax Guidelines.  The macro= value macro definition operands can  also
		 be included. The difference between the contents of MAKEFLAGS and the make util-
		 ity command line is that the contents of the variable shall not be subjected  to
		 the  word  expansions (see Word Expansions ) associated with parsing the command
		 line values.

       NLSPATH
	      Determine the location of message catalogs for the processing of LC_MESSAGES .

       PROJECTDIR

	      Provide a directory to be used to search for SCCS files not found  in  the  current
	      directory.  In all of the following cases, the search for SCCS files is made in the
	      directory SCCS in the identified directory. If the value of PROJECTDIR begins  with
	      a  slash, it shall be considered an absolute pathname; otherwise, the value of PRO-
	      JECTDIR is treated as a user name and that user's initial working  directory  shall
	      be  examined  for  a  subdirectory  src or source. If such a directory is found, it
	      shall be used. Otherwise, the value is used as a relative pathname.

       If PROJECTDIR is not set or has a null value, the search for SCCS files shall be  made  in
       the directory SCCS in the current directory.

       The  setting  of  PROJECTDIR  affects  all  files  listed in the remainder of this utility
       description for files with a component named SCCS.

       The value of the SHELL environment variable shall not be used as a macro and shall not  be
       modified by defining the SHELL macro in a makefile or on the command line. All other envi-
       ronment variables, including those with null values, shall be used as macros,  as  defined
       in Macros .

ASYNCHRONOUS EVENTS
       If  not	already  ignored, make shall trap SIGHUP, SIGTERM, SIGINT, and SIGQUIT and remove
       the current target unless the target is a directory or the target is a prerequisite of the
       special	target	.PRECIOUS  or  unless one of the -n, -p, or -q options was specified. Any
       targets removed in this manner shall be reported in  diagnostic	messages  of  unspecified
       format, written to standard error. After this cleanup process, if any, make shall take the
       standard action for all other signals.

STDOUT
       The make utility shall write all commands to be executed to standard output unless the  -s
       option  was  specified,	the  command  is  prefixed with an at sign, or the special target
       .SILENT has either the current target as a prerequisite or has no prerequisites.  If  make
       is  invoked without any work needing to be done, it shall write a message to standard out-
       put indicating that no action was taken. If the	-t  option  is	present  and  a  file  is
       touched,  make  shall  write to standard output a message of unspecified format indicating
       that the file was touched, including the filename of the file.

STDERR
       The standard error shall be used only for diagnostic messages.

OUTPUT FILES
       Files can be created when the -t option is present. Additional files can also  be  created
       by the utilities invoked by make.

EXTENDED DESCRIPTION
       The  make  utility  attempts  to perform the actions required to ensure that the specified
       targets are up-to-date. A target is considered out-of-date if it is older than any of  its
       prerequisites  or  if it does not exist. The make utility shall treat all prerequisites as
       targets themselves and recursively ensure that they are up-to-date, processing them in the
       order  in which they appear in the rule. The make utility shall use the modification times
       of files to determine whether the corresponding targets are out-of-date.

       After make has ensured that all of the prerequisites of a target are up-to-date and if the
       target is out-of-date, the commands associated with the target entry shall be executed. If
       there are no commands listed for the target, the target shall be treated as up-to-date.

   Makefile Syntax
       A makefile can contain rules, macro definitions (see Macros ), and comments. There are two
       kinds  of rules: inference rules and target rules. The make utility shall contain a set of
       built-in inference rules.  If the -r option is present, the built-in rules  shall  not  be
       used and the suffix list shall be cleared. Additional rules of both types can be specified
       in a makefile. If a rule is defined more than once, the value of the rule shall be that of
       the  last  one  specified. Macros can also be defined more than once, and the value of the
       macro is specified in Macros . Comments start with a number sign  (  '#'  )  and  continue
       until an unescaped <newline> is reached.

       By  default, the following files shall be tried in sequence: ./makefile and ./Makefile. If
       neither ./makefile or ./Makefile are found, other implementation-defined files may also be
       tried.	  On  XSI-conformant systems, the additional files ./s.makefile, SCCS/s.makefile,
       ./s.Makefile, and SCCS/s.Makefile shall also be tried.

       The -f option shall direct make to ignore any of these default files and use the specified
       argument  as a makefile instead. If the '-' argument is specified, standard input shall be
       used.

       The term makefile is used to refer to any rules provided by the user, whether  in  ./make-
       file or its variants, or specified by the -f option.

       The  rules  in  makefiles  shall  consist  of  the following types of lines: target rules,
       including special targets (see Target Rules ), inference rules  (see  Inference	Rules  ),
       macro definitions (see Macros ), empty lines, and comments.

       When  an escaped <newline> (one preceded by a backslash) is found anywhere in the makefile
       except in a command line, it shall be replaced, along with any leading white space on  the
       following  line,  with  a  single <space>. When an escaped <newline> is found in a command
       line in a makefile, the command line shall contain the backslash, the <newline>,  and  the
       next line, except that the first character of the next line shall not be included if it is
       a <tab>.

   Makefile Execution
       Makefile command lines shall be processed one at a time by writing  the	makefile  command
       line  to the standard output (unless one of the conditions listed under '@' suppresses the
       writing) and executing the command(s) in the line. A <tab>  may	precede  the  command  to
       standard output. Command execution shall be as if the makefile command line were the argu-
       ment to the system() function. The environment for the command being executed  shall  con-
       tain all of the variables in the environment of make.

       By default, when make receives a non-zero status from the execution of a command, it shall
       terminate with an error message to standard error.

       Makefile command lines can have one or more of the following prefixes: a hyphen (  '-'  ),
       an  at sign ( '@' ), or a plus sign ( '+' ). These shall modify the way in which make pro-
       cesses the command. When a command is written to standard output, the prefix shall not  be
       included in the output.

       -      If  the  command prefix contains a hyphen, or the -i option is present, or the spe-
	      cial target .IGNORE has either the current target as a prerequisite or has no  pre-
	      requisites, any error found while executing the command shall be ignored.

       @      If  the  command	prefix	contains  an at sign and the make utility command line -n
	      option is not specified, or the -s option is present, or the special target .SILENT
	      has  either  the current target as a prerequisite or has no prerequisites, the com-
	      mand shall not be written to standard output before it is executed.

       +      If the command prefix contains a plus sign, this indicates a makefile command  line
	      that shall be executed even if -n, -q, or -t is specified.

   Target Rules
       Target rules are formatted as follows:

	      target [target...]: [prerequisite...][;command]
	      [<tab>command<tab>command...]

	      line that does not begin with <tab>

       Target  entries	are  specified	by  a <blank>-separated, non-null list of targets, then a
       colon, then a <blank>-separated, possibly empty list of prerequisites.  Text  following	a
       semicolon,  if  any, and all following lines that begin with a <tab>, are makefile command
       lines to be executed to update the target. The first non-empty line that  does  not  begin
       with  a	<tab> or '#' shall begin a new entry. An empty or blank line, or a line beginning
       with '#' , may begin a new entry.

       Applications shall select target names from the set of  characters  consisting  solely  of
       periods,  underscores,  digits,	and  alphabetics from the portable character set (see the
       Base Definitions volume of IEEE Std 1003.1-2001, Section  6.1,  Portable  Character  Set).
       Implementations	may allow other characters in target names as extensions. The interpreta-
       tion of targets containing the characters '%' and '' is implementation-defined.

       A target that has prerequisites, but does not have any commands, can be used to add to the
       prerequisite  list for that target.  Only one target rule for any given target can contain
       commands.

       Lines that begin with one of the following are called  special  targets	and  control  the
       operation of make:

       .DEFAULT
	      If  the  makefile uses this special target, the application shall ensure that it is
	      specified with commands, but without prerequisites. The commands shall be  used  by
	      make if there are no other rules available to build a target.

       .IGNORE
	      Prerequisites  of  this  special	target	are  targets themselves; this shall cause
	      errors from commands associated with them to be ignored in the same manner as spec-
	      ified  by the -i option. Subsequent occurrences of .IGNORE shall add to the list of
	      targets ignoring command errors. If no  prerequisites  are  specified,  make  shall
	      behave  as if the -i option had been specified and errors from all commands associ-
	      ated with all targets shall be ignored.

       .POSIX The application shall ensure that this special target is specified without  prereq-
	      uisites  or  commands. If it appears as the first non-comment line in the makefile,
	      make shall process the makefile as specified by this section; otherwise, the behav-
	      ior of make is unspecified.

       .PRECIOUS
	      Prerequisites  of  this special target shall not be removed if make receives one of
	      the asynchronous events explicitly described in the  ASYNCHRONOUS  EVENTS  section.
	      Subsequent occurrences of .PRECIOUS shall add to the list of precious files.  If no
	      prerequisites are specified, all targets in the makefile shall  be  treated  as  if
	      specified with .PRECIOUS.

       .SCCS_GET
	      The  application shall ensure that this special target is specified without prereq-
	      uisites. If this special target is included in a makefile, the  commands	specified
	      with  this  target  shall replace the default commands associated with this special
	      target (see Default Rules ). The commands specified with this target  are  used  to
	      get all SCCS files that are not found in the current directory.

       When  source  files  are  named	in a dependency list, make shall treat them just like any
       other target. Because the source file is presumed to be present in the directory, there is
       no  need to add an entry for it to the makefile. When a target has no dependencies, but is
       present in the directory, make shall assume that that file is up-to-date. If, however,  an
       SCCS  file  named SCCS/s. source_file is found for a target source_file, make compares the
       timestamp of the target file with that of the SCCS/s.source_file to ensure the  target  is
       up-to-date.  If	the target is missing, or if the SCCS file is newer, make shall automati-
       cally issue the commands specified for the .SCCS_GET special target to retrieve	the  most
       recent  version.  However,  if the target is writable by anyone, make shall not retrieve a
       new version.

       .SILENT
	      Prerequisites of this special target are targets themselves; this shall cause  com-
	      mands associated with them not to be written to the standard output before they are
	      executed. Subsequent occurrences of .SILENT shall add to the list of  targets  with
	      silent  commands. If no prerequisites are specified, make shall behave as if the -s
	      option had been specified and no commands or touch  messages  associated	with  any
	      target shall be written to standard output.

       .SUFFIXES
	      Prerequisites  of .SUFFIXES shall be appended to the list of known suffixes and are
	      used in conjunction with the inference rules (see Inference Rules ).  If	.SUFFIXES
	      does not have any prerequisites, the list of known suffixes shall be cleared.

       The  special targets .IGNORE, .POSIX, .PRECIOUS, .SILENT, and .SUFFIXES shall be specified
       without commands.

       Targets with names consisting of a  leading  period  followed  by  the  uppercase  letters
       "POSIX"	and  then  any	other characters are reserved for future standardization. Targets
       with names consisting of a leading period followed by one or more  uppercase  letters  are
       reserved for implementation extensions.

   Macros
       Macro definitions are in the form:

	      string1 = [string2]

       The  macro  named  string1  is  defined	as  having the value of string2, where string2 is
       defined as all characters, if any, after the equal sign, up to a comment character ( '#' )
       or  an  unescaped <newline>. Any <blank>s immediately before or after the equal sign shall
       be ignored.

       Applications shall select macro names from the set  of  characters  consisting  solely  of
       periods,  underscores,  digits,	and  alphabetics from the portable character set (see the
       Base Definitions volume of IEEE Std 1003.1-2001, Section 6.1, Portable Character  Set).	A
       macro  name  shall not contain an equals sign.  Implementations may allow other characters
       in macro names as extensions.

       Macros can appear anywhere in the makefile. Macro expansions using the forms  $(  string1)
       or ${ string1} shall be replaced by string2, as follows:

	* Macros in target lines shall be evaluated when the target line is read.

	* Macros in makefile command lines shall be evaluated when the command is executed.

	* Macros  in  the  string before the equals sign in a macro definition shall be evaluated
	  when the macro assignment is made.

	* Macros after the equals sign in a macro definition shall not	be  evaluated  until  the
	  defined  macro is used in a rule or command, or before the equals sign in a macro defi-
	  nition.

       The parentheses or braces are optional if string1 is a  single  character.  The	macro  $$
       shall be replaced by the single character '$' . If string1 in a macro expansion contains a
       macro expansion, the results are unspecified.

       Macro expansions using the forms $( string1 [: subst1 =[  subst2  ]])  or  ${  string1  [:
       subst1 =[ subst2 ]]} can be used to replace all occurrences of subst1 with subst2 when the
       macro substitution is performed. The subst1 to be replaced shall be recognized when it  is
       a  suffix at the end of a word in string1 (where a word, in this context, is defined to be
       a string delimited by the beginning of the line, a <blank>, or a <newline>). If string1 in
       a macro expansion contains a macro expansion, the results are unspecified.

       Macro  expansions in string1 of macro definition lines shall be evaluated when read. Macro
       expansions in string2 of macro definition lines shall be performed when the macro  identi-
       fied by string1 is expanded in a rule or command.

       Macro  definitions  shall  be  taken  from the following sources, in the following logical
       order, before the makefile(s) are read.

	1. Macros specified on the make utility command line, in the order specified on the  com-
	   mand  line.	It  is unspecified whether the internal macros defined in Internal Macros
	   are accepted from this source.

	2. Macros defined by the MAKEFLAGS environment variable, in the order  specified  in  the
	   environment	variable. It is unspecified whether the internal macros defined in Inter-
	   nal Macros are accepted from this source.

	3. The contents of the environment, excluding  the  MAKEFLAGS  and  SHELL  variables  and
	   including the variables with null values.

	4. Macros defined in the inference rules built into make.

       Macro  definitions  from  these sources shall not override macro definitions from a lower-
       numbered source. Macro definitions from a single source (for  example,  the  make  utility
       command	line,  the  MAKEFLAGS  environment  variable, or the other environment variables)
       shall override previous macro definitions from the same source.

       Macros defined in the makefile(s) shall override macro definitions that occur before  them
       in the makefile(s) and macro definitions from source 4. If the -e option is not specified,
       macros defined in the makefile(s) shall override macro definitions from source  3.  Macros
       defined in the makefile(s) shall not override macro definitions from source 1 or source 2.

       Before  the  makefile(s) are read, all of the make utility command line options (except -f
       and -p) and make utility command line macro definitions	(except  any  for  the	MAKEFLAGS
       macro),	not  already  included	in  the  MAKEFLAGS macro, shall be added to the MAKEFLAGS
       macro, quoted in an implementation-defined manner such that  when  MAKEFLAGS  is  read  by
       another	instance  of  the  make  command,  the original macro's value is recovered. Other
       implementation-defined options and macros may also be added to  the  MAKEFLAGS  macro.  If
       this  modifies the value of the MAKEFLAGS macro, or, if the MAKEFLAGS macro is modified at
       any subsequent time, the MAKEFLAGS environment variable shall be modified to match the new
       value  of the MAKEFLAGS macro. The result of setting MAKEFLAGS in the Makefile is unspeci-
       fied.

       Before the makefile(s) are read, all of the make utility command  line  macro  definitions
       (except the MAKEFLAGS macro or the SHELL macro) shall be added to the environment of make.
       Other implementation-defined variables may also be added to the environment of make.

       The SHELL macro shall be treated specially. It shall be provided by make and  set  to  the
       pathname  of the shell command language interpreter (see sh ). The SHELL environment vari-
       able shall not affect the value of the SHELL macro. If SHELL is defined in the makefile or
       is  specified on the command line, it shall replace the original value of the SHELL macro,
       but shall not affect the SHELL environment variable. Other effects of  defining	SHELL  in
       the makefile or on the command line are implementation-defined.

   Inference Rules
       Inference rules are formatted as follows:

	      target:
	      <tab>command
	      [<tab>command]...

	      line that does not begin with <tab> or #

       The  application  shall	ensure that the target portion is a valid target name (see Target
       Rules ) of the form .s2 or .s1.s2 (where .s1 and .s2 are suffixes that have been given  as
       prerequisites  of the .SUFFIXES special target and s1 and s2 do not contain any slashes or
       periods.) 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.  Inference rules can have only
       one target before the colon.

       The application shall ensure that the makefile does not specify prerequisites  for  infer-
       ence rules; no characters other than white space shall follow the colon in the first line,
       except when creating the empty rule,  described	below.	Prerequisites  are  inferred,  as
       described below.

       Inference  rules  can be redefined. A target that matches an existing inference rule shall
       overwrite the old inference rule. An empty rule can be created with a  command  consisting
       of  simply  a semicolon (that is, the rule still exists and is found during inference rule
       search, but since it is empty, execution has no effect).  The empty rule can also be  for-
       matted as follows:

	      rule: ;

       where zero or more <blank>s separate the colon and semicolon.

       The  make utility uses the suffixes of targets and their prerequisites to infer how a tar-
       get can be made up-to-date. A list of inference rules defines the commands to be executed.
       By  default,  make  contains  a	built-in set of inference rules.  Additional rules can be
       specified in the makefile.

       The special target .SUFFIXES contains as its prerequisites a list of suffixes  that  shall
       be used by the inference rules.	The order in which the suffixes are specified defines the
       order in which the inference rules for the  suffixes  are  used.  New  suffixes	shall  be
       appended  to  the current list by specifying a .SUFFIXES special target in the makefile. A
       .SUFFIXES target with no prerequisites shall clear the list of suffixes.  An  empty  .SUF-
       FIXES  target followed by a new .SUFFIXES list is required to change the order of the suf-
       fixes.

       Normally, the user would provide an inference rule for each suffix.  The inference rule to
       update  a target with a suffix .s1 from a prerequisite with a suffix .s2 is specified as a
       target .s2.s1. The internal macros provide the means to specify	general  inference  rules
       (see Internal Macros ).

       When no target rule is found to update a target, the inference rules shall be checked. The
       suffix of the target ( .s1) to be built is compared to the list of suffixes  specified  by
       the  .SUFFIXES  special	targets.  If  the .s1 suffix is found in .SUFFIXES, the inference
       rules shall be searched in the order defined for the first .s2.s1 rule whose  prerequisite
       file  ( $*.s2) exists. If the target is out-of-date with respect to this prerequisite, the
       commands for that inference rule shall be executed.

       If the target to be built does not contain a suffix and there is no rule for  the  target,
       the  single  suffix  inference  rules  shall be checked. The single-suffix inference rules
       define how to build a target if a file is found with a name that matches the  target  name
       with  one of the single suffixes appended. A rule with one suffix .s2 is the definition of
       how to build target from target.s2. The other suffix ( .s1) is treated as null.

       A tilde ( '~' ) in the above rules refers to an SCCS file in the current directory.  Thus,
       the  rule  .c~.o would transform an SCCS C-language source file into an object file ( .o).
       Because the s. of the SCCS files is a prefix, it is incompatible with make's suffix  point
       of  view.  Hence, the '~' is a way of changing any file reference into an SCCS file refer-
       ence.

   Libraries
       If a target or prerequisite contains parentheses, it shall be treated as a  member  of  an
       archive	library. For the lib( member .o) expression lib refers to the name of the archive
       library and member .o to the member name. The application shall ensure that the member  is
       an  object file with the .o suffix. The modification time of the expression is the modifi-
       cation time for the member as kept in the archive library; see ar . The	.a  suffix  shall
       refer  to  an  archive  library.  The  .s2.a  rule shall be used to update a member in the
       library from a file with a suffix .s2.

   Internal Macros
       The make utility shall maintain five internal macros that can be used in target and infer-
       ence  rules. In order to clearly define the meaning of these macros, some clarification of
       the terms target rule, inference rule, target, and prerequisite is necessary.

       Target rules are specified by the user in a makefile for a  particular  target.	Inference
       rules  are  user-specified  or make-specified rules for a particular class of target name.
       Explicit prerequisites are those prerequisites specified in a makefile  on  target  lines.
       Implicit prerequisites are those prerequisites that are generated when inference rules are
       used.  Inference rules are applied to implicit prerequisites or to explicit  prerequisites
       that  do  not have target rules defined for them in the makefile. Target rules are applied
       to targets specified in the makefile.

       Before any target in the makefile is updated, each of its prerequisites (both explicit and
       implicit) shall be updated. This shall be accomplished by recursively processing each pre-
       requisite.  Upon recursion, each prerequisite shall become a target itself.  Its prerequi-
       sites in turn shall be processed recursively until a target is found that has no prerequi-
       sites, at which point the recursion stops. The recursion shall then back up, updating each
       target as it goes.

       In the definitions that follow, the word target refers to one of:

	* A target specified in the makefile

	* An  explicit	prerequisite  specified in the makefile that becomes the target when make
	  processes it during recursion

	* An implicit prerequisite that becomes a target when make processes it during recursion

       In the definitions that follow, the word prerequisite refers to one of the following:

	* An explicit prerequisite specified in the makefile for a particular target

	* An implicit prerequisite generated as a result of  locating  an  appropriate	inference
	  rule and corresponding file that matches the suffix of the target

       The five internal macros are:

       $@     The $@ shall evaluate to the full target name of the current target, or the archive
	      filename part of a library archive target.  It shall be evaluated for  both  target
	      and inference rules.

       For  example,  in  the  .c.a  inference	rule, $@ represents the out-of-date .a file to be
       built. Similarly, in a makefile target rule to build lib.a from file.c, $@ represents  the
       out-of-date lib.a.

       $%     The  $% macro shall be evaluated only when the current target is an archive library
	      member of the form libname( member .o). In these cases, $@ shall evaluate  to  lib-
	      name  and  $% shall evaluate to member .o. The $% macro shall be evaluated for both
	      target and inference rules.

       For example, in a makefile target rule to build lib.a( file.o), $% represents  file.o,  as
       opposed to $@, which represents lib.a.

       $?     The  $?  macro  shall evaluate to the list of prerequisites that are newer than the
	      current target. It shall be evaluated for both target and inference rules.

       For example, in a makefile target rule to build prog from file1.o, file2.o,  and  file3.o,
       and where prog is not out-of-date with respect to file1.o, but is out-of-date with respect
       to file2.o and file3.o, $? represents file2.o and file3.o.

       $<     In an inference rule, the $< macro shall evaluate to the filename  whose	existence
	      allowed  the  inference rule to be chosen for the target. In the .DEFAULT rule, the
	      $< macro shall evaluate to the current target name. The meaning  of  the	$<  macro
	      shall be otherwise unspecified.

       For example, in the .c.a inference rule, $< represents the prerequisite .c file.

       $*     The  $* macro shall evaluate to the current target name with its suffix deleted. It
	      shall be evaluated at least for inference rules.

       For example, in the .c.a inference rule, $*.o represents the out-of-date .o file that cor-
       responds to the prerequisite .c file.

       Each  of  the  internal	macros	has  an alternative form. When an uppercase 'D' or 'F' is
       appended to any of the macros, the meaning shall be changed to the directory part for  'D'
       and  filename  part  for 'F' . The directory part is the path prefix of the file without a
       trailing slash; for the current directory, the directory part is '.' . When the	$?  macro
       contains  more  than  one  prerequisite filename, the $(?D) and $(?F) (or ${?D} and ${?F})
       macros expand to a list of directory name parts and filename parts respectively.

       For the target lib( member .o) and the s2.a rule, the internal macros shall be defined as:

       $<     member .s2

       $*     member

       $@     lib

       $?     member .s2

       $%     member .o

   Default Rules
       The default rules for make shall achieve results that are the same  as  if  the	following
       were used. Implementations that do not support the C-Language Development Utilities option
       may omit CC, CFLAGS, YACC, YFLAGS, LEX, LFLAGS, LDFLAGS, and the .c, .y, and .l	inference
       rules.  Implementations that do not support FORTRAN may omit FC, FFLAGS, and the .f infer-
       ence rules. Implementations may provide additional macros and rules.

	      SPECIAL TARGETS

	      .SCCS_GET: sccs $(SCCSFLAGS) get $(SCCSGETFLAGS) $@

	      .SUFFIXES: .o .c .y .l .a .sh .f .c~ .y~ .l~ .sh~ .f~

	      MACROS

	      MAKE=make
	      AR=ar
	      ARFLAGS=-rv
	      YACC=yacc
	      YFLAGS=
	      LEX=lex
	      LFLAGS=
	      LDFLAGS=
	      CC=c99
	      CFLAGS=-O
	      FC=fort77
	      FFLAGS=-O 1

	      GET=get
	      GFLAGS=
	      SCCSFLAGS=
	      SCCSGETFLAGS=-s

	      SINGLE SUFFIX RULES

	      .c:
		  $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $<

	      .f:
		  $(FC) $(FFLAGS) $(LDFLAGS) -o $@ $<

	      .sh:
		  cp $< $@
		  chmod a+x $@

	      .c~:
		  $(GET) $(GFLAGS) -p $< > $*.c
		  $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $*.c

	      .f~:
		  $(GET) $(GFLAGS) -p $< > $*.f
		  $(FC) $(FFLAGS) $(LDFLAGS) -o $@ $*.f

	      .sh~:
		  $(GET) $(GFLAGS) -p $< > $*.sh
		  cp $*.sh $@
		  chmod a+x $@

	      DOUBLE SUFFIX RULES

	      .c.o:
		  $(CC) $(CFLAGS) -c $<

	      .f.o:
		  $(FC) $(FFLAGS) -c $<

	      .y.o:
		  $(YACC) $(YFLAGS) $<
		  $(CC) $(CFLAGS) -c y.tab.c
		  rm -f y.tab.c
		  mv y.tab.o $@

	      .l.o:
		  $(LEX) $(LFLAGS) $<
		  $(CC) $(CFLAGS) -c lex.yy.c
		  rm -f lex.yy.c
		  mv lex.yy.o $@

	      .y.c:
		  $(YACC) $(YFLAGS) $<
		  mv y.tab.c $@

	      .l.c:
		  $(LEX) $(LFLAGS) $<
		  mv lex.yy.c $@

	      .c~.o:
		  $(GET) $(GFLAGS) -p $< > $*.c
		  $(CC) $(CFLAGS) -c $*.c

	      .f~.o:
		  $(GET) $(GFLAGS) -p $< > $*.f
		  $(FC) $(FFLAGS) -c $*.f

	      .y~.o:
		  $(GET) $(GFLAGS) -p $< > $*.y
		  $(YACC) $(YFLAGS) $*.y
		  $(CC) $(CFLAGS) -c y.tab.c
		  rm -f y.tab.c
		  mv y.tab.o $@

	      .l~.o:
		  $(GET) $(GFLAGS) -p $< > $*.l
		  $(LEX) $(LFLAGS) $*.l
		  $(CC) $(CFLAGS) -c lex.yy.c
		  rm -f lex.yy.c
		  mv lex.yy.o $@

	      .y~.c:
		  $(GET) $(GFLAGS) -p $< > $*.y
		  $(YACC) $(YFLAGS) $*.y
		  mv y.tab.c $@

	      .l~.c:
		  $(GET) $(GFLAGS) -p $< > $*.l
		  $(LEX) $(LFLAGS) $*.l
		  mv lex.yy.c $@

	      .c.a:
		  $(CC) -c $(CFLAGS) $<
		  $(AR) $(ARFLAGS) $@ $*.o
		  rm -f $*.o

	      .f.a:
		  $(FC) -c $(FFLAGS) $<
		  $(AR) $(ARFLAGS) $@ $*.o
		  rm -f $*.o

EXIT STATUS
       When the -q option is specified, the make utility shall exit with  one  of  the	following
       values:

	0     Successful completion.

	1     The target was not up-to-date.

       >1     An error occurred.

       When the -q option is not specified, the make utility shall exit with one of the following
       values:

	0     Successful completion.

       >0     An error occurred.

CONSEQUENCES OF ERRORS
       Default.

       The following sections are informative.

APPLICATION USAGE
       If there is a source file (such as ./source.c) and there are two SCCS files  corresponding
       to  it ( ./s.source.c and ./SCCS/s.source.c), on XSI-conformant systems make uses the SCCS
       file in the current directory. However, users are advised to use the underlying SCCS util-
       ities  ( admin, delta, get, and so on) or the sccs utility for all source files in a given
       directory. If both forms are used for a given source  file,  future  developers	are  very
       likely to be confused.

       It  is  incumbent upon portable makefiles to specify the .POSIX special target in order to
       guarantee that they are not affected by local extensions.

       The -k and -S options are both present so that the relationship between the command  line,
       the  MAKEFLAGS  variable,  and  the makefile can be controlled precisely. If the k flag is
       passed in MAKEFLAGS and a command is of the form:

	      $(MAKE) -S foo

       then the default behavior is restored for the child make.

       When the -n option is specified, it is always added to MAKEFLAGS . This allows a recursive
       make -n target to be used to see all of the action that would be taken to update target.

       Because	of  widespread historical practice, interpreting a '#' number sign inside a vari-
       able as the start of a comment has the unfortunate side effect of making it impossible  to
       place a number sign in a variable, thus forbidding something like:

	      CFLAGS = "-D COMMENT_CHAR='#'"

       Many historical make utilities stop chaining together inference rules when an intermediate
       target is nonexistent. For example, it might be possible for a make to determine that both
       .y.c  and .c.o could be used to convert a .y to a .o. Instead, in this case, make requires
       the use of a .y.o rule.

       The best way to provide portable makefiles is to include all of the rules  needed  in  the
       makefile itself. The rules provided use only features provided by other parts of this vol-
       ume of IEEE Std 1003.1-2001.  The default rules include rules  for  optional  commands  in
       this  volume  of IEEE Std 1003.1-2001. Only rules pertaining to commands that are provided
       are needed in an implementation's default set.

       Macros used within other macros are evaluated when the new macro is used rather than  when
       the new macro is defined.  Therefore:

	      MACRO = value1NEW   = $(MACRO)
	      MACRO = value2

	      target:
		  echo $(NEW)

       would  produce value2 and not value1 since NEW was not expanded until it was needed in the
       echo command line.

       Some historical applications have been known to intermix target_name and macro=name  oper-
       ands on the command line, expecting that all of the macros are processed before any of the
       targets are dealt with. Conforming applications do not do this, although  some  backwards-
       compatibility support may be included in some implementations.

       The  following  characters in filenames may give trouble: '=' , ':' , '`' , '" , and '@' .
       For inference rules, the description of $< and $? seem similar. However, an example  shows
       the minor difference.  In a makefile containing:

	      foo.o: foo.h

       if  foo.h  is  newer  than foo.o, yet foo.c is older than foo.o, the built-in rule to make
       foo.o from foo.c is used, with $< equal to foo.c and $? equal to foo.h. If foo.c  is  also
       newer than foo.o, $< is equal to foo.c and $? is equal to foo.h foo.c.

EXAMPLES
	1. The following command:

	   make

       makes the first target found in the makefile.

	2. The following command:

	   make junk

       makes the target junk.

	3. The	following makefile says that pgm depends on two files, a.o and b.o, and that they
	   in turn depend on their corresponding source files ( a.c and b.c), and a  common  file
	   incl.h:

	   pgm: a.o b.o
	       c99 a.o b.o -o pgm
	   a.o: incl.h a.c
	       c99 -c a.c
	   b.o: incl.h b.c
	       c99 -c b.c

	4. An example for making optimized .o files from .c files is:

	   .c.o:
	       c99 -c -O $*.c

       or:

	      .c.o:
		  c99 -c -O $<

	5. The	most  common  use  of the archive interface follows. Here, it is assumed that the
	   source files are all C-language source:

	   lib: lib(file1.o) lib(file2.o) lib(file3.o)
	       @echo lib is now up-to-date

       The .c.a rule is used to make file1.o, file2.o, and file3.o and insert them into lib.

       The treatment of escaped <newline>s throughout the makefile is  historical  practice.  For
       example, the inference rule:

	      .c.o\
	      :

       works, and the macro:

	      f=  bar baz\
		  biz
	      a:
		  echo ==$f==

       echoes "==bar baz biz==" .

       If $? were:

	      /usr/include/stdio.h /usr/include/unistd.h foo.h

       then $(?D) would be:

	      /usr/include /usr/include .

       and $(?F) would be:

	      stdio.h unistd.h foo.h

	6. The contents of the built-in rules can be viewed by running:

	   make -p -f /dev/null 2>/dev/null

RATIONALE
       The  make  utility described in this volume of IEEE Std 1003.1-2001 is intended to provide
       the means for changing portable source code  into  executables  that  can  be  run  on  an
       IEEE Std 1003.1-2001-conforming	system.  It  reflects the most common features present in
       System V and BSD makes.

       Historically, the make utility has been	an  especially	fertile  ground  for  vendor  and
       research organization-specific syntax modifications and extensions. Examples include:

	* Syntax  supporting  parallel	execution  (such as from various multi-processor vendors,
	  GNU, and others)

	* Additional "operators" separating targets and their prerequisites (System V,	BSD,  and
	  others)

	* Specifying  that  command lines containing the strings "${MAKE}" and "$(MAKE)" are exe-
	  cuted when the -n option is specified (GNU and System V)

	* Modifications of the meaning of internal macros when	referencing  libraries	(BSD  and
	  others)

	* Using  a  single  instance of the shell for all of the command lines of the target (BSD
	  and others)

	* Allowing spaces as well as tabs to delimit command lines (BSD)

	* Adding C preprocessor-style "include" and "ifdef" constructs (System V, GNU,	BSD,  and
	  others)

	* Remote execution of command lines (Sprite and others)

	* Specifying additional special targets (BSD, System V, and most others)

       Additionally, many vendors and research organizations have rethought the basic concepts of
       make, creating vastly extended, as well as completely new, syntaxes. Each  of  these  ver-
       sions of make fulfills the needs of a different community of users; it is unreasonable for
       this volume of IEEE Std 1003.1-2001 to require behavior that would  be  incompatible  (and
       probably inferior) to historical practice for such a community.

       In  similar  circumstances, when the industry has enough sufficiently incompatible formats
       as to make them irreconcilable, this volume of IEEE Std 1003.1-2001 has	followed  one  or
       both  of  two courses of action. Commands have been renamed ( cksum, echo, and pax) and/or
       command line options have been provided to select the desired behavior  (  grep,  od,  and
       pax).

       Because	the  syntax specified for the make utility is, by and large, a subset of the syn-
       taxes accepted by almost all versions of make, it was decided that it  would  be  counter-
       productive  to change the name. And since the makefile itself is a basic unit of portabil-
       ity, it would not be completely effective to reserve a new option letter, such as make -P,
       to  achieve  the  portable behavior. Therefore, the special target .POSIX was added to the
       makefile, allowing users to specify "standard" behavior. This special target does not pre-
       clude  extensions  in the make utility, nor does it preclude such extensions being used by
       the makefile specifying the target; it does, however, preclude any extensions  from  being
       applied	that could alter the behavior of previously valid syntax; such extensions must be
       controlled via command line options or new special targets. It is incumbent upon  portable
       makefiles  to  specify  the  .POSIX special target in order to guarantee that they are not
       affected by local extensions.

       The portable version of make described in this reference page is not intended  to  be  the
       state-of-the-art  software  generation tool and, as such, some newer and more leading-edge
       features have not been included. An attempt has been made to describe the  portable  make-
       file in a manner that does not preclude such extensions as long as they do not disturb the
       portable behavior described here.

       When the -n option is specified, it is always added to MAKEFLAGS . This allows a recursive
       make -n target to be used to see all of the action that would be taken to update target.

       The  definition	of  MAKEFLAGS  allows both the System V letter string and the BSD command
       line formats. The two formats are sufficiently different to allow implementations to  sup-
       port both without ambiguity.

       Early  proposals  stated that an "unquoted" number sign was treated as the start of a com-
       ment. The make utility does not pay any attention to quotes. A number sign starts  a  com-
       ment regardless of its surroundings.

       The  text  about "other implementation-defined pathnames may also be tried" in addition to
       ./makefile and ./Makefile is to allow such extensions as SCCS/s.Makefile and other  varia-
       tions. It was made an implementation-defined requirement (as opposed to unspecified behav-
       ior) to highlight surprising implementations that might select something  unexpected  like
       /etc/Makefile.  XSI-conformant  systems	also try ./s.makefile, SCCS/s.makefile, ./s.Make-
       file, and SCCS/s.Makefile.

       Early proposals contained the macro NPROC as a means of specifying that make should use	n
       processes  to  do  the  work required. While this feature is a valuable extension for many
       systems, it is not common usage and could require other non-trivial extensions to makefile
       syntax.	This  extension is not required by this volume of IEEE Std 1003.1-2001, but could
       be provided as a compatible extension. The macro PARALLEL is used by some historical  sys-
       tems  with  essentially the same meaning (but without using a name that is a common system
       limit value).  It is suggested that implementors  recognize  the  existing  use	of  NPROC
       and/or PARALLEL as extensions to make.

       The  default  rules  are  based	on  System  V. The default CC= value is c99 instead of cc
       because this volume of IEEE Std 1003.1-2001 does not standardize  the  utility  named  cc.
       Thus,  every  conforming application would be required to define CC= c99 to expect to run.
       There is no advantage conferred by the hope that the makefile might  hit  the  "preferred"
       compiler  because  this	cannot be guaranteed to work. Also, since the portable makescript
       can only use the c99 options, no advantage is conferred in terms of what  the  script  can
       do. It is a quality-of-implementation issue as to whether c99 is as valuable as cc.

       The  -d	option	to  make  is frequently used to produce debugging information, but is too
       implementation-defined to add to this volume of IEEE Std 1003.1-2001.

       The -p option is not passed in MAKEFLAGS on most historical implementations and to  change
       this would cause many implementations to break without sufficiently increased portability.

       Commands  that  begin  with  a  plus  sign  (  '+' ) are executed even if the -n option is
       present. Based on the GNU version of make, the behavior of -n when the plus-sign prefix is
       encountered has been extended to apply to -q and -t as well. However, the System V conven-
       tion of forcing command execution with -n when the  command  line  of  a  target  contains
       either  of  the	strings  "$(MAKE)"  or "${MAKE}" has not been adopted. This functionality
       appeared in early proposals, but the danger of this approach was pointed out with the fol-
       lowing example of a portion of a makefile:

	      subdir:
		  cd subdir; rm all_the_files; $(MAKE)

       The  loss of the System V behavior in this case is well-balanced by the safety afforded to
       other makefiles that were not aware of this situation. In  any  event,  the  command  line
       plus-sign prefix can provide the desired functionality.

       The  double colon in the target rule format is supported in BSD systems to allow more than
       one target line containing the same target name to have commands associated with it. Since
       this  is  not functionality described in the SVID or XPG3 it has been allowed as an exten-
       sion, but not mandated.

       The default rules are provided with text specifying that the built-in rules shall  be  the
       same as if the listed set were used.  The intent is that implementations should be able to
       use the rules without change, but will be allowed to alter them in ways that do not affect
       the primary behavior.

       The  best  way  to provide portable makefiles is to include all of the rules needed in the
       makefile itself. The rules provided use only features provided by other portions  of  this
       volume  of IEEE Std 1003.1-2001.  The default rules include rules for optional commands in
       this volume of IEEE Std 1003.1-2001. Only rules pertaining to commands that  are  provided
       are needed in the default set of an implementation.

       One  point  of  discussion  was whether to drop the default rules list from this volume of
       IEEE Std 1003.1-2001. They provide convenience, but do not enhance portability of applica-
       tions.	The  prime  benefit  is in portability of users who wish to type make command and
       have the command build from a command.c file.

       The historical MAKESHELL feature was omitted. In some implementations it is used to let	a
       user  override the shell to be used to run make commands. This was confusing; for a porta-
       ble make, the shell should be chosen by the makefile writer or specified on the make  com-
       mand line and not by a user running make.

       The  make utilities in most historical implementations process the prerequisites of a tar-
       get in left-to-right order, and the makefile format requires this. It supports  the  stan-
       dard idiom used in many makefiles that produce yacc programs; for example:

	      foo: y.tab.o lex.o main.o
		  $(CC) $(CFLAGS) -o $@ t.tab.o lex.o main.o

       In  this  example, if make chose any arbitrary order, the lex.o might not be made with the
       correct y.tab.h.  Although there may be better ways to express this  relationship,  it  is
       widely  used historically. Implementations that desire to update prerequisites in parallel
       should require an explicit extension to make or the makefile format to accomplish  it,  as
       described previously.

       The  algorithm for determining a new entry for target rules is partially unspecified. Some
       historical makes allow blank, empty, or comment lines within the  collection  of  commands
       marked  by leading <tab>s. A conforming makefile must ensure that each command starts with
       a <tab>, but implementations are free to ignore blank, empty, and  comment  lines  without
       triggering the start of a new entry.

       The  ASYNCHRONOUS  EVENTS  section includes having SIGTERM and SIGHUP, along with the more
       traditional SIGINT and SIGQUIT, remove the current target unless directed not  to  do  so.
       SIGTERM	and  SIGHUP were added to parallel other utilities that have historically cleaned
       up their work as a result of these signals. When  make  receives  any  signal  other  than
       SIGQUIT,  it  is  required to resend itself the signal it received so that it exits with a
       status that reflects the signal.  The  results  from  SIGQUIT  are  partially  unspecified
       because,  on  systems  that  create core files upon receipt of SIGQUIT, the core from make
       would conflict with a core file from  the  command  that  was  running  when  the  SIGQUIT
       arrived. The main concern was to prevent damaged files from appearing up-to-date when make
       is rerun.

       The .PRECIOUS special target was extended to affect all targets globally (by specifying no
       prerequisites).	The  .IGNORE and .SILENT special targets were extended to allow prerequi-
       sites; it was judged to be more useful in some cases to be able	to  turn  off  errors  or
       echoing	for  a	list of targets than for the entire makefile. These extensions to make in
       System V were made to match historical practice from the BSD make.

       Macros are not exported to the environment of commands to be run.  This was never the case
       in any historical make and would have serious consequences. The environment is the same as
       the environment to make except that MAKEFLAGS and macros defined on the make command  line
       are added.

       Some  implementations do not use system() for all command lines, as required by the porta-
       ble makefile format; as	a  performance	enhancement,  they  select  lines  without  shell
       metacharacters for direct execution by execve().  There is no requirement that system() be
       used specifically, but merely that the same results be achieved. The metacharacters  typi-
       cally used to bypass the direct execve() execution have been any of:

	      =  |  ^  (  )  ;	&  <  >  *  ?  [  ]  :	$  `  '  "  \  \n

       The default in some advanced versions of make is to group all the command lines for a tar-
       get and execute them using a single shell invocation; the System V method is to pass  each
       line  individually to a separate shell. The single-shell method has the advantages in per-
       formance and the lack of a requirement for many continued lines.  However,  converting  to
       this  newer  method has caused portability problems with many historical makefiles, so the
       behavior with the POSIX makefile is specified to be the same as that of System  V.  It  is
       suggested  that	the  special  target  .ONESHELL be used as an implementation extension to
       achieve the single-shell grouping for a target or group of targets.

       Novice users of make have had difficulty with the historical need to start commands with a
       <tab>.  Since  it is often difficult to discern differences between <tab>s and <space>s on
       terminals or printed listings, confusing bugs can arise. In early  proposals,  an  attempt
       was made to correct this problem by allowing leading <blank>s instead of <tab>s.  However,
       implementors reported many makefiles that failed in subtle ways following this change, and
       it is difficult to implement a make that unambiguously can differentiate between macro and
       command lines. There is extensive historical practice of allowing  leading  spaces  before
       macro definitions. Forcing macro lines into column 1 would be a significant backwards-com-
       patibility problem for some makefiles. Therefore, historical practice was restored.

       The System V INCLUDE feature was considered, but not included. This  would  treat  a  line
       that  began  in the first column and contained INCLUDE <filename> as an indication to read
       <filename> at that point in the makefile. This is difficult to use in a portable way,  and
       it  raises  concerns  about nesting levels and diagnostics. System V, BSD, GNU, and others
       have used different methods for including files.

       The System V dynamic dependency feature was not included. It would support:

	      cat: $$@.c

       that would expand to;

	      cat: cat.c

       This feature exists only in the new version of System V make and, while useful, is not  in
       wide  usage. This means that macros are expanded twice for prerequisites: once at makefile
       parse time and once at target update time.

       Consideration was given to adding metarules to the POSIX make.  This would  make  %.o: %.c
       the  same  as  .c.o:.  This  is quite useful and available from some vendors, but it would
       cause too many changes to this make to support. It would have introduced rule chaining and
       new  substitution  rules. However, the rules for target names have been set to reserve the
       '%' and '' characters. These are traditionally used to implement metarules and quoting  of
       target  names,  respectively. Implementors are strongly encouraged to use these characters
       only for these purposes.

       A request was made to extend the suffix delimiter character from a period to  any  charac-
       ter.  The metarules feature in newer makes solves this problem in a more general way. This
       volume of IEEE Std 1003.1-2001 is staying with the more	conservative  historical  defini-
       tion.

       The  standard  output  format for the -p option is not described because it is primarily a
       debugging option and because the format is not generally useful to programs. In historical
       implementations	the output is not suitable for use in generating makefiles. The -p format
       has been variable across historical implementations. Therefore, the definition of  -p  was
       only  to  provide a consistently named option for obtaining make script debugging informa-
       tion.

       Some historical implementations have not cleared the suffix list with -r.

       Implementations should be aware that some historical  applications  have  intermixed  tar-
       get_name  and  macro= value operands on the command line, expecting that all of the macros
       are processed before any of the targets are dealt with.	Conforming applications do not do
       this, but some backwards-compatibility support may be warranted.

       Empty inference rules are specified with a semicolon command rather than omitting all com-
       mands, as described in an early proposal. The latter case has no traditional  meaning  and
       is reserved for implementation extensions, such as in GNU make.

FUTURE DIRECTIONS
       None.

SEE ALSO
       Shell  Command  Language , ar , c99 , get , lex , sccs , sh , yacc , the System Interfaces
       volume of IEEE Std 1003.1-2001, exec, system()

COPYRIGHT
       Portions of this text are reprinted and	reproduced  in	electronic  form  from	IEEE  Std
       1003.1,	2003  Edition,	Standard  for Information Technology -- Portable Operating System
       Interface (POSIX), The Open Group Base Specifications Issue 6, Copyright (C) 2001-2003  by
       the  Institute  of  Electrical  and  Electronics Engineers, Inc and The Open Group. In the
       event of any discrepancy between this version and the original IEEE  and  The  Open  Group
       Standard, the original IEEE and The Open Group Standard is the referee document. The orig-
       inal Standard can be obtained online at http://www.opengroup.org/unix/online.html .

IEEE/The Open Group			       2003					  MAKE(P)


All times are GMT -4. The time now is 05:57 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
×
UNIX.COM Login
Username:
Password:  
Show Password