make: Catalogue of Rules
1
1 10.2 Catalogue of Built-In Rules
1 ================================
1
1 Here is a catalogue of predefined implicit rules which are always
1 available unless the makefile explicitly overrides or cancels them.
1 ⇒Canceling Implicit Rules Canceling Rules, for information on
1 canceling or overriding an implicit rule. The '-r' or
1 '--no-builtin-rules' option cancels all predefined rules.
1
1 This manual only documents the default rules available on POSIX-based
1 operating systems. Other operating systems, such as VMS, Windows, OS/2,
1 etc. may have different sets of default rules. To see the full list of
1 default rules and variables available in your version of GNU 'make', run
1 'make -p' in a directory with no makefile.
1
1 Not all of these rules will always be defined, even when the '-r'
1 option is not given. Many of the predefined implicit rules are
1 implemented in 'make' as suffix rules, so which ones will be defined
1 depends on the "suffix list" (the list of prerequisites of the special
1 target '.SUFFIXES'). The default suffix list is: '.out', '.a', '.ln',
1 '.o', '.c', '.cc', '.C', '.cpp', '.p', '.f', '.F', '.m', '.r', '.y',
1 '.l', '.ym', '.lm', '.s', '.S', '.mod', '.sym', '.def', '.h', '.info',
1 '.dvi', '.tex', '.texinfo', '.texi', '.txinfo', '.w', '.ch' '.web',
1 '.sh', '.elc', '.el'. All of the implicit rules described below whose
1 prerequisites have one of these suffixes are actually suffix rules. If
1 you modify the suffix list, the only predefined suffix rules in effect
1 will be those named by one or two of the suffixes that are on the list
1 you specify; rules whose suffixes fail to be on the list are disabled.
1 ⇒Old-Fashioned Suffix Rules Suffix Rules, for full details on
1 suffix rules.
1
1 Compiling C programs
1 'N.o' is made automatically from 'N.c' with a recipe of the form
1 '$(CC) $(CPPFLAGS) $(CFLAGS) -c'.
1
1 Compiling C++ programs
1 'N.o' is made automatically from 'N.cc', 'N.cpp', or 'N.C' with a
1 recipe of the form '$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c'. We
1 encourage you to use the suffix '.cc' for C++ source files instead
1 of '.C'.
1
1 Compiling Pascal programs
1 'N.o' is made automatically from 'N.p' with the recipe '$(PC)
1 $(PFLAGS) -c'.
1
1 Compiling Fortran and Ratfor programs
1 'N.o' is made automatically from 'N.r', 'N.F' or 'N.f' by running
1 the Fortran compiler. The precise recipe used is as follows:
1
1 '.f'
1 '$(FC) $(FFLAGS) -c'.
1 '.F'
1 '$(FC) $(FFLAGS) $(CPPFLAGS) -c'.
1 '.r'
1 '$(FC) $(FFLAGS) $(RFLAGS) -c'.
1
1 Preprocessing Fortran and Ratfor programs
1 'N.f' is made automatically from 'N.r' or 'N.F'. This rule runs
1 just the preprocessor to convert a Ratfor or preprocessable Fortran
1 program into a strict Fortran program. The precise recipe used is
1 as follows:
1
1 '.F'
1 '$(FC) $(CPPFLAGS) $(FFLAGS) -F'.
1 '.r'
1 '$(FC) $(FFLAGS) $(RFLAGS) -F'.
1
1 Compiling Modula-2 programs
1 'N.sym' is made from 'N.def' with a recipe of the form '$(M2C)
1 $(M2FLAGS) $(DEFFLAGS)'. 'N.o' is made from 'N.mod'; the form is:
1 '$(M2C) $(M2FLAGS) $(MODFLAGS)'.
1
1 Assembling and preprocessing assembler programs
1 'N.o' is made automatically from 'N.s' by running the assembler,
1 'as'. The precise recipe is '$(AS) $(ASFLAGS)'.
1
1 'N.s' is made automatically from 'N.S' by running the C
1 preprocessor, 'cpp'. The precise recipe is '$(CPP) $(CPPFLAGS)'.
1
1 Linking a single object file
1 'N' is made automatically from 'N.o' by running the linker (usually
1 called 'ld') via the C compiler. The precise recipe used is
1 '$(CC) $(LDFLAGS) N.o $(LOADLIBES) $(LDLIBS)'.
1
1 This rule does the right thing for a simple program with only one
1 source file. It will also do the right thing if there are multiple
1 object files (presumably coming from various other source files),
1 one of which has a name matching that of the executable file.
1 Thus,
1
1 x: y.o z.o
1
1 when 'x.c', 'y.c' and 'z.c' all exist will execute:
1
1 cc -c x.c -o x.o
1 cc -c y.c -o y.o
1 cc -c z.c -o z.o
1 cc x.o y.o z.o -o x
1 rm -f x.o
1 rm -f y.o
1 rm -f z.o
1
1 In more complicated cases, such as when there is no object file
1 whose name derives from the executable file name, you must write an
1 explicit recipe for linking.
1
1 Each kind of file automatically made into '.o' object files will be
1 automatically linked by using the compiler ('$(CC)', '$(FC)' or
1 '$(PC)'; the C compiler '$(CC)' is used to assemble '.s' files)
1 without the '-c' option. This could be done by using the '.o'
1 object files as intermediates, but it is faster to do the compiling
1 and linking in one step, so that's how it's done.
1
1 Yacc for C programs
1 'N.c' is made automatically from 'N.y' by running Yacc with the
1 recipe '$(YACC) $(YFLAGS)'.
1
1 Lex for C programs
1 'N.c' is made automatically from 'N.l' by running Lex. The actual
1 recipe is '$(LEX) $(LFLAGS)'.
1
1 Lex for Ratfor programs
1 'N.r' is made automatically from 'N.l' by running Lex. The actual
1 recipe is '$(LEX) $(LFLAGS)'.
1
1 The convention of using the same suffix '.l' for all Lex files
1 regardless of whether they produce C code or Ratfor code makes it
1 impossible for 'make' to determine automatically which of the two
1 languages you are using in any particular case. If 'make' is
1 called upon to remake an object file from a '.l' file, it must
1 guess which compiler to use. It will guess the C compiler, because
1 that is more common. If you are using Ratfor, make sure 'make'
1 knows this by mentioning 'N.r' in the makefile. Or, if you are
1 using Ratfor exclusively, with no C files, remove '.c' from the
1 list of implicit rule suffixes with:
1
1 .SUFFIXES:
1 .SUFFIXES: .o .r .f .l ...
1
1 Making Lint Libraries from C, Yacc, or Lex programs
1 'N.ln' is made from 'N.c' by running 'lint'. The precise recipe is
1 '$(LINT) $(LINTFLAGS) $(CPPFLAGS) -i'. The same recipe is used on
1 the C code produced from 'N.y' or 'N.l'.
1
1 TeX and Web
1 'N.dvi' is made from 'N.tex' with the recipe '$(TEX)'. 'N.tex' is
1 made from 'N.web' with '$(WEAVE)', or from 'N.w' (and from 'N.ch'
1 if it exists or can be made) with '$(CWEAVE)'. 'N.p' is made from
1 'N.web' with '$(TANGLE)' and 'N.c' is made from 'N.w' (and from
1 'N.ch' if it exists or can be made) with '$(CTANGLE)'.
1
1 Texinfo and Info
1 'N.dvi' is made from 'N.texinfo', 'N.texi', or 'N.txinfo', with the
1 recipe '$(TEXI2DVI) $(TEXI2DVI_FLAGS)'. 'N.info' is made from
1 'N.texinfo', 'N.texi', or 'N.txinfo', with the recipe
1 '$(MAKEINFO) $(MAKEINFO_FLAGS)'.
1
1 RCS
1 Any file 'N' is extracted if necessary from an RCS file named
1 either 'N,v' or 'RCS/N,v'. The precise recipe used is
1 '$(CO) $(COFLAGS)'. 'N' will not be extracted from RCS if it
1 already exists, even if the RCS file is newer. The rules for RCS
11 are terminal (⇒Match-Anything Pattern Rules Match-Anything
Rules.), so RCS files cannot be generated from another source; they
1 must actually exist.
1
1 SCCS
1 Any file 'N' is extracted if necessary from an SCCS file named
1 either 's.N' or 'SCCS/s.N'. The precise recipe used is
11 '$(GET) $(GFLAGS)'. The rules for SCCS are terminal (⇒
Match-Anything Pattern Rules Match-Anything Rules.), so SCCS files
1 cannot be generated from another source; they must actually exist.
1
1 For the benefit of SCCS, a file 'N' is copied from 'N.sh' and made
1 executable (by everyone). This is for shell scripts that are
1 checked into SCCS. Since RCS preserves the execution permission of
1 a file, you do not need to use this feature with RCS.
1
1 We recommend that you avoid using of SCCS. RCS is widely held to be
1 superior, and is also free. By choosing free software in place of
1 comparable (or inferior) proprietary software, you support the free
1 software movement.
1
1 Usually, you want to change only the variables listed in the table
1 above, which are documented in the following section.
1
1 However, the recipes in built-in implicit rules actually use
1 variables such as 'COMPILE.c', 'LINK.p', and 'PREPROCESS.S', whose
1 values contain the recipes listed above.
1
1 'make' follows the convention that the rule to compile a '.X' source
1 file uses the variable 'COMPILE.X'. Similarly, the rule to produce an
1 executable from a '.X' file uses 'LINK.X'; and the rule to preprocess a
1 '.X' file uses 'PREPROCESS.X'.
1
1 Every rule that produces an object file uses the variable
1 'OUTPUT_OPTION'. 'make' defines this variable either to contain '-o
1 $@', or to be empty, depending on a compile-time option. You need the
1 '-o' option to ensure that the output goes into the right file when the
11 source file is in a different directory, as when using 'VPATH' (⇒
Directory Search). However, compilers on some systems do not accept a
1 '-o' switch for object files. If you use such a system, and use
1 'VPATH', some compilations will put their output in the wrong place. A
1 possible workaround for this problem is to give 'OUTPUT_OPTION' the
1 value '; mv $*.o $@'.
1