make man page on DigitalUNIX

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

make(1u)							      make(1u)

       make - Maintains, updates, and regenerates groups of programs.

       make [-f makefile] [options] [names]

       Compatibility  mode  for old makefiles.	Debug mode.  Displays detailed
       information on files and times examined.	 Causes environment  variables
       to  override assignments within makefiles.  Uses the specified descrip‐
       tion file name. A file name of - denotes the standard input.  The  con‐
       tents  of  the  file specified as makefile override the built-in rules.
       Ignores error codes returned by invoked commands.  This mode is entered
       if  the	special	 target	 name .IGNORE appears in the description file.
       Stops work on the current entry, but continues on other	branches  that
       do  not depend on that entry.  No execute mode.	Displays commands, but
       does not execute them. Even lines beginning with an  at	sign  (@)  are
       displayed.   Displays  the complete set of macro definitions and target
       descriptions.  Question mode.  Returns a zero or	 nonzero  status  code
       depending on whether the target file is or is not up to date.  Does not
       use the built-in rules.	Silent mode.  Suppresses the display  of  com‐
       mand  lines  before executing. This mode is also entered if the special
       target name .SILENT appears in the description file.  Abandons work  on
       the  current entry if it fails; the opposite of the -k option.  If both
       options are specified, the last one specified on the  command  line  is
       used.  Touches target files (causing them to be up to date) rather than
       issuing the usual commands.

       This make command is one of several versions available.	 See  the  SEE
       ALSO  section for references to information about other versions of the
       command.	 By default, the make(1) command is invoked if	you  type  the
       command name with no path.  To access the make(1u) version described in
       this reference page, use the following command path:


       The make program is designed to simplify the maintenance of other  pro‐
       grams.  This  is	 the  SYSTEM  V	 version of the make command with some
       Berkeley compatibility added.

       The make program executes commands in makefile to update	 one  or  more
       target  names.	The  name  argument  is typically a program.  If no -f
       option is present, makefile, Makefile, s.makefile, and  s.Makefile  are
       tried  in order. If makefile is -, the standard input is taken. You can
       specify more than one -f makefile argument.

       The make program updates a target only if its dependents are newer than
       the  target.   All prerequisite files of a target are added recursively
       to the list of targets.	Missing files are deemed to be out of date.

       The makefile argument contains  a  sequence  of	entries	 that  specify
       dependencies.   The  first  line of an entry is a blank-separated, non-
       null list of targets, then a colon (:), then a (possibly null) list  of
       prerequisite  files or dependencies. Text following a semicolon (;) and
       all following lines that begin with a tab are shell commands to be exe‐
       cuted  to  update the target. The first line that does not begin with a
       tab or number sign (#) begins a new  dependency	or  macro  definition.
       Shell  commands	can  be continued across lines with the backslash fol‐
       lowed by a new-line (RET) sequence. Everything printed by make  (except
       the initial tab) is passed directly to the shell.  For example: echo a\

       These entries produce the following:


       This output is exactly the same as what would have been produced by the

       The Number sign (#) and new-line surround comments.

       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
	  cc a.o b.o -o pgm a.o: incl.h a.c
	  cc -c a.c b.o: incl.h b.c
	  cc -c b.c

       Command	lines  are  executed one at a time, each by its own shell. The
       first one or two characters in a command can be the  following:	-,  @,
       -@, or @-. If @ is present, printing of the command is suppressed. If -
       is present, make ignores an error. A line is printed when  it  is  exe‐
       cuted  unless the -s option is present, or the entry is in makefile, or
       unless the initial character sequence contains  a  @.   The  -n	option
       specifies printing without execution.  However, if the command line has
       the string $(MAKE) in it, the line is always executed.  (See  the  dis‐
       cussion	of the MAKEFLAGS macro under the Environment section).	The -t
       (touch) option updates the modified date of a  file  without  executing
       any commands.

       Commands	 returning  nonzero status normally terminate make.  If the -i
       option is present, or the entry appears in  makefile,  or  the  initial
       character sequence of the command contains -, the error is ignored.  If
       the -k option is present, work stops on the current entry, but  contin‐
       ues on other branches that do not depend on that entry.

       The  -b	option allows old makefiles (those written for the old version
       of make) to run without errors.	The difference between the old version
       of  make	 and this version is that this version requires all dependency
       lines to have a (possibly null or  implicit)  command  associated  with
       them.   The  previous version of make assumed, if no command was speci‐
       fied explicitly, that the command was null.

       Interrupt and quit cause the target to be deleted unless the target  is
       a dependent of the special name

       The environment is always read by make. All variables are assumed to be
       macro definitions and processed as such. The -e option causes the envi‐
       ronment to override the macro assignments in a makefile.

       The  make  command  operates in three compatibility modes.  The type of
       mode is determined by the value of the  PROG_ENV	 environment  variable
       and  by	the  way that make is executed.	 The PROG_ENV variable has two
       valid values: BSD POSIX

       In BSD mode, make executes with	Berkeley  compatibility.   This	 means
       that  /bin/sh  is  always used as the command interpreter regardless of
       the value of SHELL, and the commands are echoed to standard out without
       a prefixed <tab>.

       In  POSIX  mode,	 make executes with POSIX compatibility, such that the
       SHELL environment variable is always ignored, SHELL is always  overrid‐
       den  by	MAKESHELL,  the	 shell is always used to execute commands, and
       commands are echoed to standard out with a prefixed <tab>.

       The MAKEFLAGS environment variable is processed by make	as  containing
       any  legal input option (except -f, -p, and -d) defined for the command
       line.  Further, upon invocation, make invents the variable if it is not
       in  the environment, puts the current options into it, and passes it on
       to invocations of commands. Thus, MAKEFLAGS always contains the current
       input  options.	This  proves very useful for super-makes.  In fact, as
       noted above, when the -n option is used, the command  $(MAKE)  is  exe‐
       cuted  anyway.  Hence, one can perform a make -n recursively on a whole
       software system to see what would have been executed.  This is  because
       the  -n	is  put	 in  MAKEFLAGS	and  passed  to further invocations of
       $(MAKE). This is one way of debugging all of the makefiles for a	 soft‐
       ware project without actually doing anything.

       Macros  can be defined in four different ways.  Some macros are defined
       by default by make internally.  All environment variables  are  assumed
       to  be  macro  definitions and macros can be defined in the makefile as
       well as on the make command line.  By  default,	the  internal  default
       macros  are  overridden by environment variables, macros defined in the
       makefile override environment variables and macros defined on the  com‐
       mand  line  override  macros  defined  in  the makefile.	 The -e option
       changes this such that environment variables override macros defined in
       the makefile.

       Entries	of  the	 form  string1	=  string2  are macro definitions. The
       string2 is defined as all characters up to a comment  character	or  an
       unescaped new-line.  Subsequent appearances of $( string1 [: subst1 = [
       subst2 ]] ) are replaced by string2.  The parentheses are optional if a
       single  character  macro	 name  is  used	 and  there  is	 no substitute
       sequence. The optional : subst1i = subst2 is a substitute sequence.  If
       it is specified, all non-overlapping occurrences of subst1 in the named
       macro are replaced by subst2.  The occurrence of subst1 must be a  suf‐
       fix  at the end of the word string1.  Strings (for the purposes of this
       type of substitution) are delimited by blanks, tabs,  new-line  charac‐
       ters,  and beginnings of lines. An example of the use of the substitute
       sequence is shown in the Libraries section.

       The MACHINE macro is defined by make to allow for  machine  independent
       makefiles.   The	 default  string  for  MACHINE	is  “vax”,  “mips”, or
       “alpha”, according to which machine the application is running on.  You
       can  redefine MACHINE to one of the other strings for cross development

   Internal Macros
       There are five internally maintained macros which are useful for	 writ‐
       ing  rules for building targets.	 The macro $* stands for the file name
       part of the current dependent with the suffix deleted.  It is evaluated
       only for inference rules.  The $@ macro stands for the full target name
       of the current target. It is evaluated only for explicitly named depen‐
       dencies.	  The  $<  macro  is only evaluated for inference rules or the
       .DEFAULT rule. It is the module which is out-of-date  with  respect  to
       the  target  (that  is, the manufactured dependent file name). Thus, in
       the rule, the $< macro would evaluate to the file. Here are  two	 exam‐
       ples for making optimized files from files:

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

	      .c.o: cc -c -O $< The $?	macro is evaluated when explicit rules
	      from the makefile are evaluated.	It is the  list	 of  prerequi‐
	      sites  that  are	out of date with respect to the target; essen‐
	      tially, those modules which must be rebuilt.  The	 $%  macro  is
	      only  evaluated  when the target is an archive library member of
	      the form lib(file.o).  In this case, $@ evaluates to lib and  $%
	      evaluates to the library member, file.o.

       Four  of the five macros can have alternative forms. When an upper case
       D or F is appended to any of the four macros, the meaning is changed to
       directory  part	for  D and file part for F.  Thus, $(@D) refers to the
       directory part of the string $@.	 If there is  no  directory  part,  is
       generated.   The	 only macro excluded from this alternative form is $?.
       The reasons for this are debatable.

   Special Names
       If a file must be made but there are no explicit commands  or  relevant
       built-in rules, the commands associated with the name .DEFAULT are used
       if it exists.  Dependents of this target are not removed when  quit  or
       interrupt is hit.  Same effect as the -s option.	 Same effect as the -i
       option.	Dependencies of the .SUFFIXES special target are added to  the
       table of known suffixes.

       Certain	names (for instance, those ending with have prerequisites such
       as can be inferred. If no update commands for such  a  file  appear  in
       makefile, and if an inferable prerequisite exists, that prerequisite is
       compiled to make the target.  In this case, make	 has  inference	 rules
       that  allow  building  files from other files by examining the suffixes
       and determining an appropriate  inference  rule	to  use.  The  current
       default inference rules are:

       .c  .c~ .sh .sh~ .c.o .c~.o .c~.c .s.o .s~.o .y.o .y~.o .l.o .l~.o .y.c
       .y~.c .l.c .c.a .c~.a .s~.a .h~.h

       The internal rules for make are contained in the	 source	 file  rules.c
       for  the	 make  program.	 These rules can be locally modified. To print
       out the rules compiled into make in a form suitable for	recompilation,
       the  following  command	is  used  from /bin/sh: make -fp - 2>/dev/null

       The only	 peculiarity  in  this	output	is  the	 (null)	 string	 which
       printf(3) prints when handed a null string.

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

       A rule with only one suffix (that is, definition of how to build x from
       x.c.  In effect, the other suffix is null.  This is useful for building
       targets	from only one source file (for example, shell procedures, sim‐
       ple C programs).

       Additional suffixes are given as the  dependency	 list  for  .SUFFIXES.
       Order is significant; the first possible name for which both a file and
       a rule exist is inferred as a prerequisite. The default list is:

       .SUFFIXES: .o .c .y .l .s

       Here again, the above command for printing the internal	rules  display
       the  list of suffixes implemented on the current machine. Multiple suf‐
       fix lists accumulate; .SUFFIXES: with no dependencies clears  the  list
       of suffixes.

   Inference Rules
       The first example can be done more briefly:

       pgm: a.o b.o
	  cc a.o b.o -o pgm a.o b.o: incl.h

       This  is	 because  make has a set of internal rules for building files.
       The user may add rules to this list by simply putting them in the make‐

       Certain	macros	are  used by the default inference rules to permit the
       inclusion of optional matter in any resulting  commands.	 For  example,
       CFLAGS,	LFLAGS,	 and  YFLAGS  are  used	 for  compiler flags to cc(1),
       lex(1), and yacc(1), respectively. Again, the previous method for exam‐
       ining the current rules is recommended.

       The inference of prerequisites can be controlled.  The rule to create a
       file with suffix from a file with suffix is specified as an entry  with
       as  the	target	and  no dependents. Shell commands associated with the
       target define the rule for making a file from a file. Any  target  that
       has  no slashes in it and starts with a dot is identified as a rule and
       not a true target.

       If a target or dependency name contains parentheses, it is  assumed  to
       be  an  archive	library,  the string within parentheses referring to a
       member within the library. Thus	lib(file.o)  and  $(LIB)(file.o)  both
       refer  to  an  archive library which contains file.o. (This assumes the
       LIB macro has been previously defined.) The  expression	$(LIB)(file1.o
       file2.o)	 is  not legal. Rules pertaining to archive libraries have the
       form XX where the XX is the suffix from which the archive member is  to
       be  made.  An  unfortunate  byproduct  of  the  current	implementation
       requires the XX to be different from the suffix of the archive  member.
       Thus,  one  cannot have lib(file.o) depend upon file.o explicitly.  The
       most common use of the archive interface follows. Here, it  is  assumed
       that the source files are all C type source:

       lib: lib(file1.o) lib(file2.o) lib(file3.o)
	  @echo lib is now up-to-date .c.a:
	  $(CC) -c $(CFLAGS1) $<
	  ar rv $@ $*.o
	  rm -f $*.o

       In fact, the rule listed above is built into make and is unnecessary in
       this example. A more interesting, but more limited example  of  an  ar‐
       chive library maintenance construction follows:

       lib: lib(file1.o) lib(file2.o) lib(file3.o)
	  $(CC) -c $(CFLAGS) $(?:.o=.c)
	  ar rv lib $?
	  rm $?
	  @echo lib is now up-to-date .c.a:;

       Here  the  substitution	mode  of the macro expansions is used.	The $?
       list is defined to be the set of object file names (inside lib) whose C
       source  files are out-of-date.  The substitution mode translates the to
       one cannot transform to of the rule,  which  would  have	 created  each
       object  file,  one by one.  This particular construct speeds up archive
       library maintenance considerably. This type of construct	 becomes  very
       cumbersome  if  the archive library contains a mix of assembly programs
       and C programs.

       Some commands return non-zero status inappropriately.  Use -i to	 over‐
       come  the difficulty.  File names with the characters =, :, or @ do not
       work.  Commands that are directly executed by the shell, notably cd(1),
       are  ineffectual	 across	 new-lines  in	make.  The syntax (lib(file1.o
       file2.o file3.o) is illegal.  You cannot build lib(file.o) from file.o.
       The macro $(a:.o=.c~) does not work.

       cc(1), cd(1), lex(1), make(1), make(1p), sh(1), yacc(1)


List of man pages available for DigitalUNIX

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