Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

s5make(1) [ultrix man page]

make(1) 						      General Commands Manual							   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 compatibility 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 execute them.  Even lines beginning with an at sign (@) are printed.

       -p	      Displays the complete set of macro definitions and target descriptions.

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

       -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 special target
		      name .SILENT appears in the description file.

       -S	      Abandon 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.

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

Special Names
	.DEFAULT      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.

       .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 executed 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 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 shell.

       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
       common 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 exe-
       cuted 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 com-

       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 con-
       tinues 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 envi-
       ronment 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:

       o      BSD

       o      POSIX

       o      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 <tab>.

       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 executed anyway.  Hence, one can perform a -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 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
       overridden by environment variables, macros defined in the makefile override environment variables and macros defined on the  command  line
       override  macros  defined in the makefile.  The -e option changes this such that environment variables override macros defined in the make-

       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 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  char-
       acters, 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 makefiles. The legal values are: vax or mips.

   Internal Macros
       There are five internally maintained macros which are useful for writing 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 dependencies.

       $<	      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 .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; essentially, 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, $@ eval-
		      uates 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.

       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 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 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 command 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 procedures, 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
       suffix 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 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 options to and respectively.	Again, the previous method for examining the current rules
       is recommended.

       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 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.a where the XX is the suffix from which the archive member is to be made.  An unfortunate byproduct of the current implementa-
       tion requires the XX to be different from the suffix of the archive member.  Thus, one cannot have lib(file.o) depend upon  file.o  explic-
       itly.  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
       archive 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~; how-
       ever, 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 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 overcome 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.

       [Mm]akefile and s.[Mm]akefile

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

Man Page