make man page on SuSE

Man page or keyword search:  
man Server   14857 pages
apropos Keyword Search (all sections)
Output format
SuSE logo
[printable version]

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

PROLOG
       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
       implementation of this interface may differ (consult the	 corresponding
       Linux  manual page for details of Linux behavior), or the interface may
       not be implemented on Linux.

NAME
       make - maintain, update, and regenerate groups  of  programs  (DEVELOP‐
       MENT)

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	corre‐
       sponding 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 prerequi‐
       sites) from which they are derived. A description file (makefile)  con‐
       tains  a	 description  of the relationships between files, and the com‐
       mands that need to be executed to update the targets to reflect changes
       in  their prerequisites.	 Each specification, or rule, shall consist of
       a target, optional prerequisites, and optional commands to be  executed
       when  a	prerequisite  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 infer‐
       ence rules that infer prerequisite relationships	 to  simplify  mainte‐
       nance 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	condi‐
       tions 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 path‐
	      name 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  cur‐
	      rent  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 descriptions. The output format is unspecified.

       -q     Return a zero exit value if the target file is up-to-date;  oth‐
	      erwise,  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 ( '+' ) prefix
	      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  prereq‐
	      uisites.

       -t     Update  the  modification	 time of each target as though a touch
	      target had been executed. 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	 asso‐
	      ciated  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
       MAKEFLAGS 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 specified, while make is processing the  makefiles,
	      the first target that make encounters that is not a special tar‐
	      get 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  con‐
       taining	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,  Internationalization	 Vari‐
	      ables  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 internationalization 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 arguments and input files).

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

       MAKEFLAGS

	      This variable shall be interpreted as a character string	repre‐
	      senting  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> separation used on a make utility command line.

	       * The characters are formatted in a manner similar to a portion
		 of  the  make	utility	 command line: options are preceded by
		 hyphens and <blank>-separated as described in the Base	 Defi‐
		 nitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility
		 Syntax Guidelines.  The macro= value macro  definition	 oper‐
		 ands  can  also  be included. The difference between the con‐
		 tents of MAKEFLAGS and the make utility command line is  that
		 the  contents	of  the variable shall not be subjected to the
		 word expansions (see Word Expansions ) associated with	 pars‐
		 ing 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  PROJECTDIR  is  treated  as a user name and that
	      user's initial working directory shall be examined for a	subdi‐
	      rectory 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 make‐
       file or on the command line. All other environment 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 sig‐
       nals.

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	 them‐
       selves 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 corre‐
       sponding 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 com‐
       ments. 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 sys‐
       tems, 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 '-' argu‐
       ment is specified, standard input shall be used.

       The term makefile is used to refer to any rules provided by  the	 user,
       whether in ./makefile 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  any‐
       where  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 condi‐
       tions listed under '@' suppresses the writing) and executing  the  com‐
       mand(s)	in  the line. A <tab> may precede the command to standard out‐
       put. Command execution shall be as if the makefile  command  line  were
       the  argument to the system() function. The environment for the command
       being executed shall contain 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 processes the command. When  a  com‐
       mand 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	 special target .IGNORE has either the current
	      target as a prerequisite or  has	no  prerequisites,  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  command
	      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  exe‐
       cuted  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 con‐
       sisting 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). Implementa‐
       tions  may  allow  other	 characters in target names as extensions. The
       interpretation 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 prerequi‐
	      sites. 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 specified by the -i option. Subse‐
	      quent 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 associated with all targets shall be ignored.

       .POSIX The  application shall ensure that this special target is speci‐
	      fied without prerequisites 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  behavior
	      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 occur‐
	      rences 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	speci‐
	      fied  without  prerequisites. 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 commands 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 con‐
       sisting 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 fol‐
       lows:

	* 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 definition.

       The  parentheses	 or braces are optional if string1 is a single charac‐
       ter. 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 occur‐
       rences 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 evalu‐
       ated when read. Macro expansions in string2 of macro  definition	 lines
       shall  be performed when the macro identified 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 command line. It is unspecified whether the inter‐
	   nal	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 Internal 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  defini‐
       tions  from  a  lower-numbered  source. Macro definitions from a single
       source (for example, the make utility command line, the MAKEFLAGS envi‐
       ronment	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  defini‐
       tions (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	 MAKE‐
       FLAGS  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 unspecified.

       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 vari‐
       ables 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 variable 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 prereq‐
       uisites for inference 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 formatted 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 target 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 suf‐
       fixes. An empty .SUFFIXES target followed by a new  .SUFFIXES  list  is
       required to change the order of the suffixes.

       Normally,  the  user  would  provide an inference rule for each suffix.
       The inference rule to update a target with a suffix .s1 from a  prereq‐
       uisite  with a suffix .s2 is specified as a target .s2.s1. The internal
       macros provide the means to specify general inference rules (see Inter‐
       nal 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  com‐
       pared  to  the list of suffixes specified by the .SUFFIXES special tar‐
       gets. 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 defini‐
       tion  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  cur‐
       rent 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 reference.

   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 mem‐
       ber name. The application shall ensure that the	member	is  an	object
       file with the .o suffix. The modification time of the expression is the
       modification 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 inference 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 prereq‐
       uisites 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 accom‐
       plished by recursively processing each prerequisite.   Upon  recursion,
       each  prerequisite  shall become a target itself.  Its prerequisites in
       turn shall be processed recursively until a target is found that has no
       prerequisites,  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 appro‐
	  priate 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 tar‐
	      get.  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 libname 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), $% rep‐
       resents 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	 file‐
	      name 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 corresponds 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	inference 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	direc‐
       tory. However, users are advised to use the underlying SCCS utilities (
       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 exten‐
       sions.

       The -k and -S options are both present so that the relationship between
       the  command line, the MAKEFLAGS variable, and the makefile can be con‐
       trolled 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 variable as the start of a comment	 has  the  unfortunate
       side  effect  of making it impossible to place a number sign in a vari‐
       able, 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 fea‐
       tures provided by other parts 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  pro‐
       vided 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 operands on the command line, expecting that all of  the
       macros are processed before any of the targets are dealt with. Conform‐
       ing 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 histori‐
       cal 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  sys‐
       tem.  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 executed when the -n option is specified (GNU and Sys‐
	  tem 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 oth‐
	  ers)

       Additionally, many vendors and research	organizations  have  rethought
       the  basic  concepts of make, creating vastly extended, as well as com‐
       pletely new, syntaxes. Each of these  versions  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 incom‐
       patible	(and probably inferior) to historical practice for such a com‐
       munity.

       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 syntaxes 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 portability, 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 preclude extensions in the  make
       utility,	 nor  does it preclude such extensions being used by the make‐
       file 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 makefile 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 differ‐
       ent to allow implementations to support both without ambiguity.

       Early proposals stated that an "unquoted" number sign  was  treated  as
       the  start of a comment. The make utility does not pay any attention to
       quotes. A number sign starts a comment 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 exten‐
       sions as SCCS/s.Makefile and other variations. It was made an implemen‐
       tation-defined  requirement  (as	 opposed  to  unspecified behavior) to
       highlight surprising implementations that might select something	 unex‐
       pected  like  /etc/Makefile.  XSI-conformant systems also try ./s.make‐
       file, SCCS/s.makefile, ./s.Makefile, 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 systems with essentially the same meaning (but with‐
       out 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 "pre‐
       ferred" 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-imple‐
       mentation issue as to whether c99 is as valuable as cc.

       The  -d option to make is frequently used to produce debugging informa‐
       tion, 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 implementa‐
       tions 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 convention of forcing  com‐
       mand  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 following 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	situa‐
       tion.  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 extension, 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 pri‐
       mary 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 fea‐
       tures   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  applications.   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 com‐
       mands. This was confusing; for a portable make,	the  shell  should  be
       chosen by the makefile writer or specified on the make command line and
       not by a user running make.

       The make utilities in most historical implementations process the  pre‐
       requisites  of a target in left-to-right order, and the makefile format
       requires this. It supports the standard 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. Implementa‐
       tions 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  conform‐
       ing  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	 glob‐
       ally  (by specifying no prerequisites). The .IGNORE and .SILENT special
       targets were extended to allow prerequisites; 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 conse‐
       quences.	 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 portable 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 com‐
       mand lines for a target and execute them using a single	shell  invoca‐
       tion;  the System V method is to pass each line individually to a sepa‐
       rate shell. The single-shell method has the advantages  in  performance
       and  the	 lack of a requirement for many continued lines. However, con‐
       verting to this newer method has caused portability problems with  many
       historical makefiles, so the behavior with the POSIX makefile is speci‐
       fied to be the same as that of System V. It is suggested that the  spe‐
       cial 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	 list‐
       ings, 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-compatibility problem for some makefiles.	There‐
       fore, 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 sup‐
       port:

	      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 avail‐
       able from some vendors, but it would cause too  many  changes  to  this
       make to support. It would have introduced rule chaining and new substi‐
       tution 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.	Imple‐
       mentors	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	character. 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 definition.

       The  standard  output format for the -p option is not described because
       it is primarily a debugging option and because the format is not gener‐
       ally  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 information.

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

       Implementations should be aware that some historical applications  have
       intermixed  target_name	and macro= value operands on the command line,
       expecting that all of the macros are processed before any of  the  tar‐
       gets  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 commands, as described in an early proposal. The lat‐
       ter 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 original Standard can be obtained online
       at http://www.opengroup.org/unix/online.html .

IEEE/The Open Group		     2003			      MAKE(1P)
[top]

List of man pages available for SuSE

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net