make man page on Ultrix

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

make(1)								       make(1)

       make, s5make - maintain, update, and regenerate groups of programs

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

       s5make [ -f makefile ] [ options ] [ names ]

       This is the SYSTEM V version of the command with some Berkeley compati‐
       bility added.

       -b	      Compatibility mode for old makefiles.

       -d	      Debug mode.  Displays detailed information on files  and
		      times examined.

       -e	      Causes  environment  variables  to  override assignments
		      within makefiles.

       -f makefile    Uses the specified description file name.	 A  file  name
		      of  -  denotes  the standard input.  The contents of the
		      file specified as makefile override the built-in rules.

       -i	      Ignores error codes returned by invoked commands.	  This
		      mode  is	entered	 if  the  special  target name .IGNORE
		      appears in the description file.

       -k	      Stops work on the current entry, but continues on	 other
		      branches that do not depend on that entry.

       -m	      Displays a memory map showing text, data, and the stack.
		      Does not operate on systems without the system call.

       -n	      No execute mode.	Displays commands, but does  not  exe‐
		      cute them.  Even lines beginning with an at sign (@) are

       -p	      Displays the complete set of macro definitions and  tar‐
		      get descriptions.

       -q	      Question	mode.	Returns	 a zero or nonzero status code
		      depending on whether the target file is or is not up  to

       -r	      Does not use the built-in rules.

       -s	      Silent  mode.   Suppresses  the display of command lines
		      before executing.	 This mode is also entered if the spe‐
		      cial  target  name  .SILENT  appears  in the description

       -S	      Abandon work on the current entry if it fails; the oppo‐
		      site  of	the -k option.	If both options are specified,
		      the last one specified on the command line is used.

       -t	      Touches target files (causing them to  be	 up  to	 date)
		      rather than issuing usual commands.

       Some  commands  return non-zero status inappropriately; use -i to over‐
       come the difficulty.  File names with the characters = : @ do not work.
       Commands	 that  are  directly executed by the shell, notably cd(1), are
       ineffectual  across  new-lines  in  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.

       If a makefile contains a dependency on a nonexistent file,  instead  of
       always  executing  the  rule,  the current time is used for comparison.
       This can cause trouble when using across an NFS environment if the time
       on the file server is later than the time on the client.

       The  command treats two dollar signs ( ) as the end of a file name in a
       dependency list, not as a single dollar sign ( ).

       The command is unable to create a rule  that  will  travel  to  a  SCCS
       directory,  extract  a file from SCCS, then copy it down to the current

       If the command is executed in the current directory,  but  no  makefile
       exists,	the  command  does not travel to the SCCS directory and search
       for a version of the makefile to from SCCS and copy down to the current
       working	directory  such	 that the original command may continue execu‐

       The command does not rebuild a source file if the source file is a  new
       link to an old file.

Special Names
	.DEFAULT      If  a  file  must be made but there are no explicit com‐
		      mands or relevant built-in rules, the  commands  associ‐
		      ated with the name .DEFAULT are used if it exists.

       .PRECIOUS      Dependents  of  this target are not removed when quit or
		      interrupt is hit.

       .SILENT	      Same effect as the -s option.

       .IGNORE	      Same effect as the -i option.

       .SUFFIXES      Dependencies of the .SUFFIXES special target  are	 added
		      to the table of known suffixes.

       The  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  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 (equence.	Everything printed by (except the ini‐
       tial 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

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

       The  following makefile says that pgm depends on two files and and that
       they in turn depend on their corresponding source files and and a  com‐
       mon file
       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, ignores an error.	A line is printed when it is  executed
       unless  the -s option is present, or the entry .SILENT: 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  discussion
       of  the	MAKEFLAGS  macro  under	 Environment).	 The -t (touch) option
       updates the modified date of a file without executing any commands.

       Commands returning nonzero status normally terminate If the  -i	option
       is  present,  or the entry .IGNORE: 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  to  run  without errors.  The difference between the old version of
       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 assumed, if no command  was	specified  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 .PRECIOUS.

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

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

       ·      BSD

       ·      POSIX

       ·      SYSTEM_FIVE

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

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

       SYSTEM_FIVE mode causes to run with SYSTEM V  compatibility  such  that
       SHELL  is  used to execute commands and commands are echoed to standard
       out with a prefixed <tab>.

       For all modes, SHELL has a default value of When is executed  with  the
       command	name  it  always  executes in SYSTEM_FIVE mode and ignores the
       environment variable PROG_ENV.

       The MAKEFLAGS environment variable is processed by  as  containing  any
       legal  input  option  (except  -f,  -p, and -d  defined for the command
       line.  Further, upon invocation, 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 -n recursively on a whole soft‐
       ware 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  software
       project without actually doing anything.

       Macros  can be defined in four different ways.  Some macros are defined
       by default by internally.  All environment variables are assumed to  be
       macro  definitions and macros can be defined in the makefile as well as
       on the command line.  By default, the internal default macros are over‐
       ridden  by  environment variables, macros defined in the makefile over‐
       ride environment variables and macros defined on the command line over‐
       ride  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.   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	 :  subst1 = subst2 is a substitute sequence.  If it is speci‐
       fied, all non-overlapping occurrences of subst1 in the named macro  are
       replaced	 by  subst2.  The occurrence of subst1 must be a suffix at the
       end of the word string1.	 Strings (for the purposes  of	this  type  of
       substitution)  are  delimited by blanks, tabs, new-line characters, and
       beginnings of lines.  An example of the use of the substitute  sequence
       is shown under Libraries.

       The  MACHINE macro is defined by to allow for machine independent make‐
       files. The legal values are: vax or mips.

   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 cur‐
		      rent dependent with the suffix deleted.  It is evaluated
		      only for inference rules.

       $@	      The $@ macro stands for the full target name of the cur‐
		      rent target.  It is evaluated only for explicitly	 named

       $<	      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 manufac‐
		      tured dependent file name).  Thus, in the .c.o rule, the
		      $<  macro would evaluate to the .c file.	An example for
		      making optimized .o files from .c files is:
		      cc -c -O $∗.c
		      cc -c -O $<

       $?	      The $? macro is evaluated when explicit rules  from  the
		      makefile are evaluated.  It is the list of prerequisites
		      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 ar‐
		      chive library member of the form lib(file.o).   In  this
		      case,  $@	 evaluates  to	lib  and  $%  evaluates to the
		      library member, file.o.

       All of the macros can have alternative forms.  When an upper case D  or
       F is appended to any of the 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.

       Certain	names  (for instance, those ending with .o) have prerequisites
       such as .c, .s, which 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,  has
       inference  rules which allow building files from other files by examin‐
       ing 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 are contained in the source file rules.c for the
       program.	 These rules can be locally modified.  To print out the	 rules
       compiled	 into in a form suitable for recompilation, the following com‐
       mand is used from
       make -fp - 2>/dev/null </dev/null

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

       A  tilde	 in  the  above	 rules refers to an SCCS file.	Thus, the rule
       .c~.o 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 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, .c:) is the 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 pro‐
       cedures, simple 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  has a set of internal rules for building files.  The
       user may add rules to this list by simply putting them in the makefile.

       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 options to and respec‐
       tively.	 Again, the previous method for examining the current rules is

       The inference of prerequisites can be controlled.  The rule to create a
       file with suffix .o from a file with suffix .c is specified as an entry
       with .c.o: as the target and no dependents.  Shell commands  associated
       with  the  target  define the rule for making a .o file from a .c file.
       Any target that has no slashes in it and starts with a dot  is  identi‐
       fied 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.a 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, we assume 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
	  $(CC) -c $(CFLAGS1) $<
	  ar rv $@ $*.o
	  rm -f $*.o
       In fact, the .c.a rule listed above is built into 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
       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  .o
       to  .c.	 (Unfortunately,  one cannot as yet transform to .c~; however,
       this may become possible in the future.)	 Note also, the	 disabling  of
       the  .c.a: rule, which would have created each object file, one by one.
       This particular construct speeds up archive library maintenance consid‐
       erably.	 This type of construct becomes very cumbersome if the archive
       library contains a mix of assembly programs and C programs.


See Also
       cc(1), cd(1), lex(1), sh(1), yacc(1), s5make(1)


List of man pages available for Ultrix

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