| This is |
| /Volumes/Android/buildbot/src/android/ndk-release-r23/toolchain/make/doc/make.info, |
| produced by makeinfo version 4.8 from |
| /Volumes/Android/buildbot/src/android/ndk-release-r23/toolchain/make/doc/make.texi. |
| |
| This file documents the GNU `make' utility, which determines |
| automatically which pieces of a large program need to be recompiled, |
| and issues the commands to recompile them. |
| |
| This is Edition 0.75, last updated 21 May 2016, of `The GNU Make |
| Manual', for GNU `make' version 4.2.1. |
| |
| Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, |
| 1997, 1998, 1999, 2000, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, |
| 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020 Free |
| Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this |
| document under the terms of the GNU Free Documentation License, |
| Version 1.3 or any later version published by the Free Software |
| Foundation; with no Invariant Sections, with the Front-Cover Texts |
| being "A GNU Manual," and with the Back-Cover Texts as in (a) |
| below. A copy of the license is included in the section entitled |
| "GNU Free Documentation License." |
| |
| (a) The FSF's Back-Cover Text is: "You have the freedom to copy and |
| modify this GNU manual. Buying copies from the FSF supports it in |
| developing GNU and promoting software freedom." |
| |
| INFO-DIR-SECTION Software development |
| START-INFO-DIR-ENTRY |
| * Make: (make). Remake files automatically. |
| END-INFO-DIR-ENTRY |
| |
| |
| File: make.info, Node: Testing, Next: Options Summary, Prev: Overriding, Up: Running |
| |
| 9.6 Testing the Compilation of a Program |
| ======================================== |
| |
| Normally, when an error happens in executing a shell command, `make' |
| gives up immediately, returning a nonzero status. No further recipes |
| are executed for any target. The error implies that the goal cannot be |
| correctly remade, and `make' reports this as soon as it knows. |
| |
| When you are compiling a program that you have just changed, this is |
| not what you want. Instead, you would rather that `make' try compiling |
| every file that can be tried, to show you as many compilation errors as |
| possible. |
| |
| On these occasions, you should use the `-k' or `--keep-going' flag. |
| This tells `make' to continue to consider the other prerequisites of |
| the pending targets, remaking them if necessary, before it gives up and |
| returns nonzero status. For example, after an error in compiling one |
| object file, `make -k' will continue compiling other object files even |
| though it already knows that linking them will be impossible. In |
| addition to continuing after failed shell commands, `make -k' will |
| continue as much as possible after discovering that it does not know |
| how to make a target or prerequisite file. This will always cause an |
| error message, but without `-k', it is a fatal error (*note Summary of |
| Options: Options Summary.). |
| |
| The usual behavior of `make' assumes that your purpose is to get the |
| goals up to date; once `make' learns that this is impossible, it might |
| as well report the failure immediately. The `-k' flag says that the |
| real purpose is to test as much as possible of the changes made in the |
| program, perhaps to find several independent problems so that you can |
| correct them all before the next attempt to compile. This is why Emacs' |
| `M-x compile' command passes the `-k' flag by default. |
| |
| |
| File: make.info, Node: Options Summary, Prev: Testing, Up: Running |
| |
| 9.7 Summary of Options |
| ====================== |
| |
| Here is a table of all the options `make' understands: |
| |
| `-b' |
| `-m' |
| These options are ignored for compatibility with other versions of |
| `make'. |
| |
| `-B' |
| `--always-make' |
| Consider all targets out-of-date. GNU `make' proceeds to consider |
| targets and their prerequisites using the normal algorithms; |
| however, all targets so considered are always remade regardless of |
| the status of their prerequisites. To avoid infinite recursion, if |
| `MAKE_RESTARTS' (*note Other Special Variables: Special |
| Variables.) is set to a number greater than 0 this option is |
| disabled when considering whether to remake makefiles (*note How |
| Makefiles Are Remade: Remaking Makefiles.). |
| |
| `-C DIR' |
| `--directory=DIR' |
| Change to directory DIR before reading the makefiles. If multiple |
| `-C' options are specified, each is interpreted relative to the |
| previous one: `-C / -C etc' is equivalent to `-C /etc'. This is |
| typically used with recursive invocations of `make' (*note |
| Recursive Use of `make': Recursion.). |
| |
| `-d' |
| Print debugging information in addition to normal processing. The |
| debugging information says which files are being considered for |
| remaking, which file-times are being compared and with what |
| results, which files actually need to be remade, which implicit |
| rules are considered and which are applied--everything interesting |
| about how `make' decides what to do. The `-d' option is |
| equivalent to `--debug=a' (see below). |
| |
| `--debug[=OPTIONS]' |
| Print debugging information in addition to normal processing. |
| Various levels and types of output can be chosen. With no |
| arguments, print the "basic" level of debugging. Possible |
| arguments are below; only the first character is considered, and |
| values must be comma- or space-separated. |
| |
| `a (all)' |
| All types of debugging output are enabled. This is |
| equivalent to using `-d'. |
| |
| `b (basic)' |
| Basic debugging prints each target that was found to be |
| out-of-date, and whether the build was successful or not. |
| |
| `v (verbose)' |
| A level above `basic'; includes messages about which |
| makefiles were parsed, prerequisites that did not need to be |
| rebuilt, etc. This option also enables `basic' messages. |
| |
| `i (implicit)' |
| Prints messages describing the implicit rule searches for |
| each target. This option also enables `basic' messages. |
| |
| `j (jobs)' |
| Prints messages giving details on the invocation of specific |
| sub-commands. |
| |
| `m (makefile)' |
| By default, the above messages are not enabled while trying |
| to remake the makefiles. This option enables messages while |
| rebuilding makefiles, too. Note that the `all' option does |
| enable this option. This option also enables `basic' |
| messages. |
| |
| `n (none)' |
| Disable all debugging currently enabled. If additional |
| debugging flags are encountered after this they will still |
| take effect. |
| |
| `-e' |
| `--environment-overrides' |
| Give variables taken from the environment precedence over |
| variables from makefiles. *Note Variables from the Environment: |
| Environment. |
| |
| `-E STRING' |
| |
| `--eval=STRING' |
| Evaluate STRING as makefile syntax. This is a command-line |
| version of the `eval' function (*note Eval Function::). The |
| evaluation is performed after the default rules and variables have |
| been defined, but before any makefiles are read. |
| |
| `-f FILE' |
| `--file=FILE' |
| `--makefile=FILE' |
| Read the file named FILE as a makefile. *Note Writing Makefiles: |
| Makefiles. |
| |
| `-h' |
| `--help' |
| Remind you of the options that `make' understands and then exit. |
| |
| `-i' |
| `--ignore-errors' |
| Ignore all errors in recipes executed to remake files. *Note |
| Errors in Recipes: Errors. |
| |
| `-I DIR' |
| `--include-dir=DIR' |
| Specifies a directory DIR to search for included makefiles. *Note |
| Including Other Makefiles: Include. If several `-I' options are |
| used to specify several directories, the directories are searched |
| in the order specified. |
| |
| `-j [JOBS]' |
| `--jobs[=JOBS]' |
| Specifies the number of recipes (jobs) to run simultaneously. |
| With no argument, `make' runs as many recipes simultaneously as |
| possible. If there is more than one `-j' option, the last one is |
| effective. *Note Parallel Execution: Parallel, for more |
| information on how recipes are run. Note that this option is |
| ignored on MS-DOS. |
| |
| `-k' |
| `--keep-going' |
| Continue as much as possible after an error. While the target that |
| failed, and those that depend on it, cannot be remade, the other |
| prerequisites of these targets can be processed all the same. |
| *Note Testing the Compilation of a Program: Testing. |
| |
| `-l [LOAD]' |
| `--load-average[=LOAD]' |
| `--max-load[=LOAD]' |
| Specifies that no new recipes should be started if there are other |
| recipes running and the load average is at least LOAD (a |
| floating-point number). With no argument, removes a previous load |
| limit. *Note Parallel Execution: Parallel. |
| |
| `-L' |
| `--check-symlink-times' |
| On systems that support symbolic links, this option causes `make' |
| to consider the timestamps on any symbolic links in addition to the |
| timestamp on the file referenced by those links. When this option |
| is provided, the most recent timestamp among the file and the |
| symbolic links is taken as the modification time for this target |
| file. |
| |
| `-n' |
| `--just-print' |
| `--dry-run' |
| `--recon' |
| Print the recipe that would be executed, but do not execute it |
| (except in certain circumstances). *Note Instead of Executing |
| Recipes: Instead of Execution. |
| |
| `-o FILE' |
| `--old-file=FILE' |
| `--assume-old=FILE' |
| Do not remake the file FILE even if it is older than its |
| prerequisites, and do not remake anything on account of changes in |
| FILE. Essentially the file is treated as very old and its rules |
| are ignored. *Note Avoiding Recompilation of Some Files: Avoiding |
| Compilation. |
| |
| `-O[TYPE]' |
| `--output-sync[=TYPE]' |
| Ensure that the complete output from each recipe is printed in one |
| uninterrupted sequence. This option is only useful when using the |
| `--jobs' option to run multiple recipes simultaneously (*note |
| Parallel Execution: Parallel.) Without this option output will be |
| displayed as it is generated by the recipes. |
| |
| With no type or the type `target', output from the entire recipe |
| of each target is grouped together. With the type `line', output |
| from each line in the recipe is grouped together. With the type |
| `recurse', the output from an entire recursive make is grouped |
| together. With the type `none', no output synchronization is |
| performed. *Note Output During Parallel Execution: Parallel |
| Output. |
| |
| `-p' |
| `--print-data-base' |
| Print the data base (rules and variable values) that results from |
| reading the makefiles; then execute as usual or as otherwise |
| specified. This also prints the version information given by the |
| `-v' switch (see below). To print the data base without trying to |
| remake any files, use `make -qp'. To print the data base of |
| predefined rules and variables, use `make -p -f /dev/null'. The |
| data base output contains file name and line number information for |
| recipe and variable definitions, so it can be a useful debugging |
| tool in complex environments. |
| |
| `-q' |
| `--question' |
| "Question mode". Do not run any recipes, or print anything; just |
| return an exit status that is zero if the specified targets are |
| already up to date, one if any remaking is required, or two if an |
| error is encountered. *Note Instead of Executing Recipes: Instead |
| of Execution. |
| |
| `-r' |
| `--no-builtin-rules' |
| Eliminate use of the built-in implicit rules (*note Using Implicit |
| Rules: Implicit Rules.). You can still define your own by writing |
| pattern rules (*note Defining and Redefining Pattern Rules: |
| Pattern Rules.). The `-r' option also clears out the default list |
| of suffixes for suffix rules (*note Old-Fashioned Suffix Rules: |
| Suffix Rules.). But you can still define your own suffixes with a |
| rule for `.SUFFIXES', and then define your own suffix rules. Note |
| that only _rules_ are affected by the `-r' option; default |
| variables remain in effect (*note Variables Used by Implicit |
| Rules: Implicit Variables.); see the `-R' option below. |
| |
| `-R' |
| `--no-builtin-variables' |
| Eliminate use of the built-in rule-specific variables (*note |
| Variables Used by Implicit Rules: Implicit Variables.). You can |
| still define your own, of course. The `-R' option also |
| automatically enables the `-r' option (see above), since it |
| doesn't make sense to have implicit rules without any definitions |
| for the variables that they use. |
| |
| `-s' |
| `--silent' |
| `--quiet' |
| Silent operation; do not print the recipes as they are executed. |
| *Note Recipe Echoing: Echoing. |
| |
| `-S' |
| `--no-keep-going' |
| `--stop' |
| Cancel the effect of the `-k' option. This is never necessary |
| except in a recursive `make' where `-k' might be inherited from |
| the top-level `make' via `MAKEFLAGS' (*note Recursive Use of |
| `make': Recursion.) or if you set `-k' in `MAKEFLAGS' in your |
| environment. |
| |
| `-t' |
| `--touch' |
| Touch files (mark them up to date without really changing them) |
| instead of running their recipes. This is used to pretend that the |
| recipes were done, in order to fool future invocations of `make'. |
| *Note Instead of Executing Recipes: Instead of Execution. |
| |
| `--trace' |
| Show tracing information for `make' execution. Prints the entire |
| recipe to be executed, even for recipes that are normally silent |
| (due to `.SILENT' or `@'). Also prints the makefile name and line |
| number where the recipe was defined, and information on why the |
| target is being rebuilt. |
| |
| `-v' |
| `--version' |
| Print the version of the `make' program plus a copyright, a list |
| of authors, and a notice that there is no warranty; then exit. |
| |
| `-w' |
| `--print-directory' |
| Print a message containing the working directory both before and |
| after executing the makefile. This may be useful for tracking |
| down errors from complicated nests of recursive `make' commands. |
| *Note Recursive Use of `make': Recursion. (In practice, you |
| rarely need to specify this option since `make' does it for you; |
| see *Note The `--print-directory' Option: -w Option.) |
| |
| `--no-print-directory' |
| Disable printing of the working directory under `-w'. This option |
| is useful when `-w' is turned on automatically, but you do not |
| want to see the extra messages. *Note The `--print-directory' |
| Option: -w Option. |
| |
| `-W FILE' |
| `--what-if=FILE' |
| `--new-file=FILE' |
| `--assume-new=FILE' |
| Pretend that the target FILE has just been modified. When used |
| with the `-n' flag, this shows you what would happen if you were |
| to modify that file. Without `-n', it is almost the same as |
| running a `touch' command on the given file before running `make', |
| except that the modification time is changed only in the |
| imagination of `make'. *Note Instead of Executing Recipes: |
| Instead of Execution. |
| |
| `--warn-undefined-variables' |
| Issue a warning message whenever `make' sees a reference to an |
| undefined variable. This can be helpful when you are trying to |
| debug makefiles which use variables in complex ways. |
| |
| |
| File: make.info, Node: Implicit Rules, Next: Archives, Prev: Running, Up: Top |
| |
| 10 Using Implicit Rules |
| *********************** |
| |
| Certain standard ways of remaking target files are used very often. For |
| example, one customary way to make an object file is from a C source |
| file using the C compiler, `cc'. |
| |
| "Implicit rules" tell `make' how to use customary techniques so that |
| you do not have to specify them in detail when you want to use them. |
| For example, there is an implicit rule for C compilation. File names |
| determine which implicit rules are run. For example, C compilation |
| typically takes a `.c' file and makes a `.o' file. So `make' applies |
| the implicit rule for C compilation when it sees this combination of |
| file name endings. |
| |
| A chain of implicit rules can apply in sequence; for example, `make' |
| will remake a `.o' file from a `.y' file by way of a `.c' file. |
| |
| The built-in implicit rules use several variables in their recipes so |
| that, by changing the values of the variables, you can change the way |
| the implicit rule works. For example, the variable `CFLAGS' controls |
| the flags given to the C compiler by the implicit rule for C |
| compilation. |
| |
| You can define your own implicit rules by writing "pattern rules". |
| |
| "Suffix rules" are a more limited way to define implicit rules. |
| Pattern rules are more general and clearer, but suffix rules are |
| retained for compatibility. |
| |
| * Menu: |
| |
| * Using Implicit:: How to use an existing implicit rule |
| to get the recipes for updating a file. |
| * Catalogue of Rules:: A list of built-in rules. |
| * Implicit Variables:: How to change what predefined rules do. |
| * Chained Rules:: How to use a chain of implicit rules. |
| * Pattern Rules:: How to define new implicit rules. |
| * Last Resort:: How to define a recipe for rules which |
| cannot find any. |
| * Suffix Rules:: The old-fashioned style of implicit rule. |
| * Implicit Rule Search:: The precise algorithm for applying |
| implicit rules. |
| |
| |
| File: make.info, Node: Using Implicit, Next: Catalogue of Rules, Prev: Implicit Rules, Up: Implicit Rules |
| |
| 10.1 Using Implicit Rules |
| ========================= |
| |
| To allow `make' to find a customary method for updating a target file, |
| all you have to do is refrain from specifying recipes yourself. Either |
| write a rule with no recipe, or don't write a rule at all. Then `make' |
| will figure out which implicit rule to use based on which kind of |
| source file exists or can be made. |
| |
| For example, suppose the makefile looks like this: |
| |
| foo : foo.o bar.o |
| cc -o foo foo.o bar.o $(CFLAGS) $(LDFLAGS) |
| |
| Because you mention `foo.o' but do not give a rule for it, `make' will |
| automatically look for an implicit rule that tells how to update it. |
| This happens whether or not the file `foo.o' currently exists. |
| |
| If an implicit rule is found, it can supply both a recipe and one or |
| more prerequisites (the source files). You would want to write a rule |
| for `foo.o' with no recipe if you need to specify additional |
| prerequisites, such as header files, that the implicit rule cannot |
| supply. |
| |
| Each implicit rule has a target pattern and prerequisite patterns. |
| There may be many implicit rules with the same target pattern. For |
| example, numerous rules make `.o' files: one, from a `.c' file with the |
| C compiler; another, from a `.p' file with the Pascal compiler; and so |
| on. The rule that actually applies is the one whose prerequisites |
| exist or can be made. So, if you have a file `foo.c', `make' will run |
| the C compiler; otherwise, if you have a file `foo.p', `make' will run |
| the Pascal compiler; and so on. |
| |
| Of course, when you write the makefile, you know which implicit rule |
| you want `make' to use, and you know it will choose that one because you |
| know which possible prerequisite files are supposed to exist. *Note |
| Catalogue of Built-In Rules: Catalogue of Rules, for a catalogue of all |
| the predefined implicit rules. |
| |
| Above, we said an implicit rule applies if the required |
| prerequisites "exist or can be made". A file "can be made" if it is |
| mentioned explicitly in the makefile as a target or a prerequisite, or |
| if an implicit rule can be recursively found for how to make it. When |
| an implicit prerequisite is the result of another implicit rule, we say |
| that "chaining" is occurring. *Note Chains of Implicit Rules: Chained |
| Rules. |
| |
| In general, `make' searches for an implicit rule for each target, and |
| for each double-colon rule, that has no recipe. A file that is |
| mentioned only as a prerequisite is considered a target whose rule |
| specifies nothing, so implicit rule search happens for it. *Note |
| Implicit Rule Search Algorithm: Implicit Rule Search, for the details |
| of how the search is done. |
| |
| Note that explicit prerequisites do not influence implicit rule |
| search. For example, consider this explicit rule: |
| |
| foo.o: foo.p |
| |
| The prerequisite on `foo.p' does not necessarily mean that `make' will |
| remake `foo.o' according to the implicit rule to make an object file, a |
| `.o' file, from a Pascal source file, a `.p' file. For example, if |
| `foo.c' also exists, the implicit rule to make an object file from a C |
| source file is used instead, because it appears before the Pascal rule |
| in the list of predefined implicit rules (*note Catalogue of Built-In |
| Rules: Catalogue of Rules.). |
| |
| If you do not want an implicit rule to be used for a target that has |
| no recipe, you can give that target an empty recipe by writing a |
| semicolon (*note Defining Empty Recipes: Empty Recipes.). |
| |
| |
| File: make.info, Node: Catalogue of Rules, Next: Implicit Variables, Prev: Using Implicit, Up: Implicit Rules |
| |
| 10.2 Catalogue of Built-In Rules |
| ================================ |
| |
| Here is a catalogue of predefined implicit rules which are always |
| available unless the makefile explicitly overrides or cancels them. |
| *Note Canceling Implicit Rules: Canceling Rules, for information on |
| canceling or overriding an implicit rule. The `-r' or |
| `--no-builtin-rules' option cancels all predefined rules. |
| |
| This manual only documents the default rules available on POSIX-based |
| operating systems. Other operating systems, such as VMS, Windows, |
| OS/2, etc. may have different sets of default rules. To see the full |
| list of default rules and variables available in your version of GNU |
| `make', run `make -p' in a directory with no makefile. |
| |
| Not all of these rules will always be defined, even when the `-r' |
| option is not given. Many of the predefined implicit rules are |
| implemented in `make' as suffix rules, so which ones will be defined |
| depends on the "suffix list" (the list of prerequisites of the special |
| target `.SUFFIXES'). The default suffix list is: `.out', `.a', `.ln', |
| `.o', `.c', `.cc', `.C', `.cpp', `.p', `.f', `.F', `.m', `.r', `.y', |
| `.l', `.ym', `.lm', `.s', `.S', `.mod', `.sym', `.def', `.h', `.info', |
| `.dvi', `.tex', `.texinfo', `.texi', `.txinfo', `.w', `.ch' `.web', |
| `.sh', `.elc', `.el'. All of the implicit rules described below whose |
| prerequisites have one of these suffixes are actually suffix rules. If |
| you modify the suffix list, the only predefined suffix rules in effect |
| will be those named by one or two of the suffixes that are on the list |
| you specify; rules whose suffixes fail to be on the list are disabled. |
| *Note Old-Fashioned Suffix Rules: Suffix Rules, for full details on |
| suffix rules. |
| |
| Compiling C programs |
| `N.o' is made automatically from `N.c' with a recipe of the form |
| `$(CC) $(CPPFLAGS) $(CFLAGS) -c'. |
| |
| Compiling C++ programs |
| `N.o' is made automatically from `N.cc', `N.cpp', or `N.C' with a |
| recipe of the form `$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c'. We |
| encourage you to use the suffix `.cc' for C++ source files instead |
| of `.C'. |
| |
| Compiling Pascal programs |
| `N.o' is made automatically from `N.p' with the recipe `$(PC) |
| $(PFLAGS) -c'. |
| |
| Compiling Fortran and Ratfor programs |
| `N.o' is made automatically from `N.r', `N.F' or `N.f' by running |
| the Fortran compiler. The precise recipe used is as follows: |
| |
| `.f' |
| `$(FC) $(FFLAGS) -c'. |
| |
| `.F' |
| `$(FC) $(FFLAGS) $(CPPFLAGS) -c'. |
| |
| `.r' |
| `$(FC) $(FFLAGS) $(RFLAGS) -c'. |
| |
| Preprocessing Fortran and Ratfor programs |
| `N.f' is made automatically from `N.r' or `N.F'. This rule runs |
| just the preprocessor to convert a Ratfor or preprocessable |
| Fortran program into a strict Fortran program. The precise recipe |
| used is as follows: |
| |
| `.F' |
| `$(FC) $(CPPFLAGS) $(FFLAGS) -F'. |
| |
| `.r' |
| `$(FC) $(FFLAGS) $(RFLAGS) -F'. |
| |
| Compiling Modula-2 programs |
| `N.sym' is made from `N.def' with a recipe of the form `$(M2C) |
| $(M2FLAGS) $(DEFFLAGS)'. `N.o' is made from `N.mod'; the form is: |
| `$(M2C) $(M2FLAGS) $(MODFLAGS)'. |
| |
| Assembling and preprocessing assembler programs |
| `N.o' is made automatically from `N.s' by running the assembler, |
| `as'. The precise recipe is `$(AS) $(ASFLAGS)'. |
| |
| `N.s' is made automatically from `N.S' by running the C |
| preprocessor, `cpp'. The precise recipe is `$(CPP) $(CPPFLAGS)'. |
| |
| Linking a single object file |
| `N' is made automatically from `N.o' by running the linker |
| (usually called `ld') via the C compiler. The precise recipe used |
| is `$(CC) $(LDFLAGS) N.o $(LOADLIBES) $(LDLIBS)'. |
| |
| This rule does the right thing for a simple program with only one |
| source file. It will also do the right thing if there are multiple |
| object files (presumably coming from various other source files), |
| one of which has a name matching that of the executable file. |
| Thus, |
| |
| x: y.o z.o |
| |
| when `x.c', `y.c' and `z.c' all exist will execute: |
| |
| cc -c x.c -o x.o |
| cc -c y.c -o y.o |
| cc -c z.c -o z.o |
| cc x.o y.o z.o -o x |
| rm -f x.o |
| rm -f y.o |
| rm -f z.o |
| |
| In more complicated cases, such as when there is no object file |
| whose name derives from the executable file name, you must write |
| an explicit recipe for linking. |
| |
| Each kind of file automatically made into `.o' object files will |
| be automatically linked by using the compiler (`$(CC)', `$(FC)' or |
| `$(PC)'; the C compiler `$(CC)' is used to assemble `.s' files) |
| without the `-c' option. This could be done by using the `.o' |
| object files as intermediates, but it is faster to do the |
| compiling and linking in one step, so that's how it's done. |
| |
| Yacc for C programs |
| `N.c' is made automatically from `N.y' by running Yacc with the |
| recipe `$(YACC) $(YFLAGS)'. |
| |
| Lex for C programs |
| `N.c' is made automatically from `N.l' by running Lex. The actual |
| recipe is `$(LEX) $(LFLAGS)'. |
| |
| Lex for Ratfor programs |
| `N.r' is made automatically from `N.l' by running Lex. The actual |
| recipe is `$(LEX) $(LFLAGS)'. |
| |
| The convention of using the same suffix `.l' for all Lex files |
| regardless of whether they produce C code or Ratfor code makes it |
| impossible for `make' to determine automatically which of the two |
| languages you are using in any particular case. If `make' is |
| called upon to remake an object file from a `.l' file, it must |
| guess which compiler to use. It will guess the C compiler, because |
| that is more common. If you are using Ratfor, make sure `make' |
| knows this by mentioning `N.r' in the makefile. Or, if you are |
| using Ratfor exclusively, with no C files, remove `.c' from the |
| list of implicit rule suffixes with: |
| |
| .SUFFIXES: |
| .SUFFIXES: .o .r .f .l ... |
| |
| Making Lint Libraries from C, Yacc, or Lex programs |
| `N.ln' is made from `N.c' by running `lint'. The precise recipe |
| is `$(LINT) $(LINTFLAGS) $(CPPFLAGS) -i'. The same recipe is used |
| on the C code produced from `N.y' or `N.l'. |
| |
| TeX and Web |
| `N.dvi' is made from `N.tex' with the recipe `$(TEX)'. `N.tex' is |
| made from `N.web' with `$(WEAVE)', or from `N.w' (and from `N.ch' |
| if it exists or can be made) with `$(CWEAVE)'. `N.p' is made from |
| `N.web' with `$(TANGLE)' and `N.c' is made from `N.w' (and from |
| `N.ch' if it exists or can be made) with `$(CTANGLE)'. |
| |
| Texinfo and Info |
| `N.dvi' is made from `N.texinfo', `N.texi', or `N.txinfo', with |
| the recipe `$(TEXI2DVI) $(TEXI2DVI_FLAGS)'. `N.info' is made from |
| `N.texinfo', `N.texi', or `N.txinfo', with the recipe |
| `$(MAKEINFO) $(MAKEINFO_FLAGS)'. |
| |
| RCS |
| Any file `N' is extracted if necessary from an RCS file named |
| either `N,v' or `RCS/N,v'. The precise recipe used is |
| `$(CO) $(COFLAGS)'. `N' will not be extracted from RCS if it |
| already exists, even if the RCS file is newer. The rules for RCS |
| are terminal (*note Match-Anything Pattern Rules: Match-Anything |
| Rules.), so RCS files cannot be generated from another source; |
| they must actually exist. |
| |
| SCCS |
| Any file `N' is extracted if necessary from an SCCS file named |
| either `s.N' or `SCCS/s.N'. The precise recipe used is |
| `$(GET) $(GFLAGS)'. The rules for SCCS are terminal (*note |
| Match-Anything Pattern Rules: Match-Anything Rules.), so SCCS |
| files cannot be generated from another source; they must actually |
| exist. |
| |
| For the benefit of SCCS, a file `N' is copied from `N.sh' and made |
| executable (by everyone). This is for shell scripts that are |
| checked into SCCS. Since RCS preserves the execution permission |
| of a file, you do not need to use this feature with RCS. |
| |
| We recommend that you avoid using of SCCS. RCS is widely held to |
| be superior, and is also free. By choosing free software in place |
| of comparable (or inferior) proprietary software, you support the |
| free software movement. |
| |
| Usually, you want to change only the variables listed in the table |
| above, which are documented in the following section. |
| |
| However, the recipes in built-in implicit rules actually use |
| variables such as `COMPILE.c', `LINK.p', and `PREPROCESS.S', whose |
| values contain the recipes listed above. |
| |
| `make' follows the convention that the rule to compile a `.X' source |
| file uses the variable `COMPILE.X'. Similarly, the rule to produce an |
| executable from a `.X' file uses `LINK.X'; and the rule to preprocess a |
| `.X' file uses `PREPROCESS.X'. |
| |
| Every rule that produces an object file uses the variable |
| `OUTPUT_OPTION'. `make' defines this variable either to contain `-o |
| $@', or to be empty, depending on a compile-time option. You need the |
| `-o' option to ensure that the output goes into the right file when the |
| source file is in a different directory, as when using `VPATH' (*note |
| Directory Search::). However, compilers on some systems do not accept |
| a `-o' switch for object files. If you use such a system, and use |
| `VPATH', some compilations will put their output in the wrong place. A |
| possible workaround for this problem is to give `OUTPUT_OPTION' the |
| value `; mv $*.o $@'. |
| |
| |
| File: make.info, Node: Implicit Variables, Next: Chained Rules, Prev: Catalogue of Rules, Up: Implicit Rules |
| |
| 10.3 Variables Used by Implicit Rules |
| ===================================== |
| |
| The recipes in built-in implicit rules make liberal use of certain |
| predefined variables. You can alter the values of these variables in |
| the makefile, with arguments to `make', or in the environment to alter |
| how the implicit rules work without redefining the rules themselves. |
| You can cancel all variables used by implicit rules with the `-R' or |
| `--no-builtin-variables' option. |
| |
| For example, the recipe used to compile a C source file actually says |
| `$(CC) -c $(CFLAGS) $(CPPFLAGS)'. The default values of the variables |
| used are `cc' and nothing, resulting in the command `cc -c'. By |
| redefining `CC' to `ncc', you could cause `ncc' to be used for all C |
| compilations performed by the implicit rule. By redefining `CFLAGS' to |
| be `-g', you could pass the `-g' option to each compilation. _All_ |
| implicit rules that do C compilation use `$(CC)' to get the program |
| name for the compiler and _all_ include `$(CFLAGS)' among the arguments |
| given to the compiler. |
| |
| The variables used in implicit rules fall into two classes: those |
| that are names of programs (like `CC') and those that contain arguments |
| for the programs (like `CFLAGS'). (The "name of a program" may also |
| contain some command arguments, but it must start with an actual |
| executable program name.) If a variable value contains more than one |
| argument, separate them with spaces. |
| |
| The following tables describe of some of the more commonly-used |
| predefined variables. This list is not exhaustive, and the default |
| values shown here may not be what `make' selects for your environment. |
| To see the complete list of predefined variables for your instance of |
| GNU `make' you can run `make -p' in a directory with no makefiles. |
| |
| Here is a table of some of the more common variables used as names of |
| programs in built-in rules: |
| |
| `AR' |
| Archive-maintaining program; default `ar'. |
| |
| `AS' |
| Program for compiling assembly files; default `as'. |
| |
| `CC' |
| Program for compiling C programs; default `cc'. |
| |
| `CXX' |
| Program for compiling C++ programs; default `g++'. |
| |
| `CPP' |
| Program for running the C preprocessor, with results to standard |
| output; default `$(CC) -E'. |
| |
| `FC' |
| Program for compiling or preprocessing Fortran and Ratfor programs; |
| default `f77'. |
| |
| `M2C' |
| Program to use to compile Modula-2 source code; default `m2c'. |
| |
| `PC' |
| Program for compiling Pascal programs; default `pc'. |
| |
| `CO' |
| Program for extracting a file from RCS; default `co'. |
| |
| `GET' |
| Program for extracting a file from SCCS; default `get'. |
| |
| `LEX' |
| Program to use to turn Lex grammars into source code; default |
| `lex'. |
| |
| `YACC' |
| Program to use to turn Yacc grammars into source code; default |
| `yacc'. |
| |
| `LINT' |
| Program to use to run lint on source code; default `lint'. |
| |
| `MAKEINFO' |
| Program to convert a Texinfo source file into an Info file; default |
| `makeinfo'. |
| |
| `TEX' |
| Program to make TeX DVI files from TeX source; default `tex'. |
| |
| `TEXI2DVI' |
| Program to make TeX DVI files from Texinfo source; default |
| `texi2dvi'. |
| |
| `WEAVE' |
| Program to translate Web into TeX; default `weave'. |
| |
| `CWEAVE' |
| Program to translate C Web into TeX; default `cweave'. |
| |
| `TANGLE' |
| Program to translate Web into Pascal; default `tangle'. |
| |
| `CTANGLE' |
| Program to translate C Web into C; default `ctangle'. |
| |
| `RM' |
| Command to remove a file; default `rm -f'. |
| |
| Here is a table of variables whose values are additional arguments |
| for the programs above. The default values for all of these is the |
| empty string, unless otherwise noted. |
| |
| `ARFLAGS' |
| Flags to give the archive-maintaining program; default `rv'. |
| |
| `ASFLAGS' |
| Extra flags to give to the assembler (when explicitly invoked on a |
| `.s' or `.S' file). |
| |
| `CFLAGS' |
| Extra flags to give to the C compiler. |
| |
| `CXXFLAGS' |
| Extra flags to give to the C++ compiler. |
| |
| `COFLAGS' |
| Extra flags to give to the RCS `co' program. |
| |
| `CPPFLAGS' |
| Extra flags to give to the C preprocessor and programs that use it |
| (the C and Fortran compilers). |
| |
| `FFLAGS' |
| Extra flags to give to the Fortran compiler. |
| |
| `GFLAGS' |
| Extra flags to give to the SCCS `get' program. |
| |
| `LDFLAGS' |
| Extra flags to give to compilers when they are supposed to invoke |
| the linker, `ld', such as `-L'. Libraries (`-lfoo') should be |
| added to the `LDLIBS' variable instead. |
| |
| `LDLIBS' |
| Library flags or names given to compilers when they are supposed to |
| invoke the linker, `ld'. `LOADLIBES' is a deprecated (but still |
| supported) alternative to `LDLIBS'. Non-library linker flags, |
| such as `-L', should go in the `LDFLAGS' variable. |
| |
| `LFLAGS' |
| Extra flags to give to Lex. |
| |
| `YFLAGS' |
| Extra flags to give to Yacc. |
| |
| `PFLAGS' |
| Extra flags to give to the Pascal compiler. |
| |
| `RFLAGS' |
| Extra flags to give to the Fortran compiler for Ratfor programs. |
| |
| `LINTFLAGS' |
| Extra flags to give to lint. |
| |
| |
| File: make.info, Node: Chained Rules, Next: Pattern Rules, Prev: Implicit Variables, Up: Implicit Rules |
| |
| 10.4 Chains of Implicit Rules |
| ============================= |
| |
| Sometimes a file can be made by a sequence of implicit rules. For |
| example, a file `N.o' could be made from `N.y' by running first Yacc |
| and then `cc'. Such a sequence is called a "chain". |
| |
| If the file `N.c' exists, or is mentioned in the makefile, no |
| special searching is required: `make' finds that the object file can be |
| made by C compilation from `N.c'; later on, when considering how to |
| make `N.c', the rule for running Yacc is used. Ultimately both `N.c' |
| and `N.o' are updated. |
| |
| However, even if `N.c' does not exist and is not mentioned, `make' |
| knows how to envision it as the missing link between `N.o' and `N.y'! |
| In this case, `N.c' is called an "intermediate file". Once `make' has |
| decided to use the intermediate file, it is entered in the data base as |
| if it had been mentioned in the makefile, along with the implicit rule |
| that says how to create it. |
| |
| Intermediate files are remade using their rules just like all other |
| files. But intermediate files are treated differently in two ways. |
| |
| The first difference is what happens if the intermediate file does |
| not exist. If an ordinary file B does not exist, and `make' considers |
| a target that depends on B, it invariably creates B and then updates |
| the target from B. But if B is an intermediate file, then `make' can |
| leave well enough alone. It won't bother updating B, or the ultimate |
| target, unless some prerequisite of B is newer than that target or |
| there is some other reason to update that target. |
| |
| The second difference is that if `make' _does_ create B in order to |
| update something else, it deletes B later on after it is no longer |
| needed. Therefore, an intermediate file which did not exist before |
| `make' also does not exist after `make'. `make' reports the deletion |
| to you by printing a `rm -f' command showing which file it is deleting. |
| |
| Ordinarily, a file cannot be intermediate if it is mentioned in the |
| makefile as a target or prerequisite. However, you can explicitly mark |
| a file as intermediate by listing it as a prerequisite of the special |
| target `.INTERMEDIATE'. This takes effect even if the file is mentioned |
| explicitly in some other way. |
| |
| You can prevent automatic deletion of an intermediate file by |
| marking it as a "secondary" file. To do this, list it as a |
| prerequisite of the special target `.SECONDARY'. When a file is |
| secondary, `make' will not create the file merely because it does not |
| already exist, but `make' does not automatically delete the file. |
| Marking a file as secondary also marks it as intermediate. |
| |
| You can list the target pattern of an implicit rule (such as `%.o') |
| as a prerequisite of the special target `.PRECIOUS' to preserve |
| intermediate files made by implicit rules whose target patterns match |
| that file's name; see *Note Interrupts::. |
| |
| A chain can involve more than two implicit rules. For example, it is |
| possible to make a file `foo' from `RCS/foo.y,v' by running RCS, Yacc |
| and `cc'. Then both `foo.y' and `foo.c' are intermediate files that |
| are deleted at the end. |
| |
| No single implicit rule can appear more than once in a chain. This |
| means that `make' will not even consider such a ridiculous thing as |
| making `foo' from `foo.o.o' by running the linker twice. This |
| constraint has the added benefit of preventing any infinite loop in the |
| search for an implicit rule chain. |
| |
| There are some special implicit rules to optimize certain cases that |
| would otherwise be handled by rule chains. For example, making `foo' |
| from `foo.c' could be handled by compiling and linking with separate |
| chained rules, using `foo.o' as an intermediate file. But what |
| actually happens is that a special rule for this case does the |
| compilation and linking with a single `cc' command. The optimized rule |
| is used in preference to the step-by-step chain because it comes |
| earlier in the ordering of rules. |
| |
| Finally, for performance reasons `make' will not consider |
| non-terminal match-anything rules (i.e., `%:') when searching for a |
| rule to build a prerequisite of an implicit rule (*note Match-Anything |
| Rules::). |
| |
| |
| File: make.info, Node: Pattern Rules, Next: Last Resort, Prev: Chained Rules, Up: Implicit Rules |
| |
| 10.5 Defining and Redefining Pattern Rules |
| ========================================== |
| |
| You define an implicit rule by writing a "pattern rule". A pattern |
| rule looks like an ordinary rule, except that its target contains the |
| character `%' (exactly one of them). The target is considered a |
| pattern for matching file names; the `%' can match any nonempty |
| substring, while other characters match only themselves. The |
| prerequisites likewise use `%' to show how their names relate to the |
| target name. |
| |
| Thus, a pattern rule `%.o : %.c' says how to make any file `STEM.o' |
| from another file `STEM.c'. |
| |
| Note that expansion using `%' in pattern rules occurs *after* any |
| variable or function expansions, which take place when the makefile is |
| read. *Note How to Use Variables: Using Variables, and *Note Functions |
| for Transforming Text: Functions. |
| |
| * Menu: |
| |
| * Pattern Intro:: An introduction to pattern rules. |
| * Pattern Examples:: Examples of pattern rules. |
| * Automatic Variables:: How to use automatic variables in the |
| recipe of implicit rules. |
| * Pattern Match:: How patterns match. |
| * Match-Anything Rules:: Precautions you should take prior to |
| defining rules that can match any |
| target file whatever. |
| * Canceling Rules:: How to override or cancel built-in rules. |
| |
| |
| File: make.info, Node: Pattern Intro, Next: Pattern Examples, Prev: Pattern Rules, Up: Pattern Rules |
| |
| 10.5.1 Introduction to Pattern Rules |
| ------------------------------------ |
| |
| A pattern rule contains the character `%' (exactly one of them) in the |
| target; otherwise, it looks exactly like an ordinary rule. The target |
| is a pattern for matching file names; the `%' matches any nonempty |
| substring, while other characters match only themselves. |
| |
| For example, `%.c' as a pattern matches any file name that ends in |
| `.c'. `s.%.c' as a pattern matches any file name that starts with |
| `s.', ends in `.c' and is at least five characters long. (There must |
| be at least one character to match the `%'.) The substring that the |
| `%' matches is called the "stem". |
| |
| `%' in a prerequisite of a pattern rule stands for the same stem |
| that was matched by the `%' in the target. In order for the pattern |
| rule to apply, its target pattern must match the file name under |
| consideration and all of its prerequisites (after pattern substitution) |
| must name files that exist or can be made. These files become |
| prerequisites of the target. |
| |
| Thus, a rule of the form |
| |
| %.o : %.c ; RECIPE... |
| |
| specifies how to make a file `N.o', with another file `N.c' as its |
| prerequisite, provided that `N.c' exists or can be made. |
| |
| There may also be prerequisites that do not use `%'; such a |
| prerequisite attaches to every file made by this pattern rule. These |
| unvarying prerequisites are useful occasionally. |
| |
| A pattern rule need not have any prerequisites that contain `%', or |
| in fact any prerequisites at all. Such a rule is effectively a general |
| wildcard. It provides a way to make any file that matches the target |
| pattern. *Note Last Resort::. |
| |
| More than one pattern rule may match a target. In this case `make' |
| will choose the "best fit" rule. *Note How Patterns Match: Pattern |
| Match. |
| |
| Pattern rules may have more than one target; however, every target |
| must contain a `%' character. Pattern rules are always treated as |
| grouped targets (*note Multiple Targets in a Rule: Multiple Targets.) |
| regardless of whether they use the `:' or `&:' separator. |
| |
| |
| File: make.info, Node: Pattern Examples, Next: Automatic Variables, Prev: Pattern Intro, Up: Pattern Rules |
| |
| 10.5.2 Pattern Rule Examples |
| ---------------------------- |
| |
| Here are some examples of pattern rules actually predefined in `make'. |
| First, the rule that compiles `.c' files into `.o' files: |
| |
| %.o : %.c |
| $(CC) -c $(CFLAGS) $(CPPFLAGS) $< -o $@ |
| |
| defines a rule that can make any file `X.o' from `X.c'. The recipe |
| uses the automatic variables `$@' and `$<' to substitute the names of |
| the target file and the source file in each case where the rule applies |
| (*note Automatic Variables::). |
| |
| Here is a second built-in rule: |
| |
| % :: RCS/%,v |
| $(CO) $(COFLAGS) $< |
| |
| defines a rule that can make any file `X' whatsoever from a |
| corresponding file `X,v' in the sub-directory `RCS'. Since the target |
| is `%', this rule will apply to any file whatever, provided the |
| appropriate prerequisite file exists. The double colon makes the rule |
| "terminal", which means that its prerequisite may not be an intermediate |
| file (*note Match-Anything Pattern Rules: Match-Anything Rules.). |
| |
| This pattern rule has two targets: |
| |
| %.tab.c %.tab.h: %.y |
| bison -d $< |
| |
| This tells `make' that the recipe `bison -d X.y' will make both |
| `X.tab.c' and `X.tab.h'. If the file `foo' depends on the files |
| `parse.tab.o' and `scan.o' and the file `scan.o' depends on the file |
| `parse.tab.h', when `parse.y' is changed, the recipe `bison -d parse.y' |
| will be executed only once, and the prerequisites of both `parse.tab.o' |
| and `scan.o' will be satisfied. (Presumably the file `parse.tab.o' |
| will be recompiled from `parse.tab.c' and the file `scan.o' from |
| `scan.c', while `foo' is linked from `parse.tab.o', `scan.o', and its |
| other prerequisites, and it will execute happily ever after.) |
| |
| |
| File: make.info, Node: Automatic Variables, Next: Pattern Match, Prev: Pattern Examples, Up: Pattern Rules |
| |
| 10.5.3 Automatic Variables |
| -------------------------- |
| |
| Suppose you are writing a pattern rule to compile a `.c' file into a |
| `.o' file: how do you write the `cc' command so that it operates on the |
| right source file name? You cannot write the name in the recipe, |
| because the name is different each time the implicit rule is applied. |
| |
| What you do is use a special feature of `make', the "automatic |
| variables". These variables have values computed afresh for each rule |
| that is executed, based on the target and prerequisites of the rule. |
| In this example, you would use `$@' for the object file name and `$<' |
| for the source file name. |
| |
| It's very important that you recognize the limited scope in which |
| automatic variable values are available: they only have values within |
| the recipe. In particular, you cannot use them anywhere within the |
| target list of a rule; they have no value there and will expand to the |
| empty string. Also, they cannot be accessed directly within the |
| prerequisite list of a rule. A common mistake is attempting to use |
| `$@' within the prerequisites list; this will not work. However, there |
| is a special feature of GNU `make', secondary expansion (*note |
| Secondary Expansion::), which will allow automatic variable values to |
| be used in prerequisite lists. |
| |
| Here is a table of automatic variables: |
| |
| `$@' |
| The file name of the target of the rule. If the target is an |
| archive member, then `$@' is the name of the archive file. In a |
| pattern rule that has multiple targets (*note Introduction to |
| Pattern Rules: Pattern Intro.), `$@' is the name of whichever |
| target caused the rule's recipe to be run. |
| |
| `$%' |
| The target member name, when the target is an archive member. |
| *Note Archives::. For example, if the target is `foo.a(bar.o)' |
| then `$%' is `bar.o' and `$@' is `foo.a'. `$%' is empty when the |
| target is not an archive member. |
| |
| `$<' |
| The name of the first prerequisite. If the target got its recipe |
| from an implicit rule, this will be the first prerequisite added |
| by the implicit rule (*note Implicit Rules::). |
| |
| `$?' |
| The names of all the prerequisites that are newer than the target, |
| with spaces between them. If the target does not exist, all |
| prerequisites will be included. For prerequisites which are |
| archive members, only the named member is used (*note Archives::). |
| |
| `$^' |
| The names of all the prerequisites, with spaces between them. For |
| prerequisites which are archive members, only the named member is |
| used (*note Archives::). A target has only one prerequisite on |
| each other file it depends on, no matter how many times each file |
| is listed as a prerequisite. So if you list a prerequisite more |
| than once for a target, the value of `$^' contains just one copy |
| of the name. This list does *not* contain any of the order-only |
| prerequisites; for those see the `$|' variable, below. |
| |
| `$+' |
| This is like `$^', but prerequisites listed more than once are |
| duplicated in the order they were listed in the makefile. This is |
| primarily useful for use in linking commands where it is |
| meaningful to repeat library file names in a particular order. |
| |
| `$|' |
| The names of all the order-only prerequisites, with spaces between |
| them. |
| |
| `$*' |
| The stem with which an implicit rule matches (*note How Patterns |
| Match: Pattern Match.). If the target is `dir/a.foo.b' and the |
| target pattern is `a.%.b' then the stem is `dir/foo'. The stem is |
| useful for constructing names of related files. |
| |
| In a static pattern rule, the stem is part of the file name that |
| matched the `%' in the target pattern. |
| |
| In an explicit rule, there is no stem; so `$*' cannot be determined |
| in that way. Instead, if the target name ends with a recognized |
| suffix (*note Old-Fashioned Suffix Rules: Suffix Rules.), `$*' is |
| set to the target name minus the suffix. For example, if the |
| target name is `foo.c', then `$*' is set to `foo', since `.c' is a |
| suffix. GNU `make' does this bizarre thing only for compatibility |
| with other implementations of `make'. You should generally avoid |
| using `$*' except in implicit rules or static pattern rules. |
| |
| If the target name in an explicit rule does not end with a |
| recognized suffix, `$*' is set to the empty string for that rule. |
| |
| `$?' is useful even in explicit rules when you wish to operate on |
| only the prerequisites that have changed. For example, suppose that an |
| archive named `lib' is supposed to contain copies of several object |
| files. This rule copies just the changed object files into the archive: |
| |
| lib: foo.o bar.o lose.o win.o |
| ar r lib $? |
| |
| Of the variables listed above, four have values that are single file |
| names, and three have values that are lists of file names. These seven |
| have variants that get just the file's directory name or just the file |
| name within the directory. The variant variables' names are formed by |
| appending `D' or `F', respectively. The functions `dir' and `notdir' |
| can be used to obtain a similar effect (*note Functions for File Names: |
| File Name Functions.). Note, however, that the `D' variants all omit |
| the trailing slash which always appears in the output of the `dir' |
| function. Here is a table of the variants: |
| |
| `$(@D)' |
| The directory part of the file name of the target, with the |
| trailing slash removed. If the value of `$@' is `dir/foo.o' then |
| `$(@D)' is `dir'. This value is `.' if `$@' does not contain a |
| slash. |
| |
| `$(@F)' |
| The file-within-directory part of the file name of the target. If |
| the value of `$@' is `dir/foo.o' then `$(@F)' is `foo.o'. `$(@F)' |
| is equivalent to `$(notdir $@)'. |
| |
| `$(*D)' |
| `$(*F)' |
| The directory part and the file-within-directory part of the stem; |
| `dir' and `foo' in this example. |
| |
| `$(%D)' |
| `$(%F)' |
| The directory part and the file-within-directory part of the target |
| archive member name. This makes sense only for archive member |
| targets of the form `ARCHIVE(MEMBER)' and is useful only when |
| MEMBER may contain a directory name. (*Note Archive Members as |
| Targets: Archive Members.) |
| |
| `$(<D)' |
| `$(<F)' |
| The directory part and the file-within-directory part of the first |
| prerequisite. |
| |
| `$(^D)' |
| `$(^F)' |
| Lists of the directory parts and the file-within-directory parts |
| of all prerequisites. |
| |
| `$(+D)' |
| `$(+F)' |
| Lists of the directory parts and the file-within-directory parts |
| of all prerequisites, including multiple instances of duplicated |
| prerequisites. |
| |
| `$(?D)' |
| `$(?F)' |
| Lists of the directory parts and the file-within-directory parts of |
| all prerequisites that are newer than the target. |
| |
| Note that we use a special stylistic convention when we talk about |
| these automatic variables; we write "the value of `$<'", rather than |
| "the variable `<'" as we would write for ordinary variables such as |
| `objects' and `CFLAGS'. We think this convention looks more natural in |
| this special case. Please do not assume it has a deep significance; |
| `$<' refers to the variable named `<' just as `$(CFLAGS)' refers to the |
| variable named `CFLAGS'. You could just as well use `$(<)' in place of |
| `$<'. |
| |
| |
| File: make.info, Node: Pattern Match, Next: Match-Anything Rules, Prev: Automatic Variables, Up: Pattern Rules |
| |
| 10.5.4 How Patterns Match |
| ------------------------- |
| |
| A target pattern is composed of a `%' between a prefix and a suffix, |
| either or both of which may be empty. The pattern matches a file name |
| only if the file name starts with the prefix and ends with the suffix, |
| without overlap. The text between the prefix and the suffix is called |
| the "stem". Thus, when the pattern `%.o' matches the file name |
| `test.o', the stem is `test'. The pattern rule prerequisites are |
| turned into actual file names by substituting the stem for the character |
| `%'. Thus, if in the same example one of the prerequisites is written |
| as `%.c', it expands to `test.c'. |
| |
| When the target pattern does not contain a slash (and it usually does |
| not), directory names in the file names are removed from the file name |
| before it is compared with the target prefix and suffix. After the |
| comparison of the file name to the target pattern, the directory names, |
| along with the slash that ends them, are added on to the prerequisite |
| file names generated from the pattern rule's prerequisite patterns and |
| the file name. The directories are ignored only for the purpose of |
| finding an implicit rule to use, not in the application of that rule. |
| Thus, `e%t' matches the file name `src/eat', with `src/a' as the stem. |
| When prerequisites are turned into file names, the directories from the |
| stem are added at the front, while the rest of the stem is substituted |
| for the `%'. The stem `src/a' with a prerequisite pattern `c%r' gives |
| the file name `src/car'. |
| |
| A pattern rule can be used to build a given file only if there is a |
| target pattern that matches the file name, _and_ all prerequisites in |
| that rule either exist or can be built. The rules you write take |
| precedence over those that are built in. Note however, that a rule |
| whose prerequisites actually exist or are mentioned always takes |
| priority over a rule with prerequisites that must be made by chaining |
| other implicit rules. |
| |
| It is possible that more than one pattern rule will meet these |
| criteria. In that case, `make' will choose the rule with the shortest |
| stem (that is, the pattern that matches most specifically). If more |
| than one pattern rule has the shortest stem, `make' will choose the |
| first one found in the makefile. |
| |
| This algorithm results in more specific rules being preferred over |
| more generic ones; for example: |
| |
| %.o: %.c |
| $(CC) -c $(CFLAGS) $(CPPFLAGS) $< -o $@ |
| |
| %.o : %.f |
| $(COMPILE.F) $(OUTPUT_OPTION) $< |
| |
| lib/%.o: lib/%.c |
| $(CC) -fPIC -c $(CFLAGS) $(CPPFLAGS) $< -o $@ |
| |
| Given these rules and asked to build `bar.o' where both `bar.c' and |
| `bar.f' exist, `make' will choose the first rule and compile `bar.c' |
| into `bar.o'. In the same situation where `bar.c' does not exist, then |
| `make' will choose the second rule and compile `bar.f' into `bar.o'. |
| |
| If `make' is asked to build `lib/bar.o' and both `lib/bar.c' and |
| `lib/bar.f' exist, then the third rule will be chosen since the stem |
| for this rule (`bar') is shorter than the stem for the first rule |
| (`lib/bar'). If `lib/bar.c' does not exist then the third rule is not |
| eligible and the second rule will be used, even though the stem is |
| longer. |
| |
| |
| File: make.info, Node: Match-Anything Rules, Next: Canceling Rules, Prev: Pattern Match, Up: Pattern Rules |
| |
| 10.5.5 Match-Anything Pattern Rules |
| ----------------------------------- |
| |
| When a pattern rule's target is just `%', it matches any file name |
| whatever. We call these rules "match-anything" rules. They are very |
| useful, but it can take a lot of time for `make' to think about them, |
| because it must consider every such rule for each file name listed |
| either as a target or as a prerequisite. |
| |
| Suppose the makefile mentions `foo.c'. For this target, `make' |
| would have to consider making it by linking an object file `foo.c.o', |
| or by C compilation-and-linking in one step from `foo.c.c', or by |
| Pascal compilation-and-linking from `foo.c.p', and many other |
| possibilities. |
| |
| We know these possibilities are ridiculous since `foo.c' is a C |
| source file, not an executable. If `make' did consider these |
| possibilities, it would ultimately reject them, because files such as |
| `foo.c.o' and `foo.c.p' would not exist. But these possibilities are so |
| numerous that `make' would run very slowly if it had to consider them. |
| |
| To gain speed, we have put various constraints on the way `make' |
| considers match-anything rules. There are two different constraints |
| that can be applied, and each time you define a match-anything rule you |
| must choose one or the other for that rule. |
| |
| One choice is to mark the match-anything rule as "terminal" by |
| defining it with a double colon. When a rule is terminal, it does not |
| apply unless its prerequisites actually exist. Prerequisites that |
| could be made with other implicit rules are not good enough. In other |
| words, no further chaining is allowed beyond a terminal rule. |
| |
| For example, the built-in implicit rules for extracting sources from |
| RCS and SCCS files are terminal; as a result, if the file `foo.c,v' does |
| not exist, `make' will not even consider trying to make it as an |
| intermediate file from `foo.c,v.o' or from `RCS/SCCS/s.foo.c,v'. RCS |
| and SCCS files are generally ultimate source files, which should not be |
| remade from any other files; therefore, `make' can save time by not |
| looking for ways to remake them. |
| |
| If you do not mark the match-anything rule as terminal, then it is |
| non-terminal. A non-terminal match-anything rule cannot apply to a |
| prerequisite of an implicit rule, or to a file name that indicates a |
| specific type of data. A file name indicates a specific type of data |
| if some non-match-anything implicit rule target matches it. |
| |
| For example, the file name `foo.c' matches the target for the pattern |
| rule `%.c : %.y' (the rule to run Yacc). Regardless of whether this |
| rule is actually applicable (which happens only if there is a file |
| `foo.y'), the fact that its target matches is enough to prevent |
| consideration of any non-terminal match-anything rules for the file |
| `foo.c'. Thus, `make' will not even consider trying to make `foo.c' as |
| an executable file from `foo.c.o', `foo.c.c', `foo.c.p', etc. |
| |
| The motivation for this constraint is that non-terminal |
| match-anything rules are used for making files containing specific |
| types of data (such as executable files) and a file name with a |
| recognized suffix indicates some other specific type of data (such as a |
| C source file). |
| |
| Special built-in dummy pattern rules are provided solely to recognize |
| certain file names so that non-terminal match-anything rules will not be |
| considered. These dummy rules have no prerequisites and no recipes, and |
| they are ignored for all other purposes. For example, the built-in |
| implicit rule |
| |
| %.p : |
| |
| exists to make sure that Pascal source files such as `foo.p' match a |
| specific target pattern and thereby prevent time from being wasted |
| looking for `foo.p.o' or `foo.p.c'. |
| |
| Dummy pattern rules such as the one for `%.p' are made for every |
| suffix listed as valid for use in suffix rules (*note Old-Fashioned |
| Suffix Rules: Suffix Rules.). |
| |
| |
| File: make.info, Node: Canceling Rules, Prev: Match-Anything Rules, Up: Pattern Rules |
| |
| 10.5.6 Canceling Implicit Rules |
| ------------------------------- |
| |
| You can override a built-in implicit rule (or one you have defined |
| yourself) by defining a new pattern rule with the same target and |
| prerequisites, but a different recipe. When the new rule is defined, |
| the built-in one is replaced. The new rule's position in the sequence |
| of implicit rules is determined by where you write the new rule. |
| |
| You can cancel a built-in implicit rule by defining a pattern rule |
| with the same target and prerequisites, but no recipe. For example, |
| the following would cancel the rule that runs the assembler: |
| |
| %.o : %.s |
| |
| |
| File: make.info, Node: Last Resort, Next: Suffix Rules, Prev: Pattern Rules, Up: Implicit Rules |
| |
| 10.6 Defining Last-Resort Default Rules |
| ======================================= |
| |
| You can define a last-resort implicit rule by writing a terminal |
| match-anything pattern rule with no prerequisites (*note Match-Anything |
| Rules::). This is just like any other pattern rule; the only thing |
| special about it is that it will match any target. So such a rule's |
| recipe is used for all targets and prerequisites that have no recipe of |
| their own and for which no other implicit rule applies. |
| |
| For example, when testing a makefile, you might not care if the |
| source files contain real data, only that they exist. Then you might |
| do this: |
| |
| %:: |
| touch $@ |
| |
| to cause all the source files needed (as prerequisites) to be created |
| automatically. |
| |
| You can instead define a recipe to be used for targets for which |
| there are no rules at all, even ones which don't specify recipes. You |
| do this by writing a rule for the target `.DEFAULT'. Such a rule's |
| recipe is used for all prerequisites which do not appear as targets in |
| any explicit rule, and for which no implicit rule applies. Naturally, |
| there is no `.DEFAULT' rule unless you write one. |
| |
| If you use `.DEFAULT' with no recipe or prerequisites: |
| |
| .DEFAULT: |
| |
| the recipe previously stored for `.DEFAULT' is cleared. Then `make' |
| acts as if you had never defined `.DEFAULT' at all. |
| |
| If you do not want a target to get the recipe from a match-anything |
| pattern rule or `.DEFAULT', but you also do not want any recipe to be |
| run for the target, you can give it an empty recipe (*note Defining |
| Empty Recipes: Empty Recipes.). |
| |
| You can use a last-resort rule to override part of another makefile. |
| *Note Overriding Part of Another Makefile: Overriding Makefiles. |
| |
| |
| File: make.info, Node: Suffix Rules, Next: Implicit Rule Search, Prev: Last Resort, Up: Implicit Rules |
| |
| 10.7 Old-Fashioned Suffix Rules |
| =============================== |
| |
| "Suffix rules" are the old-fashioned way of defining implicit rules for |
| `make'. Suffix rules are obsolete because pattern rules are more |
| general and clearer. They are supported in GNU `make' for |
| compatibility with old makefiles. They come in two kinds: |
| "double-suffix" and "single-suffix". |
| |
| A double-suffix rule is defined by a pair of suffixes: the target |
| suffix and the source suffix. It matches any file whose name ends with |
| the target suffix. The corresponding implicit prerequisite is made by |
| replacing the target suffix with the source suffix in the file name. A |
| two-suffix rule `.c.o' (whose target and source suffixes are `.o' and |
| `.c') is equivalent to the pattern rule `%.o : %.c'. |
| |
| A single-suffix rule is defined by a single suffix, which is the |
| source suffix. It matches any file name, and the corresponding implicit |
| prerequisite name is made by appending the source suffix. A |
| single-suffix rule whose source suffix is `.c' is equivalent to the |
| pattern rule `% : %.c'. |
| |
| Suffix rule definitions are recognized by comparing each rule's |
| target against a defined list of known suffixes. When `make' sees a |
| rule whose target is a known suffix, this rule is considered a |
| single-suffix rule. When `make' sees a rule whose target is two known |
| suffixes concatenated, this rule is taken as a double-suffix rule. |
| |
| For example, `.c' and `.o' are both on the default list of known |
| suffixes. Therefore, if you define a rule whose target is `.c.o', |
| `make' takes it to be a double-suffix rule with source suffix `.c' and |
| target suffix `.o'. Here is the old-fashioned way to define the rule |
| for compiling a C source file: |
| |
| .c.o: |
| $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $< |
| |
| Suffix rules cannot have any prerequisites of their own. If they |
| have any, they are treated as normal files with funny names, not as |
| suffix rules. Thus, the rule: |
| |
| .c.o: foo.h |
| $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $< |
| |
| tells how to make the file `.c.o' from the prerequisite file `foo.h', |
| and is not at all like the pattern rule: |
| |
| %.o: %.c foo.h |
| $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $< |
| |
| which tells how to make `.o' files from `.c' files, and makes all `.o' |
| files using this pattern rule also depend on `foo.h'. |
| |
| Suffix rules with no recipe are also meaningless. They do not remove |
| previous rules as do pattern rules with no recipe (*note Canceling |
| Implicit Rules: Canceling Rules.). They simply enter the suffix or |
| pair of suffixes concatenated as a target in the data base. |
| |
| The known suffixes are simply the names of the prerequisites of the |
| special target `.SUFFIXES'. You can add your own suffixes by writing a |
| rule for `.SUFFIXES' that adds more prerequisites, as in: |
| |
| .SUFFIXES: .hack .win |
| |
| which adds `.hack' and `.win' to the end of the list of suffixes. |
| |
| If you wish to eliminate the default known suffixes instead of just |
| adding to them, write a rule for `.SUFFIXES' with no prerequisites. By |
| special dispensation, this eliminates all existing prerequisites of |
| `.SUFFIXES'. You can then write another rule to add the suffixes you |
| want. For example, |
| |
| .SUFFIXES: # Delete the default suffixes |
| .SUFFIXES: .c .o .h # Define our suffix list |
| |
| The `-r' or `--no-builtin-rules' flag causes the default list of |
| suffixes to be empty. |
| |
| The variable `SUFFIXES' is defined to the default list of suffixes |
| before `make' reads any makefiles. You can change the list of suffixes |
| with a rule for the special target `.SUFFIXES', but that does not alter |
| this variable. |
| |
| |
| File: make.info, Node: Implicit Rule Search, Prev: Suffix Rules, Up: Implicit Rules |
| |
| 10.8 Implicit Rule Search Algorithm |
| =================================== |
| |
| Here is the procedure `make' uses for searching for an implicit rule |
| for a target T. This procedure is followed for each double-colon rule |
| with no recipe, for each target of ordinary rules none of which have a |
| recipe, and for each prerequisite that is not the target of any rule. |
| It is also followed recursively for prerequisites that come from |
| implicit rules, in the search for a chain of rules. |
| |
| Suffix rules are not mentioned in this algorithm because suffix |
| rules are converted to equivalent pattern rules once the makefiles have |
| been read in. |
| |
| For an archive member target of the form `ARCHIVE(MEMBER)', the |
| following algorithm is run twice, first using the entire target name T, |
| and second using `(MEMBER)' as the target T if the first run found no |
| rule. |
| |
| 1. Split T into a directory part, called D, and the rest, called N. |
| For example, if T is `src/foo.o', then D is `src/' and N is |
| `foo.o'. |
| |
| 2. Make a list of all the pattern rules one of whose targets matches |
| T or N. If the target pattern contains a slash, it is matched |
| against T; otherwise, against N. |
| |
| 3. If any rule in that list is _not_ a match-anything rule, or if T |
| is a prerequisite of an implicit rule, then remove all |
| non-terminal match-anything rules from the list. |
| |
| 4. Remove from the list all rules with no recipe. |
| |
| 5. For each pattern rule in the list: |
| |
| a. Find the stem S, which is the nonempty part of T or N matched |
| by the `%' in the target pattern. |
| |
| b. Compute the prerequisite names by substituting S for `%'; if |
| the target pattern does not contain a slash, append D to the |
| front of each prerequisite name. |
| |
| c. Test whether all the prerequisites exist or ought to exist. |
| (If a file name is mentioned in the makefile as a target or |
| as an explicit prerequisite, then we say it ought to exist.) |
| |
| If all prerequisites exist or ought to exist, or there are no |
| prerequisites, then this rule applies. |
| |
| 6. If no pattern rule has been found so far, try harder. For each |
| pattern rule in the list: |
| |
| a. If the rule is terminal, ignore it and go on to the next rule. |
| |
| b. Compute the prerequisite names as before. |
| |
| c. Test whether all the prerequisites exist or ought to exist. |
| |
| d. For each prerequisite that does not exist, follow this |
| algorithm recursively to see if the prerequisite can be made |
| by an implicit rule. |
| |
| e. If all prerequisites exist, ought to exist, or can be made by |
| implicit rules, then this rule applies. |
| |
| 7. If no implicit rule applies, the rule for `.DEFAULT', if any, |
| applies. In that case, give T the same recipe that `.DEFAULT' |
| has. Otherwise, there is no recipe for T. |
| |
| Once a rule that applies has been found, for each target pattern of |
| the rule other than the one that matched T or N, the `%' in the pattern |
| is replaced with S and the resultant file name is stored until the |
| recipe to remake the target file T is executed. After the recipe is |
| executed, each of these stored file names are entered into the data |
| base and marked as having been updated and having the same update |
| status as the file T. |
| |
| When the recipe of a pattern rule is executed for T, the automatic |
| variables are set corresponding to the target and prerequisites. *Note |
| Automatic Variables::. |
| |
| |
| File: make.info, Node: Archives, Next: Extending make, Prev: Implicit Rules, Up: Top |
| |
| 11 Using `make' to Update Archive Files |
| *************************************** |
| |
| "Archive files" are files containing named sub-files called "members"; |
| they are maintained with the program `ar' and their main use is as |
| subroutine libraries for linking. |
| |
| * Menu: |
| |
| * Archive Members:: Archive members as targets. |
| * Archive Update:: The implicit rule for archive member targets. |
| * Archive Pitfalls:: Dangers to watch out for when using archives. |
| * Archive Suffix Rules:: You can write a special kind of suffix rule |
| for updating archives. |
| |
| |
| File: make.info, Node: Archive Members, Next: Archive Update, Prev: Archives, Up: Archives |
| |
| 11.1 Archive Members as Targets |
| =============================== |
| |
| An individual member of an archive file can be used as a target or |
| prerequisite in `make'. You specify the member named MEMBER in archive |
| file ARCHIVE as follows: |
| |
| ARCHIVE(MEMBER) |
| |
| This construct is available only in targets and prerequisites, not in |
| recipes! Most programs that you might use in recipes do not support |
| this syntax and cannot act directly on archive members. Only `ar' and |
| other programs specifically designed to operate on archives can do so. |
| Therefore, valid recipes to update an archive member target probably |
| must use `ar'. For example, this rule says to create a member `hack.o' |
| in archive `foolib' by copying the file `hack.o': |
| |
| foolib(hack.o) : hack.o |
| ar cr foolib hack.o |
| |
| In fact, nearly all archive member targets are updated in just this |
| way and there is an implicit rule to do it for you. *Please note:* The |
| `c' flag to `ar' is required if the archive file does not already exist. |
| |
| To specify several members in the same archive, you can write all the |
| member names together between the parentheses. For example: |
| |
| foolib(hack.o kludge.o) |
| |
| is equivalent to: |
| |
| foolib(hack.o) foolib(kludge.o) |
| |
| You can also use shell-style wildcards in an archive member |
| reference. *Note Using Wildcard Characters in File Names: Wildcards. |
| For example, `foolib(*.o)' expands to all existing members of the |
| `foolib' archive whose names end in `.o'; perhaps `foolib(hack.o) |
| foolib(kludge.o)'. |
| |
| |
| File: make.info, Node: Archive Update, Next: Archive Pitfalls, Prev: Archive Members, Up: Archives |
| |
| 11.2 Implicit Rule for Archive Member Targets |
| ============================================= |
| |
| Recall that a target that looks like `A(M)' stands for the member named |
| M in the archive file A. |
| |
| When `make' looks for an implicit rule for such a target, as a |
| special feature it considers implicit rules that match `(M)', as well as |
| those that match the actual target `A(M)'. |
| |
| This causes one special rule whose target is `(%)' to match. This |
| rule updates the target `A(M)' by copying the file M into the archive. |
| For example, it will update the archive member target `foo.a(bar.o)' by |
| copying the _file_ `bar.o' into the archive `foo.a' as a _member_ named |
| `bar.o'. |
| |
| When this rule is chained with others, the result is very powerful. |
| Thus, `make "foo.a(bar.o)"' (the quotes are needed to protect the `(' |
| and `)' from being interpreted specially by the shell) in the presence |
| of a file `bar.c' is enough to cause the following recipe to be run, |
| even without a makefile: |
| |
| cc -c bar.c -o bar.o |
| ar r foo.a bar.o |
| rm -f bar.o |
| |
| Here `make' has envisioned the file `bar.o' as an intermediate file. |
| *Note Chains of Implicit Rules: Chained Rules. |
| |
| Implicit rules such as this one are written using the automatic |
| variable `$%'. *Note Automatic Variables::. |
| |
| An archive member name in an archive cannot contain a directory |
| name, but it may be useful in a makefile to pretend that it does. If |
| you write an archive member target `foo.a(dir/file.o)', `make' will |
| perform automatic updating with this recipe: |
| |
| ar r foo.a dir/file.o |
| |
| which has the effect of copying the file `dir/file.o' into a member |
| named `file.o'. In connection with such usage, the automatic variables |
| `%D' and `%F' may be useful. |
| |
| * Menu: |
| |
| * Archive Symbols:: How to update archive symbol directories. |
| |
| |
| File: make.info, Node: Archive Symbols, Prev: Archive Update, Up: Archive Update |
| |
| 11.2.1 Updating Archive Symbol Directories |
| ------------------------------------------ |
| |
| An archive file that is used as a library usually contains a special |
| member named `__.SYMDEF' that contains a directory of the external |
| symbol names defined by all the other members. After you update any |
| other members, you need to update `__.SYMDEF' so that it will summarize |
| the other members properly. This is done by running the `ranlib' |
| program: |
| |
| ranlib ARCHIVEFILE |
| |
| Normally you would put this command in the rule for the archive file, |
| and make all the members of the archive file prerequisites of that rule. |
| For example, |
| |
| libfoo.a: libfoo.a(x.o) libfoo.a(y.o) ... |
| ranlib libfoo.a |
| |
| The effect of this is to update archive members `x.o', `y.o', etc., and |
| then update the symbol directory member `__.SYMDEF' by running |
| `ranlib'. The rules for updating the members are not shown here; most |
| likely you can omit them and use the implicit rule which copies files |
| into the archive, as described in the preceding section. |
| |
| This is not necessary when using the GNU `ar' program, which updates |
| the `__.SYMDEF' member automatically. |
| |
| |
| File: make.info, Node: Archive Pitfalls, Next: Archive Suffix Rules, Prev: Archive Update, Up: Archives |
| |
| 11.3 Dangers When Using Archives |
| ================================ |
| |
| It is important to be careful when using parallel execution (the `-j' |
| switch; *note Parallel Execution: Parallel.) and archives. If multiple |
| `ar' commands run at the same time on the same archive file, they will |
| not know about each other and can corrupt the file. |
| |
| Possibly a future version of `make' will provide a mechanism to |
| circumvent this problem by serializing all recipes that operate on the |
| same archive file. But for the time being, you must either write your |
| makefiles to avoid this problem in some other way, or not use `-j'. |
| |
| |
| File: make.info, Node: Archive Suffix Rules, Prev: Archive Pitfalls, Up: Archives |
| |
| 11.4 Suffix Rules for Archive Files |
| =================================== |
| |
| You can write a special kind of suffix rule for dealing with archive |
| files. *Note Suffix Rules::, for a full explanation of suffix rules. |
| Archive suffix rules are obsolete in GNU `make', because pattern rules |
| for archives are a more general mechanism (*note Archive Update::). |
| But they are retained for compatibility with other `make's. |
| |
| To write a suffix rule for archives, you simply write a suffix rule |
| using the target suffix `.a' (the usual suffix for archive files). For |
| example, here is the old-fashioned suffix rule to update a library |
| archive from C source files: |
| |
| .c.a: |
| $(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $*.o |
| $(AR) r $@ $*.o |
| $(RM) $*.o |
| |
| This works just as if you had written the pattern rule: |
| |
| (%.o): %.c |
| $(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $*.o |
| $(AR) r $@ $*.o |
| $(RM) $*.o |
| |
| In fact, this is just what `make' does when it sees a suffix rule |
| with `.a' as the target suffix. Any double-suffix rule `.X.a' is |
| converted to a pattern rule with the target pattern `(%.o)' and a |
| prerequisite pattern of `%.X'. |
| |
| Since you might want to use `.a' as the suffix for some other kind |
| of file, `make' also converts archive suffix rules to pattern rules in |
| the normal way (*note Suffix Rules::). Thus a double-suffix rule |
| `.X.a' produces two pattern rules: `(%.o): %.X' and `%.a: %.X'. |
| |
| |
| File: make.info, Node: Extending make, Next: Integrating make, Prev: Archives, Up: Top |
| |
| 12 Extending GNU `make' |
| *********************** |
| |
| GNU `make' provides many advanced capabilities, including many useful |
| functions. However, it does not contain a complete programming |
| language and so it has limitations. Sometimes these limitations can be |
| overcome through use of the `shell' function to invoke a separate |
| program, although this can be inefficient. |
| |
| In cases where the built-in capabilities of GNU `make' are |
| insufficient to your requirements there are two options for extending |
| `make'. On systems where it's provided, you can utilize GNU Guile as |
| an embedded scripting language (*note GNU Guile Integration: Guile |
| Integration.). On systems which support dynamically loadable objects, |
| you can write your own extension in any language (which can be compiled |
| into such an object) and load it to provide extended capabilities |
| (*note The `load' Directive: load Directive.). |
| |
| * Menu: |
| |
| * Guile Integration:: Using Guile as an embedded scripting language. |
| * Loading Objects:: Loading dynamic objects as extensions. |
| |
| |
| File: make.info, Node: Guile Integration, Next: Loading Objects, Prev: Extending make, Up: Extending make |
| |
| 12.1 GNU Guile Integration |
| ========================== |
| |
| GNU `make' may be built with support for GNU Guile as an embedded |
| extension language. Guile implements the Scheme language. A review of |
| GNU Guile and the Scheme language and its features is beyond the scope |
| of this manual: see the documentation for GNU Guile and Scheme. |
| |
| You can determine if `make' contains support for Guile by examining |
| the `.FEATURES' variable; it will contain the word GUILE if Guile |
| support is available. |
| |
| The Guile integration provides one new `make' function: `guile'. |
| The `guile' function takes one argument which is first expanded by |
| `make' in the normal fashion, then passed to the GNU Guile evaluator. |
| The result of the evaluator is converted into a string and used as the |
| expansion of the `guile' function in the makefile. |
| |
| In addition, GNU `make' exposes Guile procedures for use in Guile |
| scripts. |
| |
| * Menu: |
| |
| * Guile Types:: Converting Guile types to `make' strings. |
| * Guile Interface:: Invoking `make' functions from Guile. |
| * Guile Example:: Example using Guile in `make'. |
| |
| |
| File: make.info, Node: Guile Types, Next: Guile Interface, Prev: Guile Integration, Up: Guile Integration |
| |
| 12.1.1 Conversion of Guile Types |
| -------------------------------- |
| |
| There is only one "data type" in `make': a string. GNU Guile, on the |
| other hand, provides a rich variety of different data types. An |
| important aspect of the interface between `make' and GNU Guile is the |
| conversion of Guile data types into `make' strings. |
| |
| This conversion is relevant in two places: when a makefile invokes |
| the `guile' function to evaluate a Guile expression, the result of that |
| evaluation must be converted into a make string so it can be further |
| evaluated by `make'. And secondly, when a Guile script invokes one of |
| the procedures exported by `make' the argument provided to the |
| procedure must be converted into a string. |
| |
| The conversion of Guile types into `make' strings is as below: |
| |
| `#f' |
| False is converted into the empty string: in `make' conditionals |
| the empty string is considered false. |
| |
| `#t' |
| True is converted to the string `#t': in `make' conditionals any |
| non-empty string is considered true. |
| |
| `symbol' |
| |
| `number' |
| A symbol or number is converted into the string representation of |
| that symbol or number. |
| |
| `character' |
| A printable character is converted to the same character. |
| |
| `string' |
| A string containing only printable characters is converted to the |
| same string. |
| |
| `list' |
| A list is converted recursively according to the above rules. This |
| implies that any structured list will be flattened (that is, a |
| result of `'(a b (c d) e)' will be converted to the `make' string |
| `a b c d e'). |
| |
| `other' |
| Any other Guile type results in an error. In future versions of |
| `make', other Guile types may be converted. |
| |
| |
| The translation of `#f' (to the empty string) and `#t' (to the |
| non-empty string `#t') is designed to allow you to use Guile boolean |
| results directly as `make' boolean conditions. For example: |
| |
| $(if $(guile (access? "myfile" R_OK)),$(info myfile exists)) |
| |
| As a consequence of these conversion rules you must consider the |
| result of your Guile script, as that result will be converted into a |
| string and parsed by `make'. If there is no natural result for the |
| script (that is, the script exists solely for its side-effects), you |
| should add `#f' as the final expression in order to avoid syntax errors |
| in your makefile. |
| |
| |
| File: make.info, Node: Guile Interface, Next: Guile Example, Prev: Guile Types, Up: Guile Integration |
| |
| 12.1.2 Interfaces from Guile to `make' |
| -------------------------------------- |
| |
| In addition to the `guile' function available in makefiles, `make' |
| exposes some procedures for use in your Guile scripts. At startup |
| `make' creates a new Guile module, `gnu make', and exports these |
| procedures as public interfaces from that module: |
| |
| `gmk-expand' |
| This procedure takes a single argument which is converted into a |
| string. The string is expanded by `make' using normal `make' |
| expansion rules. The result of the expansion is converted into a |
| Guile string and provided as the result of the procedure. |
| |
| `gmk-eval' |
| This procedure takes a single argument which is converted into a |
| string. The string is evaluated by `make' as if it were a |
| makefile. This is the same capability available via the `eval' |
| function (*note Eval Function::). The result of the `gmk-eval' |
| procedure is always the empty string. |
| |
| Note that `gmk-eval' is not quite the same as using `gmk-expand' |
| with the `eval' function: in the latter case the evaluated string |
| will be expanded _twice_; first by `gmk-expand', then again by the |
| `eval' function. |
| |
| |
| |
| File: make.info, Node: Guile Example, Prev: Guile Interface, Up: Guile Integration |
| |
| 12.1.3 Example Using Guile in `make' |
| ------------------------------------ |
| |
| Here is a very simple example using GNU Guile to manage writing to a |
| file. These Guile procedures simply open a file, allow writing to the |
| file (one string per line), and close the file. Note that because we |
| cannot store complex values such as Guile ports in `make' variables, |
| we'll keep the port as a global variable in the Guile interpreter. |
| |
| You can create Guile functions easily using `define'/`endef' to |
| create a Guile script, then use the `guile' function to internalize it: |
| |
| define GUILEIO |
| ;; A simple Guile IO library for GNU make |
| |
| (define MKPORT #f) |
| |
| (define (mkopen name mode) |
| (set! MKPORT (open-file name mode)) |
| #f) |
| |
| (define (mkwrite s) |
| (display s MKPORT) |
| (newline MKPORT) |
| #f) |
| |
| (define (mkclose) |
| (close-port MKPORT) |
| #f) |
| |
| #f |
| endef |
| |
| # Internalize the Guile IO functions |
| $(guile $(GUILEIO)) |
| |
| If you have a significant amount of Guile support code, you might |
| consider keeping it in a different file (e.g., `guileio.scm') and then |
| loading it in your makefile using the `guile' function: |
| |
| $(guile (load "guileio.scm")) |
| |
| An advantage to this method is that when editing `guileio.scm', your |
| editor will understand that this file contains Scheme syntax rather |
| than makefile syntax. |
| |
| Now you can use these Guile functions to create files. Suppose you |
| need to operate on a very large list, which cannot fit on the command |
| line, but the utility you're using accepts the list as input as well: |
| |
| prog: $(PREREQS) |
| @$(guile (mkopen "tmp.out" "w")) \ |
| $(foreach X,$^,$(guile (mkwrite "$(X)"))) \ |
| $(guile (mkclose)) |
| $(LINK) < tmp.out |
| |
| A more comprehensive suite of file manipulation procedures is |
| possible of course. You could, for example, maintain multiple output |
| files at the same time by choosing a symbol for each one and using it |
| as the key to a hash table, where the value is a port, then returning |
| the symbol to be stored in a `make' variable. |
| |
| |
| File: make.info, Node: Loading Objects, Prev: Guile Integration, Up: Extending make |
| |
| 12.2 Loading Dynamic Objects |
| ============================ |
| |
| Warning: The `load' directive and extension capability is |
| considered a "technology preview" in this release of GNU make. We |
| encourage you to experiment with this feature and we appreciate |
| any feedback on it. However we cannot guarantee to maintain |
| backward-compatibility in the next release. Consider using GNU |
| Guile instead for extending GNU make (*note The `guile' Function: |
| Guile Function.). |
| |
| Many operating systems provide a facility for dynamically loading |
| compiled objects. If your system provides this facility, GNU `make' |
| can make use of it to load dynamic objects at runtime, providing new |
| capabilities which may then be invoked by your makefile. |
| |
| The `load' directive is used to load a dynamic object. Once the |
| object is loaded, a "setup" function will be invoked to allow the |
| object to initialize itself and register new facilities with GNU |
| `make'. A dynamic object might include new `make' functions, for |
| example, and the "setup" function would register them with GNU `make''s |
| function handling system. |
| |
| * Menu: |
| |
| * load Directive:: Loading dynamic objects as extensions. |
| * Remaking Loaded Objects:: How loaded objects get remade. |
| * Loaded Object API:: Programmatic interface for loaded objects. |
| * Loaded Object Example:: Example of a loaded object |
| |
| |
| File: make.info, Node: load Directive, Next: Remaking Loaded Objects, Prev: Loading Objects, Up: Loading Objects |
| |
| 12.2.1 The `load' Directive |
| --------------------------- |
| |
| Objects are loaded into GNU `make' by placing the `load' directive into |
| your makefile. The syntax of the `load' directive is as follows: |
| |
| load OBJECT-FILE ... |
| |
| or: |
| |
| load OBJECT-FILE(SYMBOL-NAME) ... |
| |
| The file OBJECT-FILE is dynamically loaded by GNU `make'. If |
| OBJECT-FILE does not include a directory path then it is first looked |
| for in the current directory. If it is not found there, or a directory |
| path is included, then system-specific paths will be searched. If the |
| load fails for any reason, `make' will print a message and exit. |
| |
| If the load succeeds `make' will invoke an initializing function. |
| |
| If SYMBOL-NAME is provided, it will be used as the name of the |
| initializing function. |
| |
| If no SYMBOL-NAME is provided, the initializing function name is |
| created by taking the base file name of OBJECT-FILE, up to the first |
| character which is not a valid symbol name character (alphanumerics and |
| underscores are valid symbol name characters). To this prefix will be |
| appended the suffix `_gmk_setup'. |
| |
| More than one object file may be loaded with a single `load' |
| directive, and both forms of `load' arguments may be used in the same |
| directive. |
| |
| The initializing function will be provided the file name and line |
| number of the invocation of the `load' operation. It should return a |
| value of type `int', which must be `0' on failure and non-`0' on |
| success. If the return value is `-1', then GNU make will _not_ attempt |
| to rebuild the object file (*note How Loaded Objects Are Remade: |
| Remaking Loaded Objects.). |
| |
| For example: |
| |
| load ../mk_funcs.so |
| |
| will load the dynamic object `../mk_funcs.so'. After the object is |
| loaded, `make' will invoke the function (assumed to be defined by the |
| shared object) `mk_funcs_gmk_setup'. |
| |
| On the other hand: |
| |
| load ../mk_funcs.so(init_mk_func) |
| |
| will load the dynamic object `../mk_funcs.so'. After the object is |
| loaded, `make' will invoke the function `init_mk_func'. |
| |
| Regardless of how many times an object file appears in a `load' |
| directive, it will only be loaded (and its setup function will only be |
| invoked) once. |
| |
| After an object has been successfully loaded, its file name is |
| appended to the `.LOADED' variable. |
| |
| If you would prefer that failure to load a dynamic object not be |
| reported as an error, you can use the `-load' directive instead of |
| `load'. GNU `make' will not fail and no message will be generated if |
| an object fails to load. The failed object is not added to the |
| `.LOADED' variable, which can then be consulted to determine if the |
| load was successful. |
| |
| |
| File: make.info, Node: Remaking Loaded Objects, Next: Loaded Object API, Prev: load Directive, Up: Loading Objects |
| |
| 12.2.2 How Loaded Objects Are Remade |
| ------------------------------------ |
| |
| Loaded objects undergo the same re-make procedure as makefiles (*note |
| How Makefiles Are Remade: Remaking Makefiles.). If any loaded object |
| is recreated, then `make' will start from scratch and re-read all the |
| makefiles, and reload the object files again. It is not necessary for |
| the loaded object to do anything special to support this. |
| |
| It's up to the makefile author to provide the rules needed for |
| rebuilding the loaded object. |
| |
| |
| File: make.info, Node: Loaded Object API, Next: Loaded Object Example, Prev: Remaking Loaded Objects, Up: Loading Objects |
| |
| 12.2.3 Loaded Object Interface |
| ------------------------------ |
| |
| Warning: For this feature to be useful your extensions will need |
| to invoke various functions internal to GNU `make'. The |
| programming interfaces provided in this release should not be |
| considered stable: functions may be added, removed, or change |
| calling signatures or implementations in future versions of GNU |
| `make'. |
| |
| To be useful, loaded objects must be able to interact with GNU `make'. |
| This interaction includes both interfaces the loaded object provides to |
| makefiles and also interfaces `make' provides to the loaded object to |
| manipulate `make''s operation. |
| |
| The interface between loaded objects and `make' is defined by the |
| `gnumake.h' C header file. All loaded objects written in C should |
| include this header file. Any loaded object not written in C will need |
| to implement the interface defined in this header file. |
| |
| Typically, a loaded object will register one or more new GNU `make' |
| functions using the `gmk_add_function' routine from within its setup |
| function. The implementations of these `make' functions may make use |
| of the `gmk_expand' and `gmk_eval' routines to perform their tasks, |
| then optionally return a string as the result of the function expansion. |
| |
| Loaded Object Licensing |
| ....................... |
| |
| Every dynamic extension should define the global symbol |
| `plugin_is_GPL_compatible' to assert that it has been licensed under a |
| GPL-compatible license. If this symbol does not exist, `make' emits a |
| fatal error and exits when it tries to load your extension. |
| |
| The declared type of the symbol should be `int'. It does not need to |
| be in any allocated section, though. The code merely asserts that the |
| symbol exists in the global scope. Something like this is enough: |
| |
| int plugin_is_GPL_compatible; |
| |
| Data Structures |
| ............... |
| |
| `gmk_floc' |
| This structure represents a filename/location pair. It is provided |
| when defining items, so GNU `make' can inform the user later where |
| the definition occurred if necessary. |
| |
| Registering Functions |
| ..................... |
| |
| There is currently one way for makefiles to invoke operations provided |
| by the loaded object: through the `make' function call interface. A |
| loaded object can register one or more new functions which may then be |
| invoked from within the makefile in the same way as any other function. |
| |
| Use `gmk_add_function' to create a new `make' function. Its |
| arguments are as follows: |
| |
| `name' |
| The function name. This is what the makefile should use to invoke |
| the function. The name must be between 1 and 255 characters long |
| and it may only contain alphanumeric, period (`.'), dash (`-'), and |
| underscore (`_') characters. It may not begin with a period. |
| |
| `func_ptr' |
| A pointer to a function that `make' will invoke when it expands |
| the function in a makefile. This function must be defined by the |
| loaded object. |
| |
| `min_args' |
| The minimum number of arguments the function will accept. Must be |
| between 0 and 255. GNU `make' will check this and fail before |
| invoking `func_ptr' if the function was invoked with too few |
| arguments. |
| |
| `max_args' |
| The maximum number of arguments the function will accept. Must be |
| between 0 and 255. GNU `make' will check this and fail before |
| invoking `func_ptr' if the function was invoked with too few |
| arguments. If the value is 0, then any number of arguments is |
| accepted. If the value is greater than 0, then it must be greater |
| than or equal to `min_args'. |
| |
| `flags' |
| Flags that specify how this function will operate; the desired |
| flags should be OR'd together. If the `GMK_FUNC_NOEXPAND' flag is |
| given then the function arguments will not be expanded before the |
| function is called; otherwise they will be expanded first. |
| |
| Registered Function Interface |
| ............................. |
| |
| A function registered with `make' must match the `gmk_func_ptr' type. |
| It will be invoked with three parameters: `name' (the name of the |
| function), `argc' (the number of arguments to the function), and `argv' |
| (an array of pointers to arguments to the function). The last pointer |
| (that is, `argv[argc]') will be null (`0'). |
| |
| The return value of the function is the result of expanding the |
| function. If the function expands to nothing the return value may be |
| null. Otherwise, it must be a pointer to a string created with |
| `gmk_alloc'. Once the function returns, `make' owns this string and |
| will free it when appropriate; it cannot be accessed by the loaded |
| object. |
| |
| GNU `make' Facilities |
| ..................... |
| |
| There are some facilities exported by GNU `make' for use by loaded |
| objects. Typically these would be run from within the setup function |
| and/or the functions registered via `gmk_add_function', to retrieve or |
| modify the data `make' works with. |
| |
| `gmk_expand' |
| This function takes a string and expands it using `make' expansion |
| rules. The result of the expansion is returned in a |
| nil-terminated string buffer. The caller is responsible for |
| calling `gmk_free' with a pointer to the returned buffer when done. |
| |
| `gmk_eval' |
| This function takes a buffer and evaluates it as a segment of |
| makefile syntax. This function can be used to define new |
| variables, new rules, etc. It is equivalent to using the `eval' |
| `make' function. |
| |
| Note that there is a difference between `gmk_eval' and calling |
| `gmk_expand' with a string using the `eval' function: in the latter |
| case the string will be expanded _twice_; once by `gmk_expand' and then |
| again by the `eval' function. Using `gmk_eval' the buffer is only |
| expanded once, at most (as it's read by the `make' parser). |
| |
| Memory Management |
| ................. |
| |
| Some systems allow for different memory management schemes. Thus you |
| should never pass memory that you've allocated directly to any `make' |
| function, nor should you attempt to directly free any memory returned |
| to you by any `make' function. Instead, use the `gmk_alloc' and |
| `gmk_free' functions. |
| |
| In particular, the string returned to `make' by a function |
| registered using `gmk_add_function' _must_ be allocated using |
| `gmk_alloc', and the string returned from the `make' `gmk_expand' |
| function _must_ be freed (when no longer needed) using `gmk_free'. |
| |
| `gmk_alloc' |
| Return a pointer to a newly-allocated buffer. This function will |
| always return a valid pointer; if not enough memory is available |
| `make' will exit. |
| |
| `gmk_free' |
| Free a buffer returned to you by `make'. Once the `gmk_free' |
| function returns the string will no longer be valid. |
| |
| |
| File: make.info, Node: Loaded Object Example, Prev: Loaded Object API, Up: Loading Objects |
| |
| 12.2.4 Example Loaded Object |
| ---------------------------- |
| |
| Let's suppose we wanted to write a new GNU `make' function that would |
| create a temporary file and return its name. We would like our |
| function to take a prefix as an argument. First we can write the |
| function in a file `mk_temp.c': |
| |
| #include <stdlib.h> |
| #include <stdlib.h> |
| #include <stdio.h> |
| #include <string.h> |
| #include <unistd.h> |
| #include <errno.h> |
| |
| #include <gnumake.h> |
| |
| int plugin_is_GPL_compatible; |
| |
| char * |
| gen_tmpfile(const char *nm, int argc, char **argv) |
| { |
| int fd; |
| |
| /* Compute the size of the filename and allocate space for it. */ |
| int len = strlen (argv[0]) + 6 + 1; |
| char *buf = gmk_alloc (len); |
| |
| strcpy (buf, argv[0]); |
| strcat (buf, "XXXXXX"); |
| |
| fd = mkstemp(buf); |
| if (fd >= 0) |
| { |
| /* Don't leak the file descriptor. */ |
| close (fd); |
| return buf; |
| } |
| |
| /* Failure. */ |
| fprintf (stderr, "mkstemp(%s) failed: %s\n", buf, strerror (errno)); |
| gmk_free (buf); |
| return NULL; |
| } |
| |
| int |
| mk_temp_gmk_setup () |
| { |
| /* Register the function with make name "mk-temp". */ |
| gmk_add_function ("mk-temp", gen_tmpfile, 1, 1, 1); |
| return 1; |
| } |
| |
| Next, we will write a makefile that can build this shared object, |
| load it, and use it: |
| |
| all: |
| @echo Temporary file: $(mk-temp tmpfile.) |
| |
| load mk_temp.so |
| |
| mk_temp.so: mk_temp.c |
| $(CC) -shared -fPIC -o $ $< |
| |
| On MS-Windows, due to peculiarities of how shared objects are |
| produced, the compiler needs to scan the "import library" produced when |
| building `make', typically called `libgnumake-VERSION.dll.a', where |
| VERSION is the version of the load object API. So the recipe to |
| produce a shared object will look on Windows like this (assuming the |
| API version is 1): |
| |
| mk_temp.dll: mk_temp.c |
| $(CC) -shared -o $ $< -lgnumake-1 |
| |
| Now when you run `make' you'll see something like: |
| |
| $ make |
| cc -shared -fPIC -o mk_temp.so mk_temp.c |
| Temporary filename: tmpfile.A7JEwd |
| |
| |
| File: make.info, Node: Integrating make, Next: Features, Prev: Extending make, Up: Top |
| |
| 13 Integrating GNU `make' |
| ************************* |
| |
| GNU `make' is often one component in a larger system of tools, |
| including integrated development environments, compiler toolchains, and |
| others. The role of `make' is to start commands and determine whether |
| they succeeded or not: no special integration is needed to accomplish |
| that. However, sometimes it is convenient to bind `make' more tightly |
| with other parts of the system, both higher-level (tools that invoke |
| `make') and lower-level (tools that `make' invokes). |
| |
| * Menu: |
| |
| * Job Slots:: Share job slots with GNU `make'. |
| * Terminal Output:: Control output to terminals. |
| |
| |
| File: make.info, Node: Job Slots, Next: Terminal Output, Prev: Integrating make, Up: Integrating make |
| |
| 13.1 Sharing Job Slots with GNU `make' |
| ====================================== |
| |
| GNU `make' has the ability to run multiple recipes in parallel (*note |
| Parallel Execution: Parallel.) and to cap the total number of parallel |
| jobs even across recursive invocations of `make' (*note Communicating |
| Options to a Sub-`make': Options/Recursion.). Tools that `make' |
| invokes which are also able to run multiple operations in parallel, |
| either using multiple threads or multiple processes, can be enhanced to |
| participate in GNU `make''s job management facility to ensure that the |
| total number of active threads/processes running on the system does not |
| exceed the maximum number of slots provided to GNU `make'. |
| |
| GNU `make' uses a method called the "jobserver" to control the |
| number of active jobs across recursive invocations. The actual |
| implementation of the jobserver varies across different operating |
| systems, but some fundamental aspects are always true. |
| |
| First, only command lines that `make' understands to be recursive |
| invocations of `make' (*note How the `MAKE' Variable Works: MAKE |
| Variable.) will have access to the jobserver. When writing makefiles |
| you must be sure to mark the command as recursive (most commonly by |
| prefixing the command line with the `+' indicator (*note Recursive Use |
| of `make': Recursion.). |
| |
| Second, `make' will provide information necessary for accessing the |
| jobserver through the environment to its children, in the `MAKEFLAGS' |
| environment variable. Tools which want to participate in the jobserver |
| protocol will need to parse this environment variable, as described in |
| subsequent sections. |
| |
| Third, every command `make' starts has one implicit job slot |
| reserved for it before it starts. Any tool which wants to participate |
| in the jobserver protocol should assume it can always run one job |
| without having to contact the jobserver at all. |
| |
| Finally, it's critical that tools that participate in the jobserver |
| protocol return the exact number of slots they obtained from the |
| jobserver back to the jobserver before they exit, even under error |
| conditions. Remember that the implicit job slot should *not* be |
| returned to the jobserver! Returning too few slots means that those |
| slots will be lost for the rest of the build process; returning too |
| many slots means that extra slots will be available. The top-level |
| `make' command will print an error message at the end of the build if |
| it detects an incorrect number of slots available in the jobserver. |
| |
| As an example, suppose you are implementing a linker which provides |
| for multithreaded operation. You would like to enhance the linker so |
| that if it is invoked by GNU `make' it can participate in the jobserver |
| protocol to control how many threads are used during link. First you |
| will need to modify the linker to determine if the `MAKEFLAGS' |
| environment variable is set. Next you will need to parse the value of |
| that variable to determine if the jobserver is available, and how to |
| access it. If it is available then you can access it to obtain job |
| slots controlling how much parallelism your tool can use. Once done |
| your tool must return those job slots back to the jobserver. |
| |
| * Menu: |
| |
| * POSIX Jobserver:: Using the jobserver on POSIX systems. |
| * Windows Jobserver:: Using the jobserver on Windows systems. |
| |
| |
| File: make.info, Node: POSIX Jobserver, Next: Windows Jobserver, Prev: Job Slots, Up: Job Slots |
| |
| 13.1.1 POSIX Jobserver Interaction |
| ---------------------------------- |
| |
| On POSIX systems the jobserver is implemented as a simple UNIX pipe. |
| The pipe will be pre-loaded with one single-character token for each |
| available job. To obtain an extra slot you must read a single |
| character from the jobserver pipe; to release a slot you must write a |
| single character back into the jobserver pipe. Note that the read side |
| of the jobserver pipe is set to "blocking" mode. |
| |
| To access the pipe you must parse the `MAKEFLAGS' variable and look |
| for the argument string `--jobserver-auth=R,W' where `R' and `W' are |
| non-negative integers representing file descriptors: `R' is the read |
| file descriptor and `W' is the write file descriptor. |
| |
| It's important that when you release the job slot, you write back the |
| same character you read from the pipe for that slot. Don't assume that |
| all tokens are the same character; different characters may have |
| different meanings to GNU `make'. The order is not important, since |
| `make' has no idea in what order jobs will complete anyway. |
| |
| There are various error conditions you must consider to ensure your |
| implementation is robust: |
| |
| * Usually you will have a command-line argument controlling the |
| parallel operation of your tool. Consider whether your tool |
| should detect situations where both the jobserver and the |
| command-line argument are specified, and how it should react. |
| |
| * If your tool determines that the `--jobserver-auth' option is |
| available in `MAKEFLAGS' but that the file descriptors specified |
| are closed, this means that the calling `make' process did not |
| think that your tool was a recursive `make' invocation (e.g., the |
| command line was not prefixed with a `+' character). You should |
| notify your users of this situation. |
| |
| * Your tool should also examine the first word of the `MAKEFLAGS' |
| variable and look for the character `n'. If this character is |
| present then `make' was invoked with the `-n' option and your tool |
| should stop without performing any operations. |
| |
| * Your tool should be sure to write back the tokens it read, even |
| under error conditions. This includes not only errors in your |
| tool but also outside influences such as interrupts (`SIGINT'), |
| etc. You may want to install signal handlers to manage this |
| write-back. |
| |
| |
| File: make.info, Node: Windows Jobserver, Prev: POSIX Jobserver, Up: Job Slots |
| |
| 13.1.2 Windows Jobserver Interaction |
| ------------------------------------ |
| |
| On Windows systems the jobserver is implemented as a named semaphore. |
| The semaphore will be set with an initial count equal to the number of |
| available slots; to obtain a slot you must wait on the semaphore (with |
| or without a timeout). To release a slot, release the semaphore. |
| |
| To access the semaphore you must parse the `MAKEFLAGS' variable and |
| look for the argument string `--jobserver-auth=NAME' where `NAME' is |
| the name of the named semaphore. Use this name with `OpenSemaphore' to |
| create a handle to the semaphore. |
| |
| There are various error conditions you must consider to ensure your |
| implementation is robust: |
| |
| * Usually you will have a command-line argument controlling the |
| parallel operation of your tool. Consider whether your tool |
| should detect situations where both the jobserver and the |
| command-line argument are specified, and how it should react. |
| |
| * Your tool should be sure to release the semaphore for the tokens it |
| read, even under error conditions. This includes not only errors |
| in your tool but also outside influences such as interrupts |
| (`SIGINT'), etc. You may want to install signal handlers to |
| manage this write-back. |
| |
| |
| File: make.info, Node: Terminal Output, Prev: Job Slots, Up: Integrating make |
| |
| 13.2 Synchronized Terminal Output |
| ================================= |
| |
| Normally GNU `make' will invoke all commands with access to the same |
| standard and error outputs that `make' itself was started with. A |
| number of tools will detect whether the output is a terminal or |
| not-a-terminal, and use this information to change the output style. |
| For example if the output goes to a terminal the tool may add control |
| characters that set color, or even change the location of the cursor. |
| If the output is not going to a terminal then these special control |
| characters are not emitted so that they don't corrupt log files, etc. |
| |
| The `--output-sync' (*note Output During Parallel Output: Parallel |
| Output.) option will defeat the terminal detection. When output |
| synchronization is enabled GNU `make' arranges for all command output |
| to be written to a file, so that its output can be written as a block |
| without interference from other commands. This means that all tools |
| invoked by `make' will believe that their output is not going to be |
| displayed on a terminal, even when it will be (because `make' will |
| display it there after the command is completed). |
| |
| In order to facilitate tools which would like to determine whether or |
| not their output will be displayed on a terminal, GNU `make' will set |
| the `MAKE_TERMOUT' and `MAKE_TERMERR' environment variables before |
| invoking any commands. Tools which would like to determine whether |
| standard or error output (respectively) will be displayed on a terminal |
| can check these environment variables to determine if they exist and |
| contain a non-empty value. If so the tool can assume that the output |
| will (eventually) be displayed on a terminal. If the variables are not |
| set or have an empty value, then the tool should fall back to its |
| normal methods of detecting whether output is going to a terminal or |
| not. |
| |
| The content of the variables can be parsed to determine the type of |
| terminal which will be used to display the output. |
| |
| Similarly, environments which invoke `make' and would like to |
| capture the output and eventually display it on a terminal (or some |
| display which can interpret terminal control characters) can set these |
| variables before invoking `make'. GNU `make' will not modify these |
| environment variables if they already exist when it starts. |
| |
| |
| File: make.info, Node: Features, Next: Missing, Prev: Integrating make, Up: Top |
| |
| 14 Features of GNU `make' |
| ************************* |
| |
| Here is a summary of the features of GNU `make', for comparison with |
| and credit to other versions of `make'. We consider the features of |
| `make' in 4.2 BSD systems as a baseline. If you are concerned with |
| writing portable makefiles, you should not use the features of `make' |
| listed here, nor the ones in *Note Missing::. |
| |
| Many features come from the version of `make' in System V. |
| |
| * The `VPATH' variable and its special meaning. *Note Searching |
| Directories for Prerequisites: Directory Search. This feature |
| exists in System V `make', but is undocumented. It is documented |
| in 4.3 BSD `make' (which says it mimics System V's `VPATH' |
| feature). |
| |
| * Included makefiles. *Note Including Other Makefiles: Include. |
| Allowing multiple files to be included with a single directive is |
| a GNU extension. |
| |
| * Variables are read from and communicated via the environment. |
| *Note Variables from the Environment: Environment. |
| |
| * Options passed through the variable `MAKEFLAGS' to recursive |
| invocations of `make'. *Note Communicating Options to a |
| Sub-`make': Options/Recursion. |
| |
| * The automatic variable `$%' is set to the member name in an |
| archive reference. *Note Automatic Variables::. |
| |
| * The automatic variables `$@', `$*', `$<', `$%', and `$?' have |
| corresponding forms like `$(@F)' and `$(@D)'. We have generalized |
| this to `$^' as an obvious extension. *Note Automatic Variables::. |
| |
| * Substitution variable references. *Note Basics of Variable |
| References: Reference. |
| |
| * The command line options `-b' and `-m', accepted and ignored. In |
| System V `make', these options actually do something. |
| |
| * Execution of recursive commands to run `make' via the variable |
| `MAKE' even if `-n', `-q' or `-t' is specified. *Note Recursive |
| Use of `make': Recursion. |
| |
| * Support for suffix `.a' in suffix rules. *Note Archive Suffix |
| Rules::. This feature is obsolete in GNU `make', because the |
| general feature of rule chaining (*note Chains of Implicit Rules: |
| Chained Rules.) allows one pattern rule for installing members in |
| an archive (*note Archive Update::) to be sufficient. |
| |
| * The arrangement of lines and backslash/newline combinations in |
| recipes is retained when the recipes are printed, so they appear as |
| they do in the makefile, except for the stripping of initial |
| whitespace. |
| |
| The following features were inspired by various other versions of |
| `make'. In some cases it is unclear exactly which versions inspired |
| which others. |
| |
| * Pattern rules using `%'. This has been implemented in several |
| versions of `make'. We're not sure who invented it first, but |
| it's been spread around a bit. *Note Defining and Redefining |
| Pattern Rules: Pattern Rules. |
| |
| * Rule chaining and implicit intermediate files. This was |
| implemented by Stu Feldman in his version of `make' for AT&T |
| Eighth Edition Research Unix, and later by Andrew Hume of AT&T |
| Bell Labs in his `mk' program (where he terms it "transitive |
| closure"). We do not really know if we got this from either of |
| them or thought it up ourselves at the same time. *Note Chains of |
| Implicit Rules: Chained Rules. |
| |
| * The automatic variable `$^' containing a list of all prerequisites |
| of the current target. We did not invent this, but we have no |
| idea who did. *Note Automatic Variables::. The automatic variable |
| `$+' is a simple extension of `$^'. |
| |
| * The "what if" flag (`-W' in GNU `make') was (as far as we know) |
| invented by Andrew Hume in `mk'. *Note Instead of Executing |
| Recipes: Instead of Execution. |
| |
| * The concept of doing several things at once (parallelism) exists in |
| many incarnations of `make' and similar programs, though not in the |
| System V or BSD implementations. *Note Recipe Execution: |
| Execution. |
| |
| * A number of different build tools that support parallelism also |
| support collecting output and displaying as a single block. *Note |
| Output During Parallel Execution: Parallel Output. |
| |
| * Modified variable references using pattern substitution come from |
| SunOS 4. *Note Basics of Variable References: Reference. This |
| functionality was provided in GNU `make' by the `patsubst' |
| function before the alternate syntax was implemented for |
| compatibility with SunOS 4. It is not altogether clear who |
| inspired whom, since GNU `make' had `patsubst' before SunOS 4 was |
| released. |
| |
| * The special significance of `+' characters preceding recipe lines |
| (*note Instead of Executing Recipes: Instead of Execution.) is |
| mandated by `IEEE Standard 1003.2-1992' (POSIX.2). |
| |
| * The `+=' syntax to append to the value of a variable comes from |
| SunOS 4 `make'. *Note Appending More Text to Variables: Appending. |
| |
| * The syntax `ARCHIVE(MEM1 MEM2...)' to list multiple members in a |
| single archive file comes from SunOS 4 `make'. *Note Archive |
| Members::. |
| |
| * The `-include' directive to include makefiles with no error for a |
| nonexistent file comes from SunOS 4 `make'. (But note that SunOS 4 |
| `make' does not allow multiple makefiles to be specified in one |
| `-include' directive.) The same feature appears with the name |
| `sinclude' in SGI `make' and perhaps others. |
| |
| * The `!=' shell assignment operator exists in many BSD of `make' |
| and is purposefully implemented here to behave identically to |
| those implementations. |
| |
| * Various build management tools are implemented using scripting |
| languages such as Perl or Python and thus provide a natural |
| embedded scripting language, similar to GNU `make''s integration |
| of GNU Guile. |
| |
| The remaining features are inventions new in GNU `make': |
| |
| * Use the `-v' or `--version' option to print version and copyright |
| information. |
| |
| * Use the `-h' or `--help' option to summarize the options to `make'. |
| |
| * Simply-expanded variables. *Note The Two Flavors of Variables: |
| Flavors. |
| |
| * Pass command line variable assignments automatically through the |
| variable `MAKE' to recursive `make' invocations. *Note Recursive |
| Use of `make': Recursion. |
| |
| * Use the `-C' or `--directory' command option to change directory. |
| *Note Summary of Options: Options Summary. |
| |
| * Make verbatim variable definitions with `define'. *Note Defining |
| Multi-Line Variables: Multi-Line. |
| |
| * Declare phony targets with the special target `.PHONY'. |
| |
| Andrew Hume of AT&T Bell Labs implemented a similar feature with a |
| different syntax in his `mk' program. This seems to be a case of |
| parallel discovery. *Note Phony Targets: Phony Targets. |
| |
| * Manipulate text by calling functions. *Note Functions for |
| Transforming Text: Functions. |
| |
| * Use the `-o' or `--old-file' option to pretend a file's |
| modification-time is old. *Note Avoiding Recompilation of Some |
| Files: Avoiding Compilation. |
| |
| * Conditional execution. |
| |
| This feature has been implemented numerous times in various |
| versions of `make'; it seems a natural extension derived from the |
| features of the C preprocessor and similar macro languages and is |
| not a revolutionary concept. *Note Conditional Parts of |
| Makefiles: Conditionals. |
| |
| * Specify a search path for included makefiles. *Note Including |
| Other Makefiles: Include. |
| |
| * Specify extra makefiles to read with an environment variable. |
| *Note The Variable `MAKEFILES': MAKEFILES Variable. |
| |
| * Strip leading sequences of `./' from file names, so that `./FILE' |
| and `FILE' are considered to be the same file. |
| |
| * Use a special search method for library prerequisites written in |
| the form `-lNAME'. *Note Directory Search for Link Libraries: |
| Libraries/Search. |
| |
| * Allow suffixes for suffix rules (*note Old-Fashioned Suffix Rules: |
| Suffix Rules.) to contain any characters. In other versions of |
| `make', they must begin with `.' and not contain any `/' |
| characters. |
| |
| * Keep track of the current level of `make' recursion using the |
| variable `MAKELEVEL'. *Note Recursive Use of `make': Recursion. |
| |
| * Provide any goals given on the command line in the variable |
| `MAKECMDGOALS'. *Note Arguments to Specify the Goals: Goals. |
| |
| * Specify static pattern rules. *Note Static Pattern Rules: Static |
| Pattern. |
| |
| * Provide selective `vpath' search. *Note Searching Directories for |
| Prerequisites: Directory Search. |
| |
| * Provide computed variable references. *Note Basics of Variable |
| References: Reference. |
| |
| * Update makefiles. *Note How Makefiles Are Remade: Remaking |
| Makefiles. System V `make' has a very, very limited form of this |
| functionality in that it will check out SCCS files for makefiles. |
| |
| * Various new built-in implicit rules. *Note Catalogue of Built-In |
| Rules: Catalogue of Rules. |
| |
| * Load dynamic objects which can modify the behavior of `make'. |
| *Note Loading Dynamic Objects: Loading Objects. |
| |
| |
| File: make.info, Node: Missing, Next: Makefile Conventions, Prev: Features, Up: Top |
| |
| 15 Incompatibilities and Missing Features |
| ***************************************** |
| |
| The `make' programs in various other systems support a few features |
| that are not implemented in GNU `make'. The POSIX.2 standard (`IEEE |
| Standard 1003.2-1992') which specifies `make' does not require any of |
| these features. |
| |
| * A target of the form `FILE((ENTRY))' stands for a member of |
| archive file FILE. The member is chosen, not by name, but by |
| being an object file which defines the linker symbol ENTRY. |
| |
| This feature was not put into GNU `make' because of the |
| non-modularity of putting knowledge into `make' of the internal |
| format of archive file symbol tables. *Note Updating Archive |
| Symbol Directories: Archive Symbols. |
| |
| * Suffixes (used in suffix rules) that end with the character `~' |
| have a special meaning to System V `make'; they refer to the SCCS |
| file that corresponds to the file one would get without the `~'. |
| For example, the suffix rule `.c~.o' would make the file `N.o' from |
| the SCCS file `s.N.c'. For complete coverage, a whole series of |
| such suffix rules is required. *Note Old-Fashioned Suffix Rules: |
| Suffix Rules. |
| |
| In GNU `make', this entire series of cases is handled by two |
| pattern rules for extraction from SCCS, in combination with the |
| general feature of rule chaining. *Note Chains of Implicit Rules: |
| Chained Rules. |
| |
| * In System V and 4.3 BSD `make', files found by `VPATH' search |
| (*note Searching Directories for Prerequisites: Directory Search.) |
| have their names changed inside recipes. We feel it is much |
| cleaner to always use automatic variables and thus make this |
| feature unnecessary. |
| |
| * In some Unix `make's, the automatic variable `$*' appearing in the |
| prerequisites of a rule has the amazingly strange "feature" of |
| expanding to the full name of the _target of that rule_. We cannot |
| imagine what went on in the minds of Unix `make' developers to do |
| this; it is utterly inconsistent with the normal definition of |
| `$*'. |
| |
| * In some Unix `make's, implicit rule search (*note Using Implicit |
| Rules: Implicit Rules.) is apparently done for _all_ targets, not |
| just those without recipes. This means you can do: |
| |
| foo.o: |
| cc -c foo.c |
| |
| and Unix `make' will intuit that `foo.o' depends on `foo.c'. |
| |
| We feel that such usage is broken. The prerequisite properties of |
| `make' are well-defined (for GNU `make', at least), and doing such |
| a thing simply does not fit the model. |
| |
| * GNU `make' does not include any built-in implicit rules for |
| compiling or preprocessing EFL programs. If we hear of anyone who |
| is using EFL, we will gladly add them. |
| |
| * It appears that in SVR4 `make', a suffix rule can be specified |
| with no recipe, and it is treated as if it had an empty recipe |
| (*note Empty Recipes::). For example: |
| |
| .c.a: |
| |
| will override the built-in `.c.a' suffix rule. |
| |
| We feel that it is cleaner for a rule without a recipe to always |
| simply add to the prerequisite list for the target. The above |
| example can be easily rewritten to get the desired behavior in GNU |
| `make': |
| |
| .c.a: ; |
| |
| * Some versions of `make' invoke the shell with the `-e' flag, |
| except under `-k' (*note Testing the Compilation of a Program: |
| Testing.). The `-e' flag tells the shell to exit as soon as any |
| program it runs returns a nonzero status. We feel it is cleaner to |
| write each line of the recipe to stand on its own and not require |
| this special treatment. |
| |
| |
| File: make.info, Node: Makefile Conventions, Next: Quick Reference, Prev: Missing, Up: Top |
| |
| 16 Makefile Conventions |
| *********************** |
| |
| This node describes conventions for writing the Makefiles for GNU |
| programs. Using Automake will help you write a Makefile that follows |
| these conventions. For more information on portable Makefiles, see |
| POSIX and *Note Portable Make Programming: (autoconf)Portable Make. |
| |
| * Menu: |
| |
| * Makefile Basics:: General conventions for Makefiles. |
| * Utilities in Makefiles:: Utilities to be used in Makefiles. |
| * Command Variables:: Variables for specifying commands. |
| * DESTDIR:: Supporting staged installs. |
| * Directory Variables:: Variables for installation directories. |
| * Standard Targets:: Standard targets for users. |
| * Install Command Categories:: Three categories of commands in the `install' |
| rule: normal, pre-install and post-install. |
| |
| |
| File: make.info, Node: Makefile Basics, Next: Utilities in Makefiles, Up: Makefile Conventions |
| |
| 16.1 General Conventions for Makefiles |
| ====================================== |
| |
| Every Makefile should contain this line: |
| |
| SHELL = /bin/sh |
| |
| to avoid trouble on systems where the `SHELL' variable might be |
| inherited from the environment. (This is never a problem with GNU |
| `make'.) |
| |
| Different `make' programs have incompatible suffix lists and |
| implicit rules, and this sometimes creates confusion or misbehavior. So |
| it is a good idea to set the suffix list explicitly using only the |
| suffixes you need in the particular Makefile, like this: |
| |
| .SUFFIXES: |
| .SUFFIXES: .c .o |
| |
| The first line clears out the suffix list, the second introduces all |
| suffixes which may be subject to implicit rules in this Makefile. |
| |
| Don't assume that `.' is in the path for command execution. When |
| you need to run programs that are a part of your package during the |
| make, please make sure that it uses `./' if the program is built as |
| part of the make or `$(srcdir)/' if the file is an unchanging part of |
| the source code. Without one of these prefixes, the current search |
| path is used. |
| |
| The distinction between `./' (the "build directory") and |
| `$(srcdir)/' (the "source directory") is important because users can |
| build in a separate directory using the `--srcdir' option to |
| `configure'. A rule of the form: |
| |
| foo.1 : foo.man sedscript |
| sed -f sedscript foo.man > foo.1 |
| |
| will fail when the build directory is not the source directory, because |
| `foo.man' and `sedscript' are in the source directory. |
| |
| When using GNU `make', relying on `VPATH' to find the source file |
| will work in the case where there is a single dependency file, since |
| the `make' automatic variable `$<' will represent the source file |
| wherever it is. (Many versions of `make' set `$<' only in implicit |
| rules.) A Makefile target like |
| |
| foo.o : bar.c |
| $(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o |
| |
| should instead be written as |
| |
| foo.o : bar.c |
| $(CC) -I. -I$(srcdir) $(CFLAGS) -c $< -o $@ |
| |
| in order to allow `VPATH' to work correctly. When the target has |
| multiple dependencies, using an explicit `$(srcdir)' is the easiest way |
| to make the rule work well. For example, the target above for `foo.1' |
| is best written as: |
| |
| foo.1 : foo.man sedscript |
| sed -f $(srcdir)/sedscript $(srcdir)/foo.man > $@ |
| |
| GNU distributions usually contain some files which are not source |
| files--for example, Info files, and the output from Autoconf, Automake, |
| Bison or Flex. Since these files normally appear in the source |
| directory, they should always appear in the source directory, not in the |
| build directory. So Makefile rules to update them should put the |
| updated files in the source directory. |
| |
| However, if a file does not appear in the distribution, then the |
| Makefile should not put it in the source directory, because building a |
| program in ordinary circumstances should not modify the source directory |
| in any way. |
| |
| Try to make the build and installation targets, at least (and all |
| their subtargets) work correctly with a parallel `make'. |
| |
| |
| File: make.info, Node: Utilities in Makefiles, Next: Command Variables, Prev: Makefile Basics, Up: Makefile Conventions |
| |
| 16.2 Utilities in Makefiles |
| =========================== |
| |
| Write the Makefile commands (and any shell scripts, such as |
| `configure') to run under `sh' (both the traditional Bourne shell and |
| the POSIX shell), not `csh'. Don't use any special features of `ksh' |
| or `bash', or POSIX features not widely supported in traditional Bourne |
| `sh'. |
| |
| The `configure' script and the Makefile rules for building and |
| installation should not use any utilities directly except these: |
| |
| awk cat cmp cp diff echo egrep expr false grep install-info ln ls |
| mkdir mv printf pwd rm rmdir sed sleep sort tar test touch tr true |
| |
| Compression programs such as `gzip' can be used in the `dist' rule. |
| |
| Generally, stick to the widely-supported (usually POSIX-specified) |
| options and features of these programs. For example, don't use `mkdir |
| -p', convenient as it may be, because a few systems don't support it at |
| all and with others, it is not safe for parallel execution. For a list |
| of known incompatibilities, see *Note Portable Shell Programming: |
| (autoconf)Portable Shell. |
| |
| It is a good idea to avoid creating symbolic links in makefiles, |
| since a few file systems don't support them. |
| |
| The Makefile rules for building and installation can also use |
| compilers and related programs, but should do so via `make' variables |
| so that the user can substitute alternatives. Here are some of the |
| programs we mean: |
| |
| ar bison cc flex install ld ldconfig lex |
| make makeinfo ranlib texi2dvi yacc |
| |
| Use the following `make' variables to run those programs: |
| |
| $(AR) $(BISON) $(CC) $(FLEX) $(INSTALL) $(LD) $(LDCONFIG) $(LEX) |
| $(MAKE) $(MAKEINFO) $(RANLIB) $(TEXI2DVI) $(YACC) |
| |
| When you use `ranlib' or `ldconfig', you should make sure nothing |
| bad happens if the system does not have the program in question. |
| Arrange to ignore an error from that command, and print a message before |
| the command to tell the user that failure of this command does not mean |
| a problem. (The Autoconf `AC_PROG_RANLIB' macro can help with this.) |
| |
| If you use symbolic links, you should implement a fallback for |
| systems that don't have symbolic links. |
| |
| Additional utilities that can be used via Make variables are: |
| |
| chgrp chmod chown mknod |
| |
| It is ok to use other utilities in Makefile portions (or scripts) |
| intended only for particular systems where you know those utilities |
| exist. |
| |
| |
| File: make.info, Node: Command Variables, Next: DESTDIR, Prev: Utilities in Makefiles, Up: Makefile Conventions |
| |
| 16.3 Variables for Specifying Commands |
| ====================================== |
| |
| Makefiles should provide variables for overriding certain commands, |
| options, and so on. |
| |
| In particular, you should run most utility programs via variables. |
| Thus, if you use Bison, have a variable named `BISON' whose default |
| value is set with `BISON = bison', and refer to it with `$(BISON)' |
| whenever you need to use Bison. |
| |
| File management utilities such as `ln', `rm', `mv', and so on, need |
| not be referred to through variables in this way, since users don't |
| need to replace them with other programs. |
| |
| Each program-name variable should come with an options variable that |
| is used to supply options to the program. Append `FLAGS' to the |
| program-name variable name to get the options variable name--for |
| example, `BISONFLAGS'. (The names `CFLAGS' for the C compiler, |
| `YFLAGS' for yacc, and `LFLAGS' for lex, are exceptions to this rule, |
| but we keep them because they are standard.) Use `CPPFLAGS' in any |
| compilation command that runs the preprocessor, and use `LDFLAGS' in |
| any compilation command that does linking as well as in any direct use |
| of `ld'. |
| |
| If there are C compiler options that _must_ be used for proper |
| compilation of certain files, do not include them in `CFLAGS'. Users |
| expect to be able to specify `CFLAGS' freely themselves. Instead, |
| arrange to pass the necessary options to the C compiler independently |
| of `CFLAGS', by writing them explicitly in the compilation commands or |
| by defining an implicit rule, like this: |
| |
| CFLAGS = -g |
| ALL_CFLAGS = -I. $(CFLAGS) |
| .c.o: |
| $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $< |
| |
| Do include the `-g' option in `CFLAGS', because that is not |
| _required_ for proper compilation. You can consider it a default that |
| is only recommended. If the package is set up so that it is compiled |
| with GCC by default, then you might as well include `-O' in the default |
| value of `CFLAGS' as well. |
| |
| Put `CFLAGS' last in the compilation command, after other variables |
| containing compiler options, so the user can use `CFLAGS' to override |
| the others. |
| |
| `CFLAGS' should be used in every invocation of the C compiler, both |
| those which do compilation and those which do linking. |
| |
| Every Makefile should define the variable `INSTALL', which is the |
| basic command for installing a file into the system. |
| |
| Every Makefile should also define the variables `INSTALL_PROGRAM' |
| and `INSTALL_DATA'. (The default for `INSTALL_PROGRAM' should be |
| `$(INSTALL)'; the default for `INSTALL_DATA' should be `${INSTALL} -m |
| 644'.) Then it should use those variables as the commands for actual |
| installation, for executables and non-executables respectively. |
| Minimal use of these variables is as follows: |
| |
| $(INSTALL_PROGRAM) foo $(bindir)/foo |
| $(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a |
| |
| However, it is preferable to support a `DESTDIR' prefix on the |
| target files, as explained in the next section. |
| |
| It is acceptable, but not required, to install multiple files in one |
| command, with the final argument being a directory, as in: |
| |
| $(INSTALL_PROGRAM) foo bar baz $(bindir) |
| |
| |
| File: make.info, Node: DESTDIR, Next: Directory Variables, Prev: Command Variables, Up: Makefile Conventions |
| |
| 16.4 `DESTDIR': Support for Staged Installs |
| =========================================== |
| |
| `DESTDIR' is a variable prepended to each installed target file, like |
| this: |
| |
| $(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo |
| $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a |
| |
| The `DESTDIR' variable is specified by the user on the `make' |
| command line as an absolute file name. For example: |
| |
| make DESTDIR=/tmp/stage install |
| |
| `DESTDIR' should be supported only in the `install*' and `uninstall*' |
| targets, as those are the only targets where it is useful. |
| |
| If your installation step would normally install |
| `/usr/local/bin/foo' and `/usr/local/lib/libfoo.a', then an |
| installation invoked as in the example above would install |
| `/tmp/stage/usr/local/bin/foo' and `/tmp/stage/usr/local/lib/libfoo.a' |
| instead. |
| |
| Prepending the variable `DESTDIR' to each target in this way |
| provides for "staged installs", where the installed files are not |
| placed directly into their expected location but are instead copied |
| into a temporary location (`DESTDIR'). However, installed files |
| maintain their relative directory structure and any embedded file names |
| will not be modified. |
| |
| You should not set the value of `DESTDIR' in your `Makefile' at all; |
| then the files are installed into their expected locations by default. |
| Also, specifying `DESTDIR' should not change the operation of the |
| software in any way, so its value should not be included in any file |
| contents. |
| |
| `DESTDIR' support is commonly used in package creation. It is also |
| helpful to users who want to understand what a given package will |
| install where, and to allow users who don't normally have permissions |
| to install into protected areas to build and install before gaining |
| those permissions. Finally, it can be useful with tools such as |
| `stow', where code is installed in one place but made to appear to be |
| installed somewhere else using symbolic links or special mount |
| operations. So, we strongly recommend GNU packages support `DESTDIR', |
| though it is not an absolute requirement. |
| |
| |
| File: make.info, Node: Directory Variables, Next: Standard Targets, Prev: DESTDIR, Up: Makefile Conventions |
| |
| 16.5 Variables for Installation Directories |
| =========================================== |
| |
| Installation directories should always be named by variables, so it is |
| easy to install in a nonstandard place. The standard names for these |
| variables and the values they should have in GNU packages are described |
| below. They are based on a standard file system layout; variants of it |
| are used in GNU/Linux and other modern operating systems. |
| |
| Installers are expected to override these values when calling `make' |
| (e.g., `make prefix=/usr install') or `configure' (e.g., `configure |
| --prefix=/usr'). GNU packages should not try to guess which value |
| should be appropriate for these variables on the system they are being |
| installed onto: use the default settings specified here so that all GNU |
| packages behave identically, allowing the installer to achieve any |
| desired layout. |
| |
| All installation directories, and their parent directories, should be |
| created (if necessary) before they are installed into. |
| |
| These first two variables set the root for the installation. All the |
| other installation directories should be subdirectories of one of these |
| two, and nothing should be directly installed into these two |
| directories. |
| |
| `prefix' |
| A prefix used in constructing the default values of the variables |
| listed below. The default value of `prefix' should be |
| `/usr/local'. When building the complete GNU system, the prefix |
| will be empty and `/usr' will be a symbolic link to `/'. (If you |
| are using Autoconf, write it as `@prefix@'.) |
| |
| Running `make install' with a different value of `prefix' from the |
| one used to build the program should _not_ recompile the program. |
| |
| `exec_prefix' |
| A prefix used in constructing the default values of some of the |
| variables listed below. The default value of `exec_prefix' should |
| be `$(prefix)'. (If you are using Autoconf, write it as |
| `@exec_prefix@'.) |
| |
| Generally, `$(exec_prefix)' is used for directories that contain |
| machine-specific files (such as executables and subroutine |
| libraries), while `$(prefix)' is used directly for other |
| directories. |
| |
| Running `make install' with a different value of `exec_prefix' |
| from the one used to build the program should _not_ recompile the |
| program. |
| |
| Executable programs are installed in one of the following |
| directories. |
| |
| `bindir' |
| The directory for installing executable programs that users can |
| run. This should normally be `/usr/local/bin', but write it as |
| `$(exec_prefix)/bin'. (If you are using Autoconf, write it as |
| `@bindir@'.) |
| |
| `sbindir' |
| The directory for installing executable programs that can be run |
| from the shell, but are only generally useful to system |
| administrators. This should normally be `/usr/local/sbin', but |
| write it as `$(exec_prefix)/sbin'. (If you are using Autoconf, |
| write it as `@sbindir@'.) |
| |
| `libexecdir' |
| The directory for installing executable programs to be run by other |
| programs rather than by users. This directory should normally be |
| `/usr/local/libexec', but write it as `$(exec_prefix)/libexec'. |
| (If you are using Autoconf, write it as `@libexecdir@'.) |
| |
| The definition of `libexecdir' is the same for all packages, so |
| you should install your data in a subdirectory thereof. Most |
| packages install their data under `$(libexecdir)/PACKAGE-NAME/', |
| possibly within additional subdirectories thereof, such as |
| `$(libexecdir)/PACKAGE-NAME/MACHINE/VERSION'. |
| |
| Data files used by the program during its execution are divided into |
| categories in two ways. |
| |
| * Some files are normally modified by programs; others are never |
| normally modified (though users may edit some of these). |
| |
| * Some files are architecture-independent and can be shared by all |
| machines at a site; some are architecture-dependent and can be |
| shared only by machines of the same kind and operating system; |
| others may never be shared between two machines. |
| |
| This makes for six different possibilities. However, we want to |
| discourage the use of architecture-dependent files, aside from object |
| files and libraries. It is much cleaner to make other data files |
| architecture-independent, and it is generally not hard. |
| |
| Here are the variables Makefiles should use to specify directories |
| to put these various kinds of files in: |
| |
| `datarootdir' |
| The root of the directory tree for read-only |
| architecture-independent data files. This should normally be |
| `/usr/local/share', but write it as `$(prefix)/share'. (If you |
| are using Autoconf, write it as `@datarootdir@'.) `datadir''s |
| default value is based on this variable; so are `infodir', |
| `mandir', and others. |
| |
| `datadir' |
| The directory for installing idiosyncratic read-only |
| architecture-independent data files for this program. This is |
| usually the same place as `datarootdir', but we use the two |
| separate variables so that you can move these program-specific |
| files without altering the location for Info files, man pages, etc. |
| |
| This should normally be `/usr/local/share', but write it as |
| `$(datarootdir)'. (If you are using Autoconf, write it as |
| `@datadir@'.) |
| |
| The definition of `datadir' is the same for all packages, so you |
| should install your data in a subdirectory thereof. Most packages |
| install their data under `$(datadir)/PACKAGE-NAME/'. |
| |
| `sysconfdir' |
| The directory for installing read-only data files that pertain to a |
| single machine-that is to say, files for configuring a host. |
| Mailer and network configuration files, `/etc/passwd', and so |
| forth belong here. All the files in this directory should be |
| ordinary ASCII text files. This directory should normally be |
| `/usr/local/etc', but write it as `$(prefix)/etc'. (If you are |
| using Autoconf, write it as `@sysconfdir@'.) |
| |
| Do not install executables here in this directory (they probably |
| belong in `$(libexecdir)' or `$(sbindir)'). Also do not install |
| files that are modified in the normal course of their use (programs |
| whose purpose is to change the configuration of the system |
| excluded). Those probably belong in `$(localstatedir)'. |
| |
| `sharedstatedir' |
| The directory for installing architecture-independent data files |
| which the programs modify while they run. This should normally be |
| `/usr/local/com', but write it as `$(prefix)/com'. (If you are |
| using Autoconf, write it as `@sharedstatedir@'.) |
| |
| `localstatedir' |
| The directory for installing data files which the programs modify |
| while they run, and that pertain to one specific machine. Users |
| should never need to modify files in this directory to configure |
| the package's operation; put such configuration information in |
| separate files that go in `$(datadir)' or `$(sysconfdir)'. |
| `$(localstatedir)' should normally be `/usr/local/var', but write |
| it as `$(prefix)/var'. (If you are using Autoconf, write it as |
| `@localstatedir@'.) |
| |
| `runstatedir' |
| The directory for installing data files which the programs modify |
| while they run, that pertain to one specific machine, and which |
| need not persist longer than the execution of the program--which is |
| generally long-lived, for example, until the next reboot. PID |
| files for system daemons are a typical use. In addition, this |
| directory should not be cleaned except perhaps at reboot, while |
| the general `/tmp' (`TMPDIR') may be cleaned arbitrarily. This |
| should normally be `/var/run', but write it as |
| `$(localstatedir)/run'. Having it as a separate variable allows |
| the use of `/run' if desired, for example. (If you are using |
| Autoconf 2.70 or later, write it as `@runstatedir@'.) |
| |
| These variables specify the directory for installing certain specific |
| types of files, if your program has them. Every GNU package should |
| have Info files, so every program needs `infodir', but not all need |
| `libdir' or `lispdir'. |
| |
| `includedir' |
| The directory for installing header files to be included by user |
| programs with the C `#include' preprocessor directive. This |
| should normally be `/usr/local/include', but write it as |
| `$(prefix)/include'. (If you are using Autoconf, write it as |
| `@includedir@'.) |
| |
| Most compilers other than GCC do not look for header files in |
| directory `/usr/local/include'. So installing the header files |
| this way is only useful with GCC. Sometimes this is not a problem |
| because some libraries are only really intended to work with GCC. |
| But some libraries are intended to work with other compilers. |
| They should install their header files in two places, one |
| specified by `includedir' and one specified by `oldincludedir'. |
| |
| `oldincludedir' |
| The directory for installing `#include' header files for use with |
| compilers other than GCC. This should normally be `/usr/include'. |
| (If you are using Autoconf, you can write it as `@oldincludedir@'.) |
| |
| The Makefile commands should check whether the value of |
| `oldincludedir' is empty. If it is, they should not try to use |
| it; they should cancel the second installation of the header files. |
| |
| A package should not replace an existing header in this directory |
| unless the header came from the same package. Thus, if your Foo |
| package provides a header file `foo.h', then it should install the |
| header file in the `oldincludedir' directory if either (1) there |
| is no `foo.h' there or (2) the `foo.h' that exists came from the |
| Foo package. |
| |
| To tell whether `foo.h' came from the Foo package, put a magic |
| string in the file--part of a comment--and `grep' for that string. |
| |
| `docdir' |
| The directory for installing documentation files (other than Info) |
| for this package. By default, it should be |
| `/usr/local/share/doc/YOURPKG', but it should be written as |
| `$(datarootdir)/doc/YOURPKG'. (If you are using Autoconf, write |
| it as `@docdir@'.) The YOURPKG subdirectory, which may include a |
| version number, prevents collisions among files with common names, |
| such as `README'. |
| |
| `infodir' |
| The directory for installing the Info files for this package. By |
| default, it should be `/usr/local/share/info', but it should be |
| written as `$(datarootdir)/info'. (If you are using Autoconf, |
| write it as `@infodir@'.) `infodir' is separate from `docdir' for |
| compatibility with existing practice. |
| |
| `htmldir' |
| `dvidir' |
| `pdfdir' |
| `psdir' |
| Directories for installing documentation files in the particular |
| format. They should all be set to `$(docdir)' by default. (If |
| you are using Autoconf, write them as `@htmldir@', `@dvidir@', |
| etc.) Packages which supply several translations of their |
| documentation should install them in `$(htmldir)/'LL, |
| `$(pdfdir)/'LL, etc. where LL is a locale abbreviation such as |
| `en' or `pt_BR'. |
| |
| `libdir' |
| The directory for object files and libraries of object code. Do |
| not install executables here, they probably ought to go in |
| `$(libexecdir)' instead. The value of `libdir' should normally be |
| `/usr/local/lib', but write it as `$(exec_prefix)/lib'. (If you |
| are using Autoconf, write it as `@libdir@'.) |
| |
| `lispdir' |
| The directory for installing any Emacs Lisp files in this package. |
| By default, it should be `/usr/local/share/emacs/site-lisp', but |
| it should be written as `$(datarootdir)/emacs/site-lisp'. |
| |
| If you are using Autoconf, write the default as `@lispdir@'. In |
| order to make `@lispdir@' work, you need the following lines in |
| your `configure.ac' file: |
| |
| lispdir='${datarootdir}/emacs/site-lisp' |
| AC_SUBST(lispdir) |
| |
| `localedir' |
| The directory for installing locale-specific message catalogs for |
| this package. By default, it should be `/usr/local/share/locale', |
| but it should be written as `$(datarootdir)/locale'. (If you are |
| using Autoconf, write it as `@localedir@'.) This directory |
| usually has a subdirectory per locale. |
| |
| Unix-style man pages are installed in one of the following: |
| |
| `mandir' |
| The top-level directory for installing the man pages (if any) for |
| this package. It will normally be `/usr/local/share/man', but you |
| should write it as `$(datarootdir)/man'. (If you are using |
| Autoconf, write it as `@mandir@'.) |
| |
| `man1dir' |
| The directory for installing section 1 man pages. Write it as |
| `$(mandir)/man1'. |
| |
| `man2dir' |
| The directory for installing section 2 man pages. Write it as |
| `$(mandir)/man2' |
| |
| `...' |
| *Don't make the primary documentation for any GNU software be a |
| man page. Write a manual in Texinfo instead. Man pages are just |
| for the sake of people running GNU software on Unix, which is a |
| secondary application only.* |
| |
| `manext' |
| The file name extension for the installed man page. This should |
| contain a period followed by the appropriate digit; it should |
| normally be `.1'. |
| |
| `man1ext' |
| The file name extension for installed section 1 man pages. |
| |
| `man2ext' |
| The file name extension for installed section 2 man pages. |
| |
| `...' |
| Use these names instead of `manext' if the package needs to |
| install man pages in more than one section of the manual. |
| |
| And finally, you should set the following variable: |
| |
| `srcdir' |
| The directory for the sources being compiled. The value of this |
| variable is normally inserted by the `configure' shell script. |
| (If you are using Autoconf, use `srcdir = @srcdir@'.) |
| |
| For example: |
| |
| # Common prefix for installation directories. |
| # NOTE: This directory must exist when you start the install. |
| prefix = /usr/local |
| datarootdir = $(prefix)/share |
| datadir = $(datarootdir) |
| exec_prefix = $(prefix) |
| # Where to put the executable for the command 'gcc'. |
| bindir = $(exec_prefix)/bin |
| # Where to put the directories used by the compiler. |
| libexecdir = $(exec_prefix)/libexec |
| # Where to put the Info files. |
| infodir = $(datarootdir)/info |
| |
| If your program installs a large number of files into one of the |
| standard user-specified directories, it might be useful to group them |
| into a subdirectory particular to that program. If you do this, you |
| should write the `install' rule to create these subdirectories. |
| |
| Do not expect the user to include the subdirectory name in the value |
| of any of the variables listed above. The idea of having a uniform set |
| of variable names for installation directories is to enable the user to |
| specify the exact same values for several different GNU packages. In |
| order for this to be useful, all the packages must be designed so that |
| they will work sensibly when the user does so. |
| |
| At times, not all of these variables may be implemented in the |
| current release of Autoconf and/or Automake; but as of Autoconf 2.60, we |
| believe all of them are. When any are missing, the descriptions here |
| serve as specifications for what Autoconf will implement. As a |
| programmer, you can either use a development version of Autoconf or |
| avoid using these variables until a stable release is made which |
| supports them. |
| |
| |
| File: make.info, Node: Standard Targets, Next: Install Command Categories, Prev: Directory Variables, Up: Makefile Conventions |
| |
| 16.6 Standard Targets for Users |
| =============================== |
| |
| All GNU programs should have the following targets in their Makefiles: |
| |
| `all' |
| Compile the entire program. This should be the default target. |
| This target need not rebuild any documentation files; Info files |
| should normally be included in the distribution, and DVI (and other |
| documentation format) files should be made only when explicitly |
| asked for. |
| |
| By default, the Make rules should compile and link with `-g', so |
| that executable programs have debugging symbols. Otherwise, you |
| are essentially helpless in the face of a crash, and it is often |
| far from easy to reproduce with a fresh build. |
| |
| `install' |
| Compile the program and copy the executables, libraries, and so on |
| to the file names where they should reside for actual use. If |
| there is a simple test to verify that a program is properly |
| installed, this target should run that test. |
| |
| Do not strip executables when installing them. This helps eventual |
| debugging that may be needed later, and nowadays disk space is |
| cheap and dynamic loaders typically ensure debug sections are not |
| loaded during normal execution. Users that need stripped binaries |
| may invoke the `install-strip' target to do that. |
| |
| If possible, write the `install' target rule so that it does not |
| modify anything in the directory where the program was built, |
| provided `make all' has just been done. This is convenient for |
| building the program under one user name and installing it under |
| another. |
| |
| The commands should create all the directories in which files are |
| to be installed, if they don't already exist. This includes the |
| directories specified as the values of the variables `prefix' and |
| `exec_prefix', as well as all subdirectories that are needed. One |
| way to do this is by means of an `installdirs' target as described |
| below. |
| |
| Use `-' before any command for installing a man page, so that |
| `make' will ignore any errors. This is in case there are systems |
| that don't have the Unix man page documentation system installed. |
| |
| The way to install Info files is to copy them into `$(infodir)' |
| with `$(INSTALL_DATA)' (*note Command Variables::), and then run |
| the `install-info' program if it is present. `install-info' is a |
| program that edits the Info `dir' file to add or update the menu |
| entry for the given Info file; it is part of the Texinfo package. |
| |
| Here is a sample rule to install an Info file that also tries to |
| handle some additional situations, such as `install-info' not |
| being present. |
| |
| do-install-info: foo.info installdirs |
| $(NORMAL_INSTALL) |
| # Prefer an info file in . to one in srcdir. |
| if test -f foo.info; then d=.; \ |
| else d="$(srcdir)"; fi; \ |
| $(INSTALL_DATA) $$d/foo.info \ |
| "$(DESTDIR)$(infodir)/foo.info" |
| # Run install-info only if it exists. |
| # Use 'if' instead of just prepending '-' to the |
| # line so we notice real errors from install-info. |
| # Use '$(SHELL) -c' because some shells do not |
| # fail gracefully when there is an unknown command. |
| $(POST_INSTALL) |
| if $(SHELL) -c 'install-info --version' \ |
| >/dev/null 2>&1; then \ |
| install-info --dir-file="$(DESTDIR)$(infodir)/dir" \ |
| "$(DESTDIR)$(infodir)/foo.info"; \ |
| else true; fi |
| |
| When writing the `install' target, you must classify all the |
| commands into three categories: normal ones, "pre-installation" |
| commands and "post-installation" commands. *Note Install Command |
| Categories::. |
| |
| `install-html' |
| `install-dvi' |
| `install-pdf' |
| `install-ps' |
| These targets install documentation in formats other than Info; |
| they're intended to be called explicitly by the person installing |
| the package, if that format is desired. GNU prefers Info files, |
| so these must be installed by the `install' target. |
| |
| When you have many documentation files to install, we recommend |
| that you avoid collisions and clutter by arranging for these |
| targets to install in subdirectories of the appropriate |
| installation directory, such as `htmldir'. As one example, if |
| your package has multiple manuals, and you wish to install HTML |
| documentation with many files (such as the "split" mode output by |
| `makeinfo --html'), you'll certainly want to use subdirectories, |
| or two nodes with the same name in different manuals will |
| overwrite each other. |
| |
| Please make these `install-FORMAT' targets invoke the commands for |
| the FORMAT target, for example, by making FORMAT a dependency. |
| |
| `uninstall' |
| Delete all the installed files--the copies that the `install' and |
| `install-*' targets create. |
| |
| This rule should not modify the directories where compilation is |
| done, only the directories where files are installed. |
| |
| The uninstallation commands are divided into three categories, |
| just like the installation commands. *Note Install Command |
| Categories::. |
| |
| `install-strip' |
| Like `install', but strip the executable files while installing |
| them. In simple cases, this target can use the `install' target in |
| a simple way: |
| |
| install-strip: |
| $(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \ |
| install |
| |
| But if the package installs scripts as well as real executables, |
| the `install-strip' target can't just refer to the `install' |
| target; it has to strip the executables but not the scripts. |
| |
| `install-strip' should not strip the executables in the build |
| directory which are being copied for installation. It should only |
| strip the copies that are installed. |
| |
| Normally we do not recommend stripping an executable unless you |
| are sure the program has no bugs. However, it can be reasonable |
| to install a stripped executable for actual execution while saving |
| the unstripped executable elsewhere in case there is a bug. |
| |
| `clean' |
| Delete all files in the current directory that are normally |
| created by building the program. Also delete files in other |
| directories if they are created by this makefile. However, don't |
| delete the files that record the configuration. Also preserve |
| files that could be made by building, but normally aren't because |
| the distribution comes with them. There is no need to delete |
| parent directories that were created with `mkdir -p', since they |
| could have existed anyway. |
| |
| Delete `.dvi' files here if they are not part of the distribution. |
| |
| `distclean' |
| Delete all files in the current directory (or created by this |
| makefile) that are created by configuring or building the program. |
| If you have unpacked the source and built the program without |
| creating any other files, `make distclean' should leave only the |
| files that were in the distribution. However, there is no need to |
| delete parent directories that were created with `mkdir -p', since |
| they could have existed anyway. |
| |
| `mostlyclean' |
| Like `clean', but may refrain from deleting a few files that people |
| normally don't want to recompile. For example, the `mostlyclean' |
| target for GCC does not delete `libgcc.a', because recompiling it |
| is rarely necessary and takes a lot of time. |
| |
| `maintainer-clean' |
| Delete almost everything that can be reconstructed with this |
| Makefile. This typically includes everything deleted by |
| `distclean', plus more: C source files produced by Bison, tags |
| tables, Info files, and so on. |
| |
| The reason we say "almost everything" is that running the command |
| `make maintainer-clean' should not delete `configure' even if |
| `configure' can be remade using a rule in the Makefile. More |
| generally, `make maintainer-clean' should not delete anything that |
| needs to exist in order to run `configure' and then begin to build |
| the program. Also, there is no need to delete parent directories |
| that were created with `mkdir -p', since they could have existed |
| anyway. These are the only exceptions; `maintainer-clean' should |
| delete everything else that can be rebuilt. |
| |
| The `maintainer-clean' target is intended to be used by a |
| maintainer of the package, not by ordinary users. You may need |
| special tools to reconstruct some of the files that `make |
| maintainer-clean' deletes. Since these files are normally |
| included in the distribution, we don't take care to make them easy |
| to reconstruct. If you find you need to unpack the full |
| distribution again, don't blame us. |
| |
| To help make users aware of this, the commands for the special |
| `maintainer-clean' target should start with these two: |
| |
| @echo 'This command is intended for maintainers to use; it' |
| @echo 'deletes files that may need special tools to rebuild.' |
| |
| `TAGS' |
| Update a tags table for this program. |
| |
| `info' |
| Generate any Info files needed. The best way to write the rules |
| is as follows: |
| |
| info: foo.info |
| |
| foo.info: foo.texi chap1.texi chap2.texi |
| $(MAKEINFO) $(srcdir)/foo.texi |
| |
| You must define the variable `MAKEINFO' in the Makefile. It should |
| run the `makeinfo' program, which is part of the Texinfo |
| distribution. |
| |
| Normally a GNU distribution comes with Info files, and that means |
| the Info files are present in the source directory. Therefore, |
| the Make rule for an info file should update it in the source |
| directory. When users build the package, ordinarily Make will not |
| update the Info files because they will already be up to date. |
| |
| `dvi' |
| `html' |
| `pdf' |
| `ps' |
| Generate documentation files in the given format. These targets |
| should always exist, but any or all can be a no-op if the given |
| output format cannot be generated. These targets should not be |
| dependencies of the `all' target; the user must manually invoke |
| them. |
| |
| Here's an example rule for generating DVI files from Texinfo: |
| |
| dvi: foo.dvi |
| |
| foo.dvi: foo.texi chap1.texi chap2.texi |
| $(TEXI2DVI) $(srcdir)/foo.texi |
| |
| You must define the variable `TEXI2DVI' in the Makefile. It |
| should run the program `texi2dvi', which is part of the Texinfo |
| distribution. (`texi2dvi' uses TeX to do the real work of |
| formatting. TeX is not distributed with Texinfo.) Alternatively, |
| write only the dependencies, and allow GNU `make' to provide the |
| command. |
| |
| Here's another example, this one for generating HTML from Texinfo: |
| |
| html: foo.html |
| |
| foo.html: foo.texi chap1.texi chap2.texi |
| $(TEXI2HTML) $(srcdir)/foo.texi |
| |
| Again, you would define the variable `TEXI2HTML' in the Makefile; |
| for example, it might run `makeinfo --no-split --html' (`makeinfo' |
| is part of the Texinfo distribution). |
| |
| `dist' |
| Create a distribution tar file for this program. The tar file |
| should be set up so that the file names in the tar file start with |
| a subdirectory name which is the name of the package it is a |
| distribution for. This name can include the version number. |
| |
| For example, the distribution tar file of GCC version 1.40 unpacks |
| into a subdirectory named `gcc-1.40'. |
| |
| The easiest way to do this is to create a subdirectory |
| appropriately named, use `ln' or `cp' to install the proper files |
| in it, and then `tar' that subdirectory. |
| |
| Compress the tar file with `gzip'. For example, the actual |
| distribution file for GCC version 1.40 is called `gcc-1.40.tar.gz'. |
| It is ok to support other free compression formats as well. |
| |
| The `dist' target should explicitly depend on all non-source files |
| that are in the distribution, to make sure they are up to date in |
| the distribution. *Note Making Releases: (standards)Releases. |
| |
| `check' |
| Perform self-tests (if any). The user must build the program |
| before running the tests, but need not install the program; you |
| should write the self-tests so that they work when the program is |
| built but not installed. |
| |
| The following targets are suggested as conventional names, for |
| programs in which they are useful. |
| |
| `installcheck' |
| Perform installation tests (if any). The user must build and |
| install the program before running the tests. You should not |
| assume that `$(bindir)' is in the search path. |
| |
| `installdirs' |
| It's useful to add a target named `installdirs' to create the |
| directories where files are installed, and their parent |
| directories. There is a script called `mkinstalldirs' which is |
| convenient for this; you can find it in the Gnulib package. You |
| can use a rule like this: |
| |
| # Make sure all installation directories (e.g. $(bindir)) |
| # actually exist by making them if necessary. |
| installdirs: mkinstalldirs |
| $(srcdir)/mkinstalldirs $(bindir) $(datadir) \ |
| $(libdir) $(infodir) \ |
| $(mandir) |
| |
| or, if you wish to support `DESTDIR' (strongly encouraged), |
| |
| # Make sure all installation directories (e.g. $(bindir)) |
| # actually exist by making them if necessary. |
| installdirs: mkinstalldirs |
| $(srcdir)/mkinstalldirs \ |
| $(DESTDIR)$(bindir) $(DESTDIR)$(datadir) \ |
| $(DESTDIR)$(libdir) $(DESTDIR)$(infodir) \ |
| $(DESTDIR)$(mandir) |
| |
| This rule should not modify the directories where compilation is |
| done. It should do nothing but create installation directories. |
| |
| |
| File: make.info, Node: Install Command Categories, Prev: Standard Targets, Up: Makefile Conventions |
| |
| 16.7 Install Command Categories |
| =============================== |
| |
| When writing the `install' target, you must classify all the commands |
| into three categories: normal ones, "pre-installation" commands and |
| "post-installation" commands. |
| |
| Normal commands move files into their proper places, and set their |
| modes. They may not alter any files except the ones that come entirely |
| from the package they belong to. |
| |
| Pre-installation and post-installation commands may alter other |
| files; in particular, they can edit global configuration files or data |
| bases. |
| |
| Pre-installation commands are typically executed before the normal |
| commands, and post-installation commands are typically run after the |
| normal commands. |
| |
| The most common use for a post-installation command is to run |
| `install-info'. This cannot be done with a normal command, since it |
| alters a file (the Info directory) which does not come entirely and |
| solely from the package being installed. It is a post-installation |
| command because it needs to be done after the normal command which |
| installs the package's Info files. |
| |
| Most programs don't need any pre-installation commands, but we have |
| the feature just in case it is needed. |
| |
| To classify the commands in the `install' rule into these three |
| categories, insert "category lines" among them. A category line |
| specifies the category for the commands that follow. |
| |
| A category line consists of a tab and a reference to a special Make |
| variable, plus an optional comment at the end. There are three |
| variables you can use, one for each category; the variable name |
| specifies the category. Category lines are no-ops in ordinary execution |
| because these three Make variables are normally undefined (and you |
| _should not_ define them in the makefile). |
| |
| Here are the three possible category lines, each with a comment that |
| explains what it means: |
| |
| $(PRE_INSTALL) # Pre-install commands follow. |
| $(POST_INSTALL) # Post-install commands follow. |
| $(NORMAL_INSTALL) # Normal commands follow. |
| |
| If you don't use a category line at the beginning of the `install' |
| rule, all the commands are classified as normal until the first category |
| line. If you don't use any category lines, all the commands are |
| classified as normal. |
| |
| These are the category lines for `uninstall': |
| |
| $(PRE_UNINSTALL) # Pre-uninstall commands follow. |
| $(POST_UNINSTALL) # Post-uninstall commands follow. |
| $(NORMAL_UNINSTALL) # Normal commands follow. |
| |
| Typically, a pre-uninstall command would be used for deleting entries |
| from the Info directory. |
| |
| If the `install' or `uninstall' target has any dependencies which |
| act as subroutines of installation, then you should start _each_ |
| dependency's commands with a category line, and start the main target's |
| commands with a category line also. This way, you can ensure that each |
| command is placed in the right category regardless of which of the |
| dependencies actually run. |
| |
| Pre-installation and post-installation commands should not run any |
| programs except for these: |
| |
| [ basename bash cat chgrp chmod chown cmp cp dd diff echo |
| egrep expand expr false fgrep find getopt grep gunzip gzip |
| hostname install install-info kill ldconfig ln ls md5sum |
| mkdir mkfifo mknod mv printenv pwd rm rmdir sed sort tee |
| test touch true uname xargs yes |
| |
| The reason for distinguishing the commands in this way is for the |
| sake of making binary packages. Typically a binary package contains |
| all the executables and other files that need to be installed, and has |
| its own method of installing them--so it does not need to run the normal |
| installation commands. But installing the binary package does need to |
| execute the pre-installation and post-installation commands. |
| |
| Programs to build binary packages work by extracting the |
| pre-installation and post-installation commands. Here is one way of |
| extracting the pre-installation commands (the `-s' option to `make' is |
| needed to silence messages about entering subdirectories): |
| |
| make -s -n install -o all \ |
| PRE_INSTALL=pre-install \ |
| POST_INSTALL=post-install \ |
| NORMAL_INSTALL=normal-install \ |
| | gawk -f pre-install.awk |
| |
| where the file `pre-install.awk' could contain this: |
| |
| $0 ~ /^(normal-install|post-install)[ \t]*$/ {on = 0} |
| on {print $0} |
| $0 ~ /^pre-install[ \t]*$/ {on = 1} |
| |
| |
| File: make.info, Node: Quick Reference, Next: Error Messages, Prev: Makefile Conventions, Up: Top |
| |
| Appendix A Quick Reference |
| ************************** |
| |
| This appendix summarizes the directives, text manipulation functions, |
| and special variables which GNU `make' understands. *Note Special |
| Targets::, *Note Catalogue of Built-In Rules: Catalogue of Rules, and |
| *Note Summary of Options: Options Summary, for other summaries. |
| |
| Here is a summary of the directives GNU `make' recognizes: |
| |
| `define VARIABLE' |
| `define VARIABLE =' |
| `define VARIABLE :=' |
| `define VARIABLE ::=' |
| `define VARIABLE +=' |
| `define VARIABLE ?=' |
| `endef' |
| Define multi-line variables. |
| *Note Multi-Line::. |
| |
| `undefine VARIABLE' |
| Undefining variables. |
| *Note Undefine Directive::. |
| |
| `ifdef VARIABLE' |
| `ifndef VARIABLE' |
| `ifeq (A,B)' |
| `ifeq "A" "B"' |
| `ifeq 'A' 'B'' |
| `ifneq (A,B)' |
| `ifneq "A" "B"' |
| `ifneq 'A' 'B'' |
| `else' |
| `endif' |
| Conditionally evaluate part of the makefile. |
| *Note Conditionals::. |
| |
| `include FILE' |
| `-include FILE' |
| `sinclude FILE' |
| Include another makefile. |
| *Note Including Other Makefiles: Include. |
| |
| `override VARIABLE-ASSIGNMENT' |
| Define a variable, overriding any previous definition, even one |
| from the command line. |
| *Note The `override' Directive: Override Directive. |
| |
| `export' |
| Tell `make' to export all variables to child processes by default. |
| *Note Communicating Variables to a Sub-`make': Variables/Recursion. |
| |
| `export VARIABLE' |
| `export VARIABLE-ASSIGNMENT' |
| `unexport VARIABLE' |
| Tell `make' whether or not to export a particular variable to child |
| processes. |
| *Note Communicating Variables to a Sub-`make': Variables/Recursion. |
| |
| `private VARIABLE-ASSIGNMENT' |
| Do not allow this variable assignment to be inherited by |
| prerequisites. |
| *Note Suppressing Inheritance::. |
| |
| `vpath PATTERN PATH' |
| Specify a search path for files matching a `%' pattern. |
| *Note The `vpath' Directive: Selective Search. |
| |
| `vpath PATTERN' |
| Remove all search paths previously specified for PATTERN. |
| |
| `vpath' |
| Remove all search paths previously specified in any `vpath' |
| directive. |
| |
| Here is a summary of the built-in functions (*note Functions::): |
| |
| `$(subst FROM,TO,TEXT)' |
| Replace FROM with TO in TEXT. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(patsubst PATTERN,REPLACEMENT,TEXT)' |
| Replace words matching PATTERN with REPLACEMENT in TEXT. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(strip STRING)' |
| Remove excess whitespace characters from STRING. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(findstring FIND,TEXT)' |
| Locate FIND in TEXT. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(filter PATTERN...,TEXT)' |
| Select words in TEXT that match one of the PATTERN words. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(filter-out PATTERN...,TEXT)' |
| Select words in TEXT that _do not_ match any of the PATTERN words. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(sort LIST)' |
| Sort the words in LIST lexicographically, removing duplicates. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(word N,TEXT)' |
| Extract the Nth word (one-origin) of TEXT. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(words TEXT)' |
| Count the number of words in TEXT. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(wordlist S,E,TEXT)' |
| Returns the list of words in TEXT from S to E. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(firstword NAMES...)' |
| Extract the first word of NAMES. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(lastword NAMES...)' |
| Extract the last word of NAMES. |
| *Note Functions for String Substitution and Analysis: Text |
| Functions. |
| |
| `$(dir NAMES...)' |
| Extract the directory part of each file name. |
| *Note Functions for File Names: File Name Functions. |
| |
| `$(notdir NAMES...)' |
| Extract the non-directory part of each file name. |
| *Note Functions for File Names: File Name Functions. |
| |
| `$(suffix NAMES...)' |
| Extract the suffix (the last `.' and following characters) of each |
| file name. |
| *Note Functions for File Names: File Name Functions. |
| |
| `$(basename NAMES...)' |
| Extract the base name (name without suffix) of each file name. |
| *Note Functions for File Names: File Name Functions. |
| |
| `$(addsuffix SUFFIX,NAMES...)' |
| Append SUFFIX to each word in NAMES. |
| *Note Functions for File Names: File Name Functions. |
| |
| `$(addprefix PREFIX,NAMES...)' |
| Prepend PREFIX to each word in NAMES. |
| *Note Functions for File Names: File Name Functions. |
| |
| `$(join LIST1,LIST2)' |
| Join two parallel lists of words. |
| *Note Functions for File Names: File Name Functions. |
| |
| `$(wildcard PATTERN...)' |
| Find file names matching a shell file name pattern (_not_ a `%' |
| pattern). |
| *Note The Function `wildcard': Wildcard Function. |
| |
| `$(realpath NAMES...)' |
| For each file name in NAMES, expand to an absolute name that does |
| not contain any `.', `..', nor symlinks. |
| *Note Functions for File Names: File Name Functions. |
| |
| `$(abspath NAMES...)' |
| For each file name in NAMES, expand to an absolute name that does |
| not contain any `.' or `..' components, but preserves symlinks. |
| *Note Functions for File Names: File Name Functions. |
| |
| `$(error TEXT...)' |
| When this function is evaluated, `make' generates a fatal error |
| with the message TEXT. |
| *Note Functions That Control Make: Make Control Functions. |
| |
| `$(warning TEXT...)' |
| When this function is evaluated, `make' generates a warning with |
| the message TEXT. |
| *Note Functions That Control Make: Make Control Functions. |
| |
| `$(shell COMMAND)' |
| Execute a shell command and return its output. |
| *Note The `shell' Function: Shell Function. |
| |
| `$(origin VARIABLE)' |
| Return a string describing how the `make' variable VARIABLE was |
| defined. |
| *Note The `origin' Function: Origin Function. |
| |
| `$(flavor VARIABLE)' |
| Return a string describing the flavor of the `make' variable |
| VARIABLE. |
| *Note The `flavor' Function: Flavor Function. |
| |
| `$(foreach VAR,WORDS,TEXT)' |
| Evaluate TEXT with VAR bound to each word in WORDS, and |
| concatenate the results. |
| *Note The `foreach' Function: Foreach Function. |
| |
| `$(if CONDITION,THEN-PART[,ELSE-PART])' |
| Evaluate the condition CONDITION; if it's non-empty substitute the |
| expansion of the THEN-PART otherwise substitute the expansion of |
| the ELSE-PART. |
| *Note Functions for Conditionals: Conditional Functions. |
| |
| `$(or CONDITION1[,CONDITION2[,CONDITION3...]])' |
| Evaluate each condition CONDITIONN one at a time; substitute the |
| first non-empty expansion. If all expansions are empty, substitute |
| the empty string. |
| *Note Functions for Conditionals: Conditional Functions. |
| |
| `$(and CONDITION1[,CONDITION2[,CONDITION3...]])' |
| Evaluate each condition CONDITIONN one at a time; if any expansion |
| results in the empty string substitute the empty string. If all |
| expansions result in a non-empty string, substitute the expansion |
| of the last CONDITION. |
| *Note Functions for Conditionals: Conditional Functions. |
| |
| `$(call VAR,PARAM,...)' |
| Evaluate the variable VAR replacing any references to `$(1)', |
| `$(2)' with the first, second, etc. PARAM values. |
| *Note The `call' Function: Call Function. |
| |
| `$(eval TEXT)' |
| Evaluate TEXT then read the results as makefile commands. Expands |
| to the empty string. |
| *Note The `eval' Function: Eval Function. |
| |
| `$(file OP FILENAME,TEXT)' |
| Expand the arguments, then open the file FILENAME using mode OP |
| and write TEXT to that file. |
| *Note The `file' Function: File Function. |
| |
| `$(value VAR)' |
| Evaluates to the contents of the variable VAR, with no expansion |
| performed on it. |
| *Note The `value' Function: Value Function. |
| |
| Here is a summary of the automatic variables. *Note Automatic |
| Variables::, for full information. |
| |
| `$@' |
| The file name of the target. |
| |
| `$%' |
| The target member name, when the target is an archive member. |
| |
| `$<' |
| The name of the first prerequisite. |
| |
| `$?' |
| The names of all the prerequisites that are newer than the target, |
| with spaces between them. For prerequisites which are archive |
| members, only the named member is used (*note Archives::). |
| |
| `$^' |
| `$+' |
| The names of all the prerequisites, with spaces between them. For |
| prerequisites which are archive members, only the named member is |
| used (*note Archives::). The value of `$^' omits duplicate |
| prerequisites, while `$+' retains them and preserves their order. |
| |
| `$*' |
| The stem with which an implicit rule matches (*note How Patterns |
| Match: Pattern Match.). |
| |
| `$(@D)' |
| `$(@F)' |
| The directory part and the file-within-directory part of `$@'. |
| |
| `$(*D)' |
| `$(*F)' |
| The directory part and the file-within-directory part of `$*'. |
| |
| `$(%D)' |
| `$(%F)' |
| The directory part and the file-within-directory part of `$%'. |
| |
| `$(<D)' |
| `$(<F)' |
| The directory part and the file-within-directory part of `$<'. |
| |
| `$(^D)' |
| `$(^F)' |
| The directory part and the file-within-directory part of `$^'. |
| |
| `$(+D)' |
| `$(+F)' |
| The directory part and the file-within-directory part of `$+'. |
| |
| `$(?D)' |
| `$(?F)' |
| The directory part and the file-within-directory part of `$?'. |
| |
| These variables are used specially by GNU `make': |
| |
| `MAKEFILES' |
| Makefiles to be read on every invocation of `make'. |
| *Note The Variable `MAKEFILES': MAKEFILES Variable. |
| |
| `VPATH' |
| Directory search path for files not found in the current directory. |
| *Note `VPATH' Search Path for All Prerequisites: General Search. |
| |
| `SHELL' |
| The name of the system default command interpreter, usually |
| `/bin/sh'. You can set `SHELL' in the makefile to change the |
| shell used to run recipes. *Note Recipe Execution: Execution. |
| The `SHELL' variable is handled specially when importing from and |
| exporting to the environment. *Note Choosing the Shell::. |
| |
| `MAKESHELL' |
| On MS-DOS only, the name of the command interpreter that is to be |
| used by `make'. This value takes precedence over the value of |
| `SHELL'. *Note MAKESHELL variable: Execution. |
| |
| `MAKE' |
| The name with which `make' was invoked. Using this variable in |
| recipes has special meaning. *Note How the `MAKE' Variable Works: |
| MAKE Variable. |
| |
| `MAKE_VERSION' |
| The built-in variable `MAKE_VERSION' expands to the version number |
| of the GNU `make' program. |
| |
| `MAKE_HOST' |
| The built-in variable `MAKE_HOST' expands to a string representing |
| the host that GNU `make' was built to run on. |
| |
| `MAKELEVEL' |
| The number of levels of recursion (sub-`make's). |
| *Note Variables/Recursion::. |
| |
| `MAKEFLAGS' |
| The flags given to `make'. You can set this in the environment or |
| a makefile to set flags. |
| *Note Communicating Options to a Sub-`make': Options/Recursion. |
| |
| It is _never_ appropriate to use `MAKEFLAGS' directly in a recipe |
| line: its contents may not be quoted correctly for use in the |
| shell. Always allow recursive `make''s to obtain these values |
| through the environment from its parent. |
| |
| `GNUMAKEFLAGS' |
| Other flags parsed by `make'. You can set this in the environment |
| or a makefile to set `make' command-line flags. GNU `make' never |
| sets this variable itself. This variable is only needed if you'd |
| like to set GNU `make'-specific flags in a POSIX-compliant |
| makefile. This variable will be seen by GNU `make' and ignored by |
| other `make' implementations. It's not needed if you only use GNU |
| `make'; just use `MAKEFLAGS' directly. *Note Communicating |
| Options to a Sub-`make': Options/Recursion. |
| |
| `MAKECMDGOALS' |
| The targets given to `make' on the command line. Setting this |
| variable has no effect on the operation of `make'. |
| *Note Arguments to Specify the Goals: Goals. |
| |
| `CURDIR' |
| Set to the absolute pathname of the current working directory |
| (after all `-C' options are processed, if any). Setting this |
| variable has no effect on the operation of `make'. |
| *Note Recursive Use of `make': Recursion. |
| |
| `SUFFIXES' |
| The default list of suffixes before `make' reads any makefiles. |
| |
| `.LIBPATTERNS' |
| Defines the naming of the libraries `make' searches for, and their |
| order. |
| *Note Directory Search for Link Libraries: Libraries/Search. |
| |
| |
| File: make.info, Node: Error Messages, Next: Complex Makefile, Prev: Quick Reference, Up: Top |
| |
| Appendix B Errors Generated by Make |
| *********************************** |
| |
| Here is a list of the more common errors you might see generated by |
| `make', and some information about what they mean and how to fix them. |
| |
| Sometimes `make' errors are not fatal, especially in the presence of |
| a `-' prefix on a recipe line, or the `-k' command line option. Errors |
| that are fatal are prefixed with the string `***'. |
| |
| Error messages are all either prefixed with the name of the program |
| (usually `make'), or, if the error is found in a makefile, the name of |
| the file and line number containing the problem. |
| |
| In the table below, these common prefixes are left off. |
| |
| `[FOO] Error NN' |
| `[FOO] SIGNAL DESCRIPTION' |
| These errors are not really `make' errors at all. They mean that a |
| program that `make' invoked as part of a recipe returned a non-0 |
| error code (`Error NN'), which `make' interprets as failure, or it |
| exited in some other abnormal fashion (with a signal of some |
| type). *Note Errors in Recipes: Errors. |
| |
| If no `***' is attached to the message, then the sub-process failed |
| but the rule in the makefile was prefixed with the `-' special |
| character, so `make' ignored the error. |
| |
| `missing separator. Stop.' |
| `missing separator (did you mean TAB instead of 8 spaces?). Stop.' |
| This means that `make' could not understand much of anything about |
| the makefile line it just read. GNU `make' looks for various |
| separators (`:', `=', recipe prefix characters, etc.) to indicate |
| what kind of line it's parsing. This message means it couldn't |
| find a valid one. |
| |
| One of the most common reasons for this message is that you (or |
| perhaps your oh-so-helpful editor, as is the case with many |
| MS-Windows editors) have attempted to indent your recipe lines |
| with spaces instead of a tab character. In this case, `make' will |
| use the second form of the error above. Remember that every line |
| in the recipe must begin with a tab character (unless you set |
| `.RECIPEPREFIX'; *note Special Variables::). Eight spaces do not |
| count. *Note Rule Syntax::. |
| |
| `recipe commences before first target. Stop.' |
| `missing rule before recipe. Stop.' |
| This means the first thing in the makefile seems to be part of a |
| recipe: it begins with a recipe prefix character and doesn't |
| appear to be a legal `make' directive (such as a variable |
| assignment). Recipes must always be associated with a target. |
| |
| The second form is generated if the line has a semicolon as the |
| first non-whitespace character; `make' interprets this to mean you |
| left out the "target: prerequisite" section of a rule. *Note Rule |
| Syntax::. |
| |
| `No rule to make target `XXX'.' |
| `No rule to make target `XXX', needed by `YYY'.' |
| This means that `make' decided it needed to build a target, but |
| then couldn't find any instructions in the makefile on how to do |
| that, either explicit or implicit (including in the default rules |
| database). |
| |
| If you want that file to be built, you will need to add a rule to |
| your makefile describing how that target can be built. Other |
| possible sources of this problem are typos in the makefile (if |
| that file name is wrong) or a corrupted source tree (if that file |
| is not supposed to be built, but rather only a prerequisite). |
| |
| `No targets specified and no makefile found. Stop.' |
| `No targets. Stop.' |
| The former means that you didn't provide any targets to be built |
| on the command line, and `make' couldn't find any makefiles to |
| read in. The latter means that some makefile was found, but it |
| didn't contain any default goal and none was given on the command |
| line. GNU `make' has nothing to do in these situations. *Note |
| Arguments to Specify the Makefile: Makefile Arguments. |
| |
| `Makefile `XXX' was not found.' |
| `Included makefile `XXX' was not found.' |
| A makefile specified on the command line (first form) or included |
| (second form) was not found. |
| |
| `warning: overriding recipe for target `XXX'' |
| `warning: ignoring old recipe for target `XXX'' |
| GNU `make' allows only one recipe to be specified per target |
| (except for double-colon rules). If you give a recipe for a target |
| which already has been defined to have one, this warning is issued |
| and the second recipe will overwrite the first. *Note Multiple |
| Rules for One Target: Multiple Rules. |
| |
| `Circular XXX <- YYY dependency dropped.' |
| This means that `make' detected a loop in the dependency graph: |
| after tracing the prerequisite YYY of target XXX, and its |
| prerequisites, etc., one of them depended on XXX again. |
| |
| `Recursive variable `XXX' references itself (eventually). Stop.' |
| This means you've defined a normal (recursive) `make' variable XXX |
| that, when it's expanded, will refer to itself (XXX). This is not |
| allowed; either use simply-expanded variables (`:=' or `::=') or |
| use the append operator (`+='). *Note How to Use Variables: Using |
| Variables. |
| |
| `Unterminated variable reference. Stop.' |
| This means you forgot to provide the proper closing parenthesis or |
| brace in your variable or function reference. |
| |
| `insufficient arguments to function `XXX'. Stop.' |
| This means you haven't provided the requisite number of arguments |
| for this function. See the documentation of the function for a |
| description of its arguments. *Note Functions for Transforming |
| Text: Functions. |
| |
| `missing target pattern. Stop.' |
| `multiple target patterns. Stop.' |
| `target pattern contains no `%'. Stop.' |
| `mixed implicit and static pattern rules. Stop.' |
| These errors are generated for malformed static pattern rules |
| (*note Syntax of Static Pattern Rules: Static Usage.). The first |
| means the target-pattern part of the rule is empty; the second |
| means there are multiple pattern characters (`%') in the |
| target-pattern part; the third means there are no pattern |
| characters in the target-pattern part; and the fourth means that |
| all three parts of the static pattern rule contain pattern |
| characters (`%')-the first part should not contain pattern |
| characters. |
| |
| If you see these errors and you aren't trying to create a static |
| pattern rule, check the value of any variables in your target and |
| prerequisite lists to be sure they do not contain colons. |
| |
| `warning: -jN forced in submake: disabling jobserver mode.' |
| This warning and the next are generated if `make' detects error |
| conditions related to parallel processing on systems where |
| sub-`make's can communicate (*note Communicating Options to a |
| Sub-`make': Options/Recursion.). This warning is generated if a |
| recursive invocation of a `make' process is forced to have `-jN' |
| in its argument list (where N is greater than one). This could |
| happen, for example, if you set the `MAKE' environment variable to |
| `make -j2'. In this case, the sub-`make' doesn't communicate with |
| other `make' processes and will simply pretend it has two jobs of |
| its own. |
| |
| `warning: jobserver unavailable: using -j1. Add `+' to parent make rule.' |
| In order for `make' processes to communicate, the parent will pass |
| information to the child. Since this could result in problems if |
| the child process isn't actually a `make', the parent will only do |
| this if it thinks the child is a `make'. The parent uses the |
| normal algorithms to determine this (*note How the `MAKE' Variable |
| Works: MAKE Variable.). If the makefile is constructed such that |
| the parent doesn't know the child is a `make' process, then the |
| child will receive only part of the information necessary. In |
| this case, the child will generate this warning message and |
| proceed with its build in a sequential manner. |
| |
| `warning: ignoring prerequisites on suffix rule definition' |
| According to POSIX, a suffix rule cannot contain prerequisites. |
| If a rule that could be a suffix rule has prerequisites it is |
| interpreted as a simple explicit rule, with an odd target name. |
| This requirement is obeyed when POSIX-conforming mode is enabled |
| (the `.POSIX' target is defined). In versions of GNU `make' prior |
| to 4.3, no warning was emitted and a suffix rule was created, |
| however all prerequisites were ignored and were not part of the |
| suffix rule. Starting with GNU `make' 4.3 the behavior is the |
| same, and in addition this warning is generated. In a future |
| version the POSIX-conforming behavior will be the only behavior: |
| no rule with a prerequisite can be suffix rule and this warning |
| will be removed. |
| |
| |
| |
| File: make.info, Node: Complex Makefile, Next: GNU Free Documentation License, Prev: Error Messages, Up: Top |
| |
| Appendix C Complex Makefile Example |
| *********************************** |
| |
| Here is the makefile for the GNU `tar' program. This is a moderately |
| complex makefile. The first line uses a `#!' setting to allow the |
| makefile to be executed directly. |
| |
| Because it is the first target, the default goal is `all'. An |
| interesting feature of this makefile is that `testpad.h' is a source |
| file automatically created by the `testpad' program, itself compiled |
| from `testpad.c'. |
| |
| If you type `make' or `make all', then `make' creates the `tar' |
| executable, the `rmt' daemon that provides remote tape access, and the |
| `tar.info' Info file. |
| |
| If you type `make install', then `make' not only creates `tar', |
| `rmt', and `tar.info', but also installs them. |
| |
| If you type `make clean', then `make' removes the `.o' files, and |
| the `tar', `rmt', `testpad', `testpad.h', and `core' files. |
| |
| If you type `make distclean', then `make' not only removes the same |
| files as does `make clean' but also the `TAGS', `Makefile', and |
| `config.status' files. (Although it is not evident, this makefile (and |
| `config.status') is generated by the user with the `configure' program, |
| which is provided in the `tar' distribution, but is not shown here.) |
| |
| If you type `make realclean', then `make' removes the same files as |
| does `make distclean' and also removes the Info files generated from |
| `tar.texinfo'. |
| |
| In addition, there are targets `shar' and `dist' that create |
| distribution kits. |
| |
| #!/usr/bin/make -f |
| # Generated automatically from Makefile.in by configure. |
| # Un*x Makefile for GNU tar program. |
| # Copyright (C) 1991 Free Software Foundation, Inc. |
| |
| # This program is free software; you can redistribute |
| # it and/or modify it under the terms of the GNU |
| # General Public License ... |
| ... |
| ... |
| |
| SHELL = /bin/sh |
| |
| #### Start of system configuration section. #### |
| |
| srcdir = . |
| |
| # If you use gcc, you should either run the |
| # fixincludes script that comes with it or else use |
| # gcc with the -traditional option. Otherwise ioctl |
| # calls will be compiled incorrectly on some systems. |
| CC = gcc -O |
| YACC = bison -y |
| INSTALL = /usr/local/bin/install -c |
| INSTALLDATA = /usr/local/bin/install -c -m 644 |
| |
| # Things you might add to DEFS: |
| # -DSTDC_HEADERS If you have ANSI C headers and |
| # libraries. |
| # -DPOSIX If you have POSIX.1 headers and |
| # libraries. |
| # -DBSD42 If you have sys/dir.h (unless |
| # you use -DPOSIX), sys/file.h, |
| # and st_blocks in `struct stat'. |
| # -DUSG If you have System V/ANSI C |
| # string and memory functions |
| # and headers, sys/sysmacros.h, |
| # fcntl.h, getcwd, no valloc, |
| # and ndir.h (unless |
| # you use -DDIRENT). |
| # -DNO_MEMORY_H If USG or STDC_HEADERS but do not |
| # include memory.h. |
| # -DDIRENT If USG and you have dirent.h |
| # instead of ndir.h. |
| # -DSIGTYPE=int If your signal handlers |
| # return int, not void. |
| # -DNO_MTIO If you lack sys/mtio.h |
| # (magtape ioctls). |
| # -DNO_REMOTE If you do not have a remote shell |
| # or rexec. |
| # -DUSE_REXEC To use rexec for remote tape |
| # operations instead of |
| # forking rsh or remsh. |
| # -DVPRINTF_MISSING If you lack vprintf function |
| # (but have _doprnt). |
| # -DDOPRNT_MISSING If you lack _doprnt function. |
| # Also need to define |
| # -DVPRINTF_MISSING. |
| # -DFTIME_MISSING If you lack ftime system call. |
| # -DSTRSTR_MISSING If you lack strstr function. |
| # -DVALLOC_MISSING If you lack valloc function. |
| # -DMKDIR_MISSING If you lack mkdir and |
| # rmdir system calls. |
| # -DRENAME_MISSING If you lack rename system call. |
| # -DFTRUNCATE_MISSING If you lack ftruncate |
| # system call. |
| # -DV7 On Version 7 Unix (not |
| # tested in a long time). |
| # -DEMUL_OPEN3 If you lack a 3-argument version |
| # of open, and want to emulate it |
| # with system calls you do have. |
| # -DNO_OPEN3 If you lack the 3-argument open |
| # and want to disable the tar -k |
| # option instead of emulating open. |
| # -DXENIX If you have sys/inode.h |
| # and need it 94 to be included. |
| |
| DEFS = -DSIGTYPE=int -DDIRENT -DSTRSTR_MISSING \ |
| -DVPRINTF_MISSING -DBSD42 |
| # Set this to rtapelib.o unless you defined NO_REMOTE, |
| # in which case make it empty. |
| RTAPELIB = rtapelib.o |
| LIBS = |
| DEF_AR_FILE = /dev/rmt8 |
| DEFBLOCKING = 20 |
| |
| CDEBUG = -g |
| CFLAGS = $(CDEBUG) -I. -I$(srcdir) $(DEFS) \ |
| -DDEF_AR_FILE=\"$(DEF_AR_FILE)\" \ |
| -DDEFBLOCKING=$(DEFBLOCKING) |
| LDFLAGS = -g |
| |
| prefix = /usr/local |
| # Prefix for each installed program, |
| # normally empty or `g'. |
| binprefix = |
| |
| # The directory to install tar in. |
| bindir = $(prefix)/bin |
| |
| # The directory to install the info files in. |
| infodir = $(prefix)/info |
| |
| #### End of system configuration section. #### |
| |
| SRCS_C = tar.c create.c extract.c buffer.c \ |
| getoldopt.c update.c gnu.c mangle.c \ |
| version.c list.c names.c diffarch.c \ |
| port.c wildmat.c getopt.c getopt1.c \ |
| regex.c |
| SRCS_Y = getdate.y |
| SRCS = $(SRCS_C) $(SRCS_Y) |
| OBJS = $(SRCS_C:.c=.o) $(SRCS_Y:.y=.o) $(RTAPELIB) |
| AUX = README COPYING ChangeLog Makefile.in \ |
| makefile.pc configure configure.in \ |
| tar.texinfo tar.info* texinfo.tex \ |
| tar.h port.h open3.h getopt.h regex.h \ |
| rmt.h rmt.c rtapelib.c alloca.c \ |
| msd_dir.h msd_dir.c tcexparg.c \ |
| level-0 level-1 backup-specs testpad.c |
| |
| .PHONY: all |
| all: tar rmt tar.info |
| |
| tar: $(OBJS) |
| $(CC) $(LDFLAGS) -o $@ $(OBJS) $(LIBS) |
| |
| rmt: rmt.c |
| $(CC) $(CFLAGS) $(LDFLAGS) -o $@ rmt.c |
| |
| tar.info: tar.texinfo |
| makeinfo tar.texinfo |
| |
| .PHONY: install |
| install: all |
| $(INSTALL) tar $(bindir)/$(binprefix)tar |
| -test ! -f rmt || $(INSTALL) rmt /etc/rmt |
| $(INSTALLDATA) $(srcdir)/tar.info* $(infodir) |
| |
| $(OBJS): tar.h port.h testpad.h |
| regex.o buffer.o tar.o: regex.h |
| # getdate.y has 8 shift/reduce conflicts. |
| |
| testpad.h: testpad |
| ./testpad |
| |
| testpad: testpad.o |
| $(CC) -o $@ testpad.o |
| |
| TAGS: $(SRCS) |
| etags $(SRCS) |
| |
| .PHONY: clean |
| clean: |
| rm -f *.o tar rmt testpad testpad.h core |
| |
| .PHONY: distclean |
| distclean: clean |
| rm -f TAGS Makefile config.status |
| |
| .PHONY: realclean |
| realclean: distclean |
| rm -f tar.info* |
| |
| .PHONY: shar |
| shar: $(SRCS) $(AUX) |
| shar $(SRCS) $(AUX) | compress \ |
| > tar-`sed -e '/version_string/!d' \ |
| -e 's/[^0-9.]*\([0-9.]*\).*/\1/' \ |
| -e q |
| version.c`.shar.Z |
| |
| .PHONY: dist |
| dist: $(SRCS) $(AUX) |
| echo tar-`sed \ |
| -e '/version_string/!d' \ |
| -e 's/[^0-9.]*\([0-9.]*\).*/\1/' \ |
| -e q |
| version.c` > .fname |
| -rm -rf `cat .fname` |
| mkdir `cat .fname` |
| ln $(SRCS) $(AUX) `cat .fname` |
| tar chZf `cat .fname`.tar.Z `cat .fname` |
| -rm -rf `cat .fname` .fname |
| |
| tar.zoo: $(SRCS) $(AUX) |
| -rm -rf tmp.dir |
| -mkdir tmp.dir |
| -rm tar.zoo |
| for X in $(SRCS) $(AUX) ; do \ |
| echo $$X ; \ |
| sed 's/$$/^M/' $$X \ |
| > tmp.dir/$$X ; done |
| cd tmp.dir ; zoo aM ../tar.zoo * |
| -rm -rf tmp.dir |
| |
| |
| File: make.info, Node: GNU Free Documentation License, Next: Concept Index, Prev: Complex Makefile, Up: Top |
| |
| Appendix D GNU Free Documentation License |
| ***************************************** |
| |
| Version 1.3, 3 November 2008 |
| |
| Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. |
| `https://fsf.org/' |
| |
| Everyone is permitted to copy and distribute verbatim copies |
| of this license document, but changing it is not allowed. |
| |
| 0. PREAMBLE |
| |
| The purpose of this License is to make a manual, textbook, or other |
| functional and useful document "free" in the sense of freedom: to |
| assure everyone the effective freedom to copy and redistribute it, |
| with or without modifying it, either commercially or |
| noncommercially. Secondarily, this License preserves for the |
| author and publisher a way to get credit for their work, while not |
| being considered responsible for modifications made by others. |
| |
| This License is a kind of "copyleft", which means that derivative |
| works of the document must themselves be free in the same sense. |
| It complements the GNU General Public License, which is a copyleft |
| license designed for free software. |
| |
| We have designed this License in order to use it for manuals for |
| free software, because free software needs free documentation: a |
| free program should come with manuals providing the same freedoms |
| that the software does. But this License is not limited to |
| software manuals; it can be used for any textual work, regardless |
| of subject matter or whether it is published as a printed book. |
| We recommend this License principally for works whose purpose is |
| instruction or reference. |
| |
| 1. APPLICABILITY AND DEFINITIONS |
| |
| This License applies to any manual or other work, in any medium, |
| that contains a notice placed by the copyright holder saying it |
| can be distributed under the terms of this License. Such a notice |
| grants a world-wide, royalty-free license, unlimited in duration, |
| to use that work under the conditions stated herein. The |
| "Document", below, refers to any such manual or work. Any member |
| of the public is a licensee, and is addressed as "you". You |
| accept the license if you copy, modify or distribute the work in a |
| way requiring permission under copyright law. |
| |
| A "Modified Version" of the Document means any work containing the |
| Document or a portion of it, either copied verbatim, or with |
| modifications and/or translated into another language. |
| |
| A "Secondary Section" is a named appendix or a front-matter section |
| of the Document that deals exclusively with the relationship of the |
| publishers or authors of the Document to the Document's overall |
| subject (or to related matters) and contains nothing that could |
| fall directly within that overall subject. (Thus, if the Document |
| is in part a textbook of mathematics, a Secondary Section may not |
| explain any mathematics.) The relationship could be a matter of |
| historical connection with the subject or with related matters, or |
| of legal, commercial, philosophical, ethical or political position |
| regarding them. |
| |
| The "Invariant Sections" are certain Secondary Sections whose |
| titles are designated, as being those of Invariant Sections, in |
| the notice that says that the Document is released under this |
| License. If a section does not fit the above definition of |
| Secondary then it is not allowed to be designated as Invariant. |
| The Document may contain zero Invariant Sections. If the Document |
| does not identify any Invariant Sections then there are none. |
| |
| The "Cover Texts" are certain short passages of text that are |
| listed, as Front-Cover Texts or Back-Cover Texts, in the notice |
| that says that the Document is released under this License. A |
| Front-Cover Text may be at most 5 words, and a Back-Cover Text may |
| be at most 25 words. |
| |
| A "Transparent" copy of the Document means a machine-readable copy, |
| represented in a format whose specification is available to the |
| general public, that is suitable for revising the document |
| straightforwardly with generic text editors or (for images |
| composed of pixels) generic paint programs or (for drawings) some |
| widely available drawing editor, and that is suitable for input to |
| text formatters or for automatic translation to a variety of |
| formats suitable for input to text formatters. A copy made in an |
| otherwise Transparent file format whose markup, or absence of |
| markup, has been arranged to thwart or discourage subsequent |
| modification by readers is not Transparent. An image format is |
| not Transparent if used for any substantial amount of text. A |
| copy that is not "Transparent" is called "Opaque". |
| |
| Examples of suitable formats for Transparent copies include plain |
| ASCII without markup, Texinfo input format, LaTeX input format, |
| SGML or XML using a publicly available DTD, and |
| standard-conforming simple HTML, PostScript or PDF designed for |
| human modification. Examples of transparent image formats include |
| PNG, XCF and JPG. Opaque formats include proprietary formats that |
| can be read and edited only by proprietary word processors, SGML or |
| XML for which the DTD and/or processing tools are not generally |
| available, and the machine-generated HTML, PostScript or PDF |
| produced by some word processors for output purposes only. |
| |
| The "Title Page" means, for a printed book, the title page itself, |
| plus such following pages as are needed to hold, legibly, the |
| material this License requires to appear in the title page. For |
| works in formats which do not have any title page as such, "Title |
| Page" means the text near the most prominent appearance of the |
| work's title, preceding the beginning of the body of the text. |
| |
| The "publisher" means any person or entity that distributes copies |
| of the Document to the public. |
| |
| A section "Entitled XYZ" means a named subunit of the Document |
| whose title either is precisely XYZ or contains XYZ in parentheses |
| following text that translates XYZ in another language. (Here XYZ |
| stands for a specific section name mentioned below, such as |
| "Acknowledgements", "Dedications", "Endorsements", or "History".) |
| To "Preserve the Title" of such a section when you modify the |
| Document means that it remains a section "Entitled XYZ" according |
| to this definition. |
| |
| The Document may include Warranty Disclaimers next to the notice |
| which states that this License applies to the Document. These |
| Warranty Disclaimers are considered to be included by reference in |
| this License, but only as regards disclaiming warranties: any other |
| implication that these Warranty Disclaimers may have is void and |
| has no effect on the meaning of this License. |
| |
| 2. VERBATIM COPYING |
| |
| You may copy and distribute the Document in any medium, either |
| commercially or noncommercially, provided that this License, the |
| copyright notices, and the license notice saying this License |
| applies to the Document are reproduced in all copies, and that you |
| add no other conditions whatsoever to those of this License. You |
| may not use technical measures to obstruct or control the reading |
| or further copying of the copies you make or distribute. However, |
| you may accept compensation in exchange for copies. If you |
| distribute a large enough number of copies you must also follow |
| the conditions in section 3. |
| |
| You may also lend copies, under the same conditions stated above, |
| and you may publicly display copies. |
| |
| 3. COPYING IN QUANTITY |
| |
| If you publish printed copies (or copies in media that commonly |
| have printed covers) of the Document, numbering more than 100, and |
| the Document's license notice requires Cover Texts, you must |
| enclose the copies in covers that carry, clearly and legibly, all |
| these Cover Texts: Front-Cover Texts on the front cover, and |
| Back-Cover Texts on the back cover. Both covers must also clearly |
| and legibly identify you as the publisher of these copies. The |
| front cover must present the full title with all words of the |
| title equally prominent and visible. You may add other material |
| on the covers in addition. Copying with changes limited to the |
| covers, as long as they preserve the title of the Document and |
| satisfy these conditions, can be treated as verbatim copying in |
| other respects. |
| |
| If the required texts for either cover are too voluminous to fit |
| legibly, you should put the first ones listed (as many as fit |
| reasonably) on the actual cover, and continue the rest onto |
| adjacent pages. |
| |
| If you publish or distribute Opaque copies of the Document |
| numbering more than 100, you must either include a |
| machine-readable Transparent copy along with each Opaque copy, or |
| state in or with each Opaque copy a computer-network location from |
| which the general network-using public has access to download |
| using public-standard network protocols a complete Transparent |
| copy of the Document, free of added material. If you use the |
| latter option, you must take reasonably prudent steps, when you |
| begin distribution of Opaque copies in quantity, to ensure that |
| this Transparent copy will remain thus accessible at the stated |
| location until at least one year after the last time you |
| distribute an Opaque copy (directly or through your agents or |
| retailers) of that edition to the public. |
| |
| It is requested, but not required, that you contact the authors of |
| the Document well before redistributing any large number of |
| copies, to give them a chance to provide you with an updated |
| version of the Document. |
| |
| 4. MODIFICATIONS |
| |
| You may copy and distribute a Modified Version of the Document |
| under the conditions of sections 2 and 3 above, provided that you |
| release the Modified Version under precisely this License, with |
| the Modified Version filling the role of the Document, thus |
| licensing distribution and modification of the Modified Version to |
| whoever possesses a copy of it. In addition, you must do these |
| things in the Modified Version: |
| |
| A. Use in the Title Page (and on the covers, if any) a title |
| distinct from that of the Document, and from those of |
| previous versions (which should, if there were any, be listed |
| in the History section of the Document). You may use the |
| same title as a previous version if the original publisher of |
| that version gives permission. |
| |
| B. List on the Title Page, as authors, one or more persons or |
| entities responsible for authorship of the modifications in |
| the Modified Version, together with at least five of the |
| principal authors of the Document (all of its principal |
| authors, if it has fewer than five), unless they release you |
| from this requirement. |
| |
| C. State on the Title page the name of the publisher of the |
| Modified Version, as the publisher. |
| |
| D. Preserve all the copyright notices of the Document. |
| |
| E. Add an appropriate copyright notice for your modifications |
| adjacent to the other copyright notices. |
| |
| F. Include, immediately after the copyright notices, a license |
| notice giving the public permission to use the Modified |
| Version under the terms of this License, in the form shown in |
| the Addendum below. |
| |
| G. Preserve in that license notice the full lists of Invariant |
| Sections and required Cover Texts given in the Document's |
| license notice. |
| |
| H. Include an unaltered copy of this License. |
| |
| I. Preserve the section Entitled "History", Preserve its Title, |
| and add to it an item stating at least the title, year, new |
| authors, and publisher of the Modified Version as given on |
| the Title Page. If there is no section Entitled "History" in |
| the Document, create one stating the title, year, authors, |
| and publisher of the Document as given on its Title Page, |
| then add an item describing the Modified Version as stated in |
| the previous sentence. |
| |
| J. Preserve the network location, if any, given in the Document |
| for public access to a Transparent copy of the Document, and |
| likewise the network locations given in the Document for |
| previous versions it was based on. These may be placed in |
| the "History" section. You may omit a network location for a |
| work that was published at least four years before the |
| Document itself, or if the original publisher of the version |
| it refers to gives permission. |
| |
| K. For any section Entitled "Acknowledgements" or "Dedications", |
| Preserve the Title of the section, and preserve in the |
| section all the substance and tone of each of the contributor |
| acknowledgements and/or dedications given therein. |
| |
| L. Preserve all the Invariant Sections of the Document, |
| unaltered in their text and in their titles. Section numbers |
| or the equivalent are not considered part of the section |
| titles. |
| |
| M. Delete any section Entitled "Endorsements". Such a section |
| may not be included in the Modified Version. |
| |
| N. Do not retitle any existing section to be Entitled |
| "Endorsements" or to conflict in title with any Invariant |
| Section. |
| |
| O. Preserve any Warranty Disclaimers. |
| |
| If the Modified Version includes new front-matter sections or |
| appendices that qualify as Secondary Sections and contain no |
| material copied from the Document, you may at your option |
| designate some or all of these sections as invariant. To do this, |
| add their titles to the list of Invariant Sections in the Modified |
| Version's license notice. These titles must be distinct from any |
| other section titles. |
| |
| You may add a section Entitled "Endorsements", provided it contains |
| nothing but endorsements of your Modified Version by various |
| parties--for example, statements of peer review or that the text |
| has been approved by an organization as the authoritative |
| definition of a standard. |
| |
| You may add a passage of up to five words as a Front-Cover Text, |
| and a passage of up to 25 words as a Back-Cover Text, to the end |
| of the list of Cover Texts in the Modified Version. Only one |
| passage of Front-Cover Text and one of Back-Cover Text may be |
| added by (or through arrangements made by) any one entity. If the |
| Document already includes a cover text for the same cover, |
| previously added by you or by arrangement made by the same entity |
| you are acting on behalf of, you may not add another; but you may |
| replace the old one, on explicit permission from the previous |
| publisher that added the old one. |
| |
| The author(s) and publisher(s) of the Document do not by this |
| License give permission to use their names for publicity for or to |
| assert or imply endorsement of any Modified Version. |
| |
| 5. COMBINING DOCUMENTS |
| |
| You may combine the Document with other documents released under |
| this License, under the terms defined in section 4 above for |
| modified versions, provided that you include in the combination |
| all of the Invariant Sections of all of the original documents, |
| unmodified, and list them all as Invariant Sections of your |
| combined work in its license notice, and that you preserve all |
| their Warranty Disclaimers. |
| |
| The combined work need only contain one copy of this License, and |
| multiple identical Invariant Sections may be replaced with a single |
| copy. If there are multiple Invariant Sections with the same name |
| but different contents, make the title of each such section unique |
| by adding at the end of it, in parentheses, the name of the |
| original author or publisher of that section if known, or else a |
| unique number. Make the same adjustment to the section titles in |
| the list of Invariant Sections in the license notice of the |
| combined work. |
| |
| In the combination, you must combine any sections Entitled |
| "History" in the various original documents, forming one section |
| Entitled "History"; likewise combine any sections Entitled |
| "Acknowledgements", and any sections Entitled "Dedications". You |
| must delete all sections Entitled "Endorsements." |
| |
| 6. COLLECTIONS OF DOCUMENTS |
| |
| You may make a collection consisting of the Document and other |
| documents released under this License, and replace the individual |
| copies of this License in the various documents with a single copy |
| that is included in the collection, provided that you follow the |
| rules of this License for verbatim copying of each of the |
| documents in all other respects. |
| |
| You may extract a single document from such a collection, and |
| distribute it individually under this License, provided you insert |
| a copy of this License into the extracted document, and follow |
| this License in all other respects regarding verbatim copying of |
| that document. |
| |
| 7. AGGREGATION WITH INDEPENDENT WORKS |
| |
| A compilation of the Document or its derivatives with other |
| separate and independent documents or works, in or on a volume of |
| a storage or distribution medium, is called an "aggregate" if the |
| copyright resulting from the compilation is not used to limit the |
| legal rights of the compilation's users beyond what the individual |
| works permit. When the Document is included in an aggregate, this |
| License does not apply to the other works in the aggregate which |
| are not themselves derivative works of the Document. |
| |
| If the Cover Text requirement of section 3 is applicable to these |
| copies of the Document, then if the Document is less than one half |
| of the entire aggregate, the Document's Cover Texts may be placed |
| on covers that bracket the Document within the aggregate, or the |
| electronic equivalent of covers if the Document is in electronic |
| form. Otherwise they must appear on printed covers that bracket |
| the whole aggregate. |
| |
| 8. TRANSLATION |
| |
| Translation is considered a kind of modification, so you may |
| distribute translations of the Document under the terms of section |
| 4. Replacing Invariant Sections with translations requires special |
| permission from their copyright holders, but you may include |
| translations of some or all Invariant Sections in addition to the |
| original versions of these Invariant Sections. You may include a |
| translation of this License, and all the license notices in the |
| Document, and any Warranty Disclaimers, provided that you also |
| include the original English version of this License and the |
| original versions of those notices and disclaimers. In case of a |
| disagreement between the translation and the original version of |
| this License or a notice or disclaimer, the original version will |
| prevail. |
| |
| If a section in the Document is Entitled "Acknowledgements", |
| "Dedications", or "History", the requirement (section 4) to |
| Preserve its Title (section 1) will typically require changing the |
| actual title. |
| |
| 9. TERMINATION |
| |
| You may not copy, modify, sublicense, or distribute the Document |
| except as expressly provided under this License. Any attempt |
| otherwise to copy, modify, sublicense, or distribute it is void, |
| and will automatically terminate your rights under this License. |
| |
| However, if you cease all violation of this License, then your |
| license from a particular copyright holder is reinstated (a) |
| provisionally, unless and until the copyright holder explicitly |
| and finally terminates your license, and (b) permanently, if the |
| copyright holder fails to notify you of the violation by some |
| reasonable means prior to 60 days after the cessation. |
| |
| Moreover, your license from a particular copyright holder is |
| reinstated permanently if the copyright holder notifies you of the |
| violation by some reasonable means, this is the first time you have |
| received notice of violation of this License (for any work) from |
| that copyright holder, and you cure the violation prior to 30 days |
| after your receipt of the notice. |
| |
| Termination of your rights under this section does not terminate |
| the licenses of parties who have received copies or rights from |
| you under this License. If your rights have been terminated and |
| not permanently reinstated, receipt of a copy of some or all of |
| the same material does not give you any rights to use it. |
| |
| 10. FUTURE REVISIONS OF THIS LICENSE |
| |
| The Free Software Foundation may publish new, revised versions of |
| the GNU Free Documentation License from time to time. Such new |
| versions will be similar in spirit to the present version, but may |
| differ in detail to address new problems or concerns. See |
| `https://www.gnu.org/copyleft/'. |
| |
| Each version of the License is given a distinguishing version |
| number. If the Document specifies that a particular numbered |
| version of this License "or any later version" applies to it, you |
| have the option of following the terms and conditions either of |
| that specified version or of any later version that has been |
| published (not as a draft) by the Free Software Foundation. If |
| the Document does not specify a version number of this License, |
| you may choose any version ever published (not as a draft) by the |
| Free Software Foundation. If the Document specifies that a proxy |
| can decide which future versions of this License can be used, that |
| proxy's public statement of acceptance of a version permanently |
| authorizes you to choose that version for the Document. |
| |
| 11. RELICENSING |
| |
| "Massive Multiauthor Collaboration Site" (or "MMC Site") means any |
| World Wide Web server that publishes copyrightable works and also |
| provides prominent facilities for anybody to edit those works. A |
| public wiki that anybody can edit is an example of such a server. |
| A "Massive Multiauthor Collaboration" (or "MMC") contained in the |
| site means any set of copyrightable works thus published on the MMC |
| site. |
| |
| "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 |
| license published by Creative Commons Corporation, a not-for-profit |
| corporation with a principal place of business in San Francisco, |
| California, as well as future copyleft versions of that license |
| published by that same organization. |
| |
| "Incorporate" means to publish or republish a Document, in whole or |
| in part, as part of another Document. |
| |
| An MMC is "eligible for relicensing" if it is licensed under this |
| License, and if all works that were first published under this |
| License somewhere other than this MMC, and subsequently |
| incorporated in whole or in part into the MMC, (1) had no cover |
| texts or invariant sections, and (2) were thus incorporated prior |
| to November 1, 2008. |
| |
| The operator of an MMC Site may republish an MMC contained in the |
| site under CC-BY-SA on the same site at any time before August 1, |
| 2009, provided the MMC is eligible for relicensing. |
| |
| |
| ADDENDUM: How to use this License for your documents |
| ==================================================== |
| |
| To use this License in a document you have written, include a copy of |
| the License in the document and put the following copyright and license |
| notices just after the title page: |
| |
| Copyright (C) YEAR YOUR NAME. |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.3 |
| or any later version published by the Free Software Foundation; |
| with no Invariant Sections, no Front-Cover Texts, and no Back-Cover |
| Texts. A copy of the license is included in the section entitled ``GNU |
| Free Documentation License''. |
| |
| If you have Invariant Sections, Front-Cover Texts and Back-Cover |
| Texts, replace the "with...Texts." line with this: |
| |
| with the Invariant Sections being LIST THEIR TITLES, with |
| the Front-Cover Texts being LIST, and with the Back-Cover Texts |
| being LIST. |
| |
| If you have Invariant Sections without Cover Texts, or some other |
| combination of the three, merge those two alternatives to suit the |
| situation. |
| |
| If your document contains nontrivial examples of program code, we |
| recommend releasing these examples in parallel under your choice of |
| free software license, such as the GNU General Public License, to |
| permit their use in free software. |
| |
| |
| File: make.info, Node: Concept Index, Next: Name Index, Prev: GNU Free Documentation License, Up: Top |
| |
| Index of Concepts |
| ***************** |
| |
| [index] |
| * Menu: |
| |
| * !=: Setting. (line 6) |
| * !=, expansion: Reading Makefiles. (line 34) |
| * # (comments), in makefile: Makefile Contents. (line 42) |
| * # (comments), in recipes: Recipe Syntax. (line 29) |
| * #include: Automatic Prerequisites. |
| (line 16) |
| * $, in function call: Syntax of Functions. (line 6) |
| * $, in rules: Rule Syntax. (line 34) |
| * $, in variable name: Computed Names. (line 6) |
| * $, in variable reference: Reference. (line 6) |
| * %, in pattern rules: Pattern Intro. (line 9) |
| * %, quoting in patsubst: Text Functions. (line 26) |
| * %, quoting in static pattern: Static Usage. (line 37) |
| * %, quoting in vpath: Selective Search. (line 38) |
| * %, quoting with \ (backslash) <1>: Selective Search. (line 38) |
| * %, quoting with \ (backslash) <2>: Text Functions. (line 26) |
| * %, quoting with \ (backslash): Static Usage. (line 37) |
| * * (wildcard character): Wildcards. (line 6) |
| * +, and define: Canned Recipes. (line 49) |
| * +, and recipe execution: Instead of Execution. |
| (line 63) |
| * +, and recipes: MAKE Variable. (line 18) |
| * +=: Appending. (line 6) |
| * +=, expansion: Reading Makefiles. (line 34) |
| * ,v (RCS file extension): Catalogue of Rules. (line 164) |
| * - (in recipes): Errors. (line 19) |
| * -, and define: Canned Recipes. (line 49) |
| * --always-make: Options Summary. (line 15) |
| * --assume-new <1>: Instead of Execution. |
| (line 38) |
| * --assume-new: Options Summary. (line 278) |
| * --assume-new, and recursion: Options/Recursion. (line 22) |
| * --assume-old <1>: Avoiding Compilation. |
| (line 6) |
| * --assume-old: Options Summary. (line 161) |
| * --assume-old, and recursion: Options/Recursion. (line 22) |
| * --check-symlink-times: Options Summary. (line 143) |
| * --debug: Options Summary. (line 42) |
| * --directory <1>: Options Summary. (line 26) |
| * --directory: Recursion. (line 20) |
| * --directory, and --print-directory: -w Option. (line 20) |
| * --directory, and recursion: Options/Recursion. (line 22) |
| * --dry-run <1>: Instead of Execution. |
| (line 14) |
| * --dry-run <2>: Echoing. (line 18) |
| * --dry-run: Options Summary. (line 153) |
| * --environment-overrides: Options Summary. (line 83) |
| * --eval: Options Summary. (line 90) |
| * --file <1>: Options Summary. (line 97) |
| * --file <2>: Makefile Names. (line 23) |
| * --file: Makefile Arguments. (line 6) |
| * --file, and recursion: Options/Recursion. (line 22) |
| * --help: Options Summary. (line 103) |
| * --ignore-errors <1>: Options Summary. (line 107) |
| * --ignore-errors: Errors. (line 30) |
| * --include-dir <1>: Include. (line 53) |
| * --include-dir: Options Summary. (line 112) |
| * --jobs <1>: Options Summary. (line 119) |
| * --jobs: Parallel. (line 6) |
| * --jobs, and recursion: Options/Recursion. (line 25) |
| * --just-print <1>: Options Summary. (line 152) |
| * --just-print <2>: Instead of Execution. |
| (line 14) |
| * --just-print: Echoing. (line 18) |
| * --keep-going <1>: Errors. (line 46) |
| * --keep-going <2>: Options Summary. (line 128) |
| * --keep-going: Testing. (line 16) |
| * --load-average <1>: Options Summary. (line 135) |
| * --load-average: Parallel. (line 35) |
| * --makefile <1>: Makefile Arguments. (line 6) |
| * --makefile <2>: Options Summary. (line 98) |
| * --makefile: Makefile Names. (line 23) |
| * --max-load <1>: Parallel. (line 35) |
| * --max-load: Options Summary. (line 136) |
| * --new-file <1>: Instead of Execution. |
| (line 38) |
| * --new-file: Options Summary. (line 277) |
| * --new-file, and recursion: Options/Recursion. (line 22) |
| * --no-builtin-rules: Options Summary. (line 205) |
| * --no-builtin-variables: Options Summary. (line 218) |
| * --no-keep-going: Options Summary. (line 233) |
| * --no-print-directory <1>: Options Summary. (line 269) |
| * --no-print-directory: -w Option. (line 20) |
| * --old-file <1>: Avoiding Compilation. |
| (line 6) |
| * --old-file: Options Summary. (line 160) |
| * --old-file, and recursion: Options/Recursion. (line 22) |
| * --output-sync <1>: Options Summary. (line 169) |
| * --output-sync: Parallel Output. (line 11) |
| * --print-data-base: Options Summary. (line 185) |
| * --print-directory: Options Summary. (line 261) |
| * --print-directory, and --directory: -w Option. (line 20) |
| * --print-directory, and recursion: -w Option. (line 20) |
| * --print-directory, disabling: -w Option. (line 20) |
| * --question <1>: Instead of Execution. |
| (line 30) |
| * --question: Options Summary. (line 197) |
| * --quiet <1>: Echoing. (line 24) |
| * --quiet: Options Summary. (line 228) |
| * --recon <1>: Options Summary. (line 154) |
| * --recon <2>: Echoing. (line 18) |
| * --recon: Instead of Execution. |
| (line 14) |
| * --silent <1>: Options Summary. (line 227) |
| * --silent: Echoing. (line 24) |
| * --stop: Options Summary. (line 234) |
| * --touch <1>: Options Summary. (line 242) |
| * --touch: Instead of Execution. |
| (line 23) |
| * --touch, and recursion: MAKE Variable. (line 34) |
| * --trace: Options Summary. (line 248) |
| * --version: Options Summary. (line 256) |
| * --warn-undefined-variables: Options Summary. (line 287) |
| * --what-if <1>: Options Summary. (line 276) |
| * --what-if: Instead of Execution. |
| (line 38) |
| * -B: Options Summary. (line 14) |
| * -b: Options Summary. (line 9) |
| * -C <1>: Recursion. (line 20) |
| * -C: Options Summary. (line 25) |
| * -C, and -w: -w Option. (line 20) |
| * -C, and recursion: Options/Recursion. (line 22) |
| * -d: Options Summary. (line 33) |
| * -E: Options Summary. (line 88) |
| * -e: Options Summary. (line 82) |
| * -e (shell flag): Automatic Prerequisites. |
| (line 66) |
| * -f <1>: Options Summary. (line 96) |
| * -f <2>: Makefile Names. (line 23) |
| * -f: Makefile Arguments. (line 6) |
| * -f, and recursion: Options/Recursion. (line 22) |
| * -h: Options Summary. (line 102) |
| * -I <1>: Include. (line 53) |
| * -I: Options Summary. (line 111) |
| * -i <1>: Errors. (line 30) |
| * -i: Options Summary. (line 106) |
| * -j <1>: Parallel. (line 6) |
| * -j: Options Summary. (line 118) |
| * -j, and archive update: Archive Pitfalls. (line 6) |
| * -j, and recursion: Options/Recursion. (line 25) |
| * -k <1>: Errors. (line 46) |
| * -k <2>: Testing. (line 16) |
| * -k: Options Summary. (line 127) |
| * -L: Options Summary. (line 142) |
| * -l: Options Summary. (line 134) |
| * -l (library search): Libraries/Search. (line 6) |
| * -l (load average): Parallel. (line 35) |
| * -m: Options Summary. (line 10) |
| * -M (to compiler): Automatic Prerequisites. |
| (line 18) |
| * -MM (to GNU compiler): Automatic Prerequisites. |
| (line 68) |
| * -n <1>: Instead of Execution. |
| (line 14) |
| * -n <2>: Options Summary. (line 151) |
| * -n: Echoing. (line 18) |
| * -O: Options Summary. (line 168) |
| * -o <1>: Avoiding Compilation. |
| (line 6) |
| * -o: Options Summary. (line 159) |
| * -O: Parallel Output. (line 11) |
| * -o, and recursion: Options/Recursion. (line 22) |
| * -p: Options Summary. (line 184) |
| * -q <1>: Instead of Execution. |
| (line 30) |
| * -q: Options Summary. (line 196) |
| * -r: Options Summary. (line 204) |
| * -R: Options Summary. (line 217) |
| * -S: Options Summary. (line 232) |
| * -s <1>: Echoing. (line 24) |
| * -s: Options Summary. (line 226) |
| * -t <1>: Options Summary. (line 241) |
| * -t: Instead of Execution. |
| (line 23) |
| * -t, and recursion: MAKE Variable. (line 34) |
| * -v: Options Summary. (line 255) |
| * -w: Options Summary. (line 260) |
| * -W <1>: Options Summary. (line 275) |
| * -W: Instead of Execution. |
| (line 38) |
| * -w, and -C: -w Option. (line 20) |
| * -w, and recursion: -w Option. (line 20) |
| * -W, and recursion: Options/Recursion. (line 22) |
| * -w, disabling: -w Option. (line 20) |
| * .a (archives): Archive Suffix Rules. |
| (line 6) |
| * .c: Catalogue of Rules. (line 35) |
| * .C: Catalogue of Rules. (line 39) |
| * .cc: Catalogue of Rules. (line 39) |
| * .ch: Catalogue of Rules. (line 151) |
| * .cpp: Catalogue of Rules. (line 39) |
| * .d: Automatic Prerequisites. |
| (line 81) |
| * .def: Catalogue of Rules. (line 74) |
| * .dvi: Catalogue of Rules. (line 151) |
| * .f: Catalogue of Rules. (line 49) |
| * .F: Catalogue of Rules. (line 49) |
| * .info: Catalogue of Rules. (line 158) |
| * .l: Catalogue of Rules. (line 124) |
| * .LIBPATTERNS, and link libraries: Libraries/Search. (line 6) |
| * .ln: Catalogue of Rules. (line 146) |
| * .mod: Catalogue of Rules. (line 74) |
| * .o: Catalogue of Rules. (line 86) |
| * .ONESHELL, use of: One Shell. (line 6) |
| * .p: Catalogue of Rules. (line 45) |
| * .PRECIOUS intermediate files: Chained Rules. (line 56) |
| * .r: Catalogue of Rules. (line 49) |
| * .S: Catalogue of Rules. (line 82) |
| * .s: Catalogue of Rules. (line 79) |
| * .sh: Catalogue of Rules. (line 180) |
| * .SHELLFLAGS, value of: Choosing the Shell. (line 6) |
| * .sym: Catalogue of Rules. (line 74) |
| * .tex: Catalogue of Rules. (line 151) |
| * .texi: Catalogue of Rules. (line 158) |
| * .texinfo: Catalogue of Rules. (line 158) |
| * .txinfo: Catalogue of Rules. (line 158) |
| * .w: Catalogue of Rules. (line 151) |
| * .web: Catalogue of Rules. (line 151) |
| * .y: Catalogue of Rules. (line 120) |
| * :: rules (double-colon): Double-Colon. (line 6) |
| * ::= <1>: Setting. (line 6) |
| * ::=: Flavors. (line 56) |
| * := <1>: Flavors. (line 56) |
| * :=: Setting. (line 6) |
| * = <1>: Setting. (line 6) |
| * =: Flavors. (line 10) |
| * =, expansion: Reading Makefiles. (line 34) |
| * ? (wildcard character): Wildcards. (line 6) |
| * ?= <1>: Setting. (line 6) |
| * ?=: Flavors. (line 133) |
| * ?=, expansion: Reading Makefiles. (line 34) |
| * @ (in recipes): Echoing. (line 6) |
| * @, and define: Canned Recipes. (line 49) |
| * [...] (wildcard characters): Wildcards. (line 6) |
| * \ (backslash), for continuation lines: Simple Makefile. (line 41) |
| * \ (backslash), in recipes: Splitting Recipe Lines. |
| (line 6) |
| * \ (backslash), to quote % <1>: Selective Search. (line 38) |
| * \ (backslash), to quote % <2>: Static Usage. (line 37) |
| * \ (backslash), to quote %: Text Functions. (line 26) |
| * __.SYMDEF: Archive Symbols. (line 6) |
| * abspath: File Name Functions. (line 121) |
| * algorithm for directory search: Search Algorithm. (line 6) |
| * all (standard target): Goals. (line 72) |
| * appending to variables: Appending. (line 6) |
| * ar: Implicit Variables. (line 40) |
| * archive: Archives. (line 6) |
| * archive member targets: Archive Members. (line 6) |
| * archive symbol directory updating: Archive Symbols. (line 6) |
| * archive, and -j: Archive Pitfalls. (line 6) |
| * archive, and parallel execution: Archive Pitfalls. (line 6) |
| * archive, suffix rule for: Archive Suffix Rules. |
| (line 6) |
| * Arg list too long: Options/Recursion. (line 57) |
| * arguments of functions: Syntax of Functions. (line 6) |
| * as <1>: Catalogue of Rules. (line 79) |
| * as: Implicit Variables. (line 43) |
| * assembly, rule to compile: Catalogue of Rules. (line 79) |
| * automatic generation of prerequisites <1>: Automatic Prerequisites. |
| (line 6) |
| * automatic generation of prerequisites: Include. (line 51) |
| * automatic variables: Automatic Variables. (line 6) |
| * automatic variables in prerequisites: Automatic Variables. (line 17) |
| * backquotes: Shell Function. (line 6) |
| * backslash (\), for continuation lines: Simple Makefile. (line 41) |
| * backslash (\), in recipes: Splitting Recipe Lines. |
| (line 6) |
| * backslash (\), to quote % <1>: Selective Search. (line 38) |
| * backslash (\), to quote % <2>: Text Functions. (line 26) |
| * backslash (\), to quote %: Static Usage. (line 37) |
| * backslash (\), to quote newlines: Splitting Lines. (line 6) |
| * backslashes in pathnames and wildcard expansion: Wildcard Pitfall. |
| (line 31) |
| * basename: File Name Functions. (line 57) |
| * binary packages: Install Command Categories. |
| (line 80) |
| * broken pipe: Parallel Input. (line 11) |
| * bugs, reporting: Bugs. (line 6) |
| * built-in special targets: Special Targets. (line 6) |
| * C++, rule to compile: Catalogue of Rules. (line 39) |
| * C, rule to compile: Catalogue of Rules. (line 35) |
| * canned recipes: Canned Recipes. (line 6) |
| * cc <1>: Implicit Variables. (line 46) |
| * cc: Catalogue of Rules. (line 35) |
| * cd (shell command) <1>: Execution. (line 12) |
| * cd (shell command): MAKE Variable. (line 16) |
| * chains of rules: Chained Rules. (line 6) |
| * check (standard target): Goals. (line 114) |
| * clean (standard target): Goals. (line 75) |
| * clean target <1>: Cleanup. (line 11) |
| * clean target: Simple Makefile. (line 85) |
| * cleaning up: Cleanup. (line 6) |
| * clobber (standard target): Goals. (line 86) |
| * co <1>: Implicit Variables. (line 66) |
| * co: Catalogue of Rules. (line 164) |
| * combining rules by prerequisite: Combine By Prerequisite. |
| (line 6) |
| * command expansion: Shell Function. (line 6) |
| * command line variable definitions, and recursion: Options/Recursion. |
| (line 17) |
| * command line variables: Overriding. (line 6) |
| * commands, sequences of: Canned Recipes. (line 6) |
| * comments, in makefile: Makefile Contents. (line 42) |
| * comments, in recipes: Recipe Syntax. (line 29) |
| * compatibility: Features. (line 6) |
| * compatibility in exporting: Variables/Recursion. (line 105) |
| * compilation, testing: Testing. (line 6) |
| * computed variable name: Computed Names. (line 6) |
| * conditional expansion: Conditional Functions. |
| (line 6) |
| * conditional variable assignment: Flavors. (line 133) |
| * conditionals: Conditionals. (line 6) |
| * continuation lines: Simple Makefile. (line 41) |
| * controlling make: Make Control Functions. |
| (line 6) |
| * conventions for makefiles: Makefile Conventions. |
| (line 6) |
| * convert guile types: Guile Types. (line 6) |
| * ctangle <1>: Implicit Variables. (line 103) |
| * ctangle: Catalogue of Rules. (line 151) |
| * cweave <1>: Implicit Variables. (line 97) |
| * cweave: Catalogue of Rules. (line 151) |
| * data base of make rules: Options Summary. (line 185) |
| * deducing recipes (implicit rules): make Deduces. (line 6) |
| * default directories for included makefiles: Include. (line 53) |
| * default goal <1>: Rules. (line 11) |
| * default goal: How Make Works. (line 11) |
| * default makefile name: Makefile Names. (line 6) |
| * default rules, last-resort: Last Resort. (line 6) |
| * define, expansion: Reading Makefiles. (line 34) |
| * defining variables verbatim: Multi-Line. (line 6) |
| * deletion of target files <1>: Interrupts. (line 6) |
| * deletion of target files: Errors. (line 63) |
| * directive: Makefile Contents. (line 28) |
| * directories, creating installation: Directory Variables. (line 20) |
| * directories, printing them: -w Option. (line 6) |
| * directories, updating archive symbol: Archive Symbols. (line 6) |
| * directory part: File Name Functions. (line 17) |
| * directory search (VPATH): Directory Search. (line 6) |
| * directory search (VPATH), and implicit rules: Implicit/Search. |
| (line 6) |
| * directory search (VPATH), and link libraries: Libraries/Search. |
| (line 6) |
| * directory search (VPATH), and recipes: Recipes/Search. (line 6) |
| * directory search algorithm: Search Algorithm. (line 6) |
| * directory search, traditional (GPATH): Search Algorithm. (line 42) |
| * dist (standard target): Goals. (line 106) |
| * distclean (standard target): Goals. (line 84) |
| * dollar sign ($), in function call: Syntax of Functions. (line 6) |
| * dollar sign ($), in rules: Rule Syntax. (line 34) |
| * dollar sign ($), in variable name: Computed Names. (line 6) |
| * dollar sign ($), in variable reference: Reference. (line 6) |
| * DOS, choosing a shell in: Choosing the Shell. (line 38) |
| * double-colon rules: Double-Colon. (line 6) |
| * duplicate words, removing: Text Functions. (line 155) |
| * E2BIG: Options/Recursion. (line 57) |
| * echoing of recipes: Echoing. (line 6) |
| * editor: Introduction. (line 22) |
| * Emacs (M-x compile): Errors. (line 61) |
| * empty recipes: Empty Recipes. (line 6) |
| * empty targets: Empty Targets. (line 6) |
| * environment: Environment. (line 6) |
| * environment, and recursion: Variables/Recursion. (line 6) |
| * environment, SHELL in: Choosing the Shell. (line 12) |
| * error, stopping on: Make Control Functions. |
| (line 11) |
| * errors (in recipes): Errors. (line 6) |
| * errors with wildcards: Wildcard Pitfall. (line 6) |
| * evaluating makefile syntax: Eval Function. (line 6) |
| * example of loaded objects: Loaded Object Example. |
| (line 6) |
| * example using Guile: Guile Example. (line 6) |
| * execution, in parallel: Parallel. (line 6) |
| * execution, instead of: Instead of Execution. |
| (line 6) |
| * execution, of recipes: Execution. (line 6) |
| * exit status (errors): Errors. (line 6) |
| * exit status of make: Running. (line 18) |
| * expansion, secondary: Secondary Expansion. (line 6) |
| * explicit rule, definition of: Makefile Contents. (line 10) |
| * explicit rule, expansion: Reading Makefiles. (line 93) |
| * explicit rules, secondary expansion of: Secondary Expansion. |
| (line 105) |
| * exporting variables: Variables/Recursion. (line 6) |
| * extensions, Guile: Guile Integration. (line 6) |
| * extensions, load directive: load Directive. (line 6) |
| * extensions, loading: Loading Objects. (line 6) |
| * f77 <1>: Implicit Variables. (line 57) |
| * f77: Catalogue of Rules. (line 49) |
| * FDL, GNU Free Documentation License: GNU Free Documentation License. |
| (line 6) |
| * features of GNU make: Features. (line 6) |
| * features, missing: Missing. (line 6) |
| * file name functions: File Name Functions. (line 6) |
| * file name of makefile: Makefile Names. (line 6) |
| * file name of makefile, how to specify: Makefile Names. (line 30) |
| * file name prefix, adding: File Name Functions. (line 79) |
| * file name suffix: File Name Functions. (line 43) |
| * file name suffix, adding: File Name Functions. (line 68) |
| * file name with wildcards: Wildcards. (line 6) |
| * file name, abspath of: File Name Functions. (line 121) |
| * file name, basename of: File Name Functions. (line 57) |
| * file name, directory part: File Name Functions. (line 17) |
| * file name, nondirectory part: File Name Functions. (line 27) |
| * file name, realpath of: File Name Functions. (line 114) |
| * file, reading from: File Function. (line 6) |
| * file, writing to: File Function. (line 6) |
| * files, assuming new: Instead of Execution. |
| (line 38) |
| * files, assuming old: Avoiding Compilation. |
| (line 6) |
| * files, avoiding recompilation of: Avoiding Compilation. |
| (line 6) |
| * files, intermediate: Chained Rules. (line 16) |
| * filtering out words: Text Functions. (line 132) |
| * filtering words: Text Functions. (line 114) |
| * finding strings: Text Functions. (line 103) |
| * flags: Options Summary. (line 6) |
| * flags for compilers: Implicit Variables. (line 6) |
| * flavor of variable: Flavor Function. (line 6) |
| * flavors of variables: Flavors. (line 6) |
| * FORCE: Force Targets. (line 6) |
| * force targets: Force Targets. (line 6) |
| * Fortran, rule to compile: Catalogue of Rules. (line 49) |
| * functions: Functions. (line 6) |
| * functions, for controlling make: Make Control Functions. |
| (line 6) |
| * functions, for file names: File Name Functions. (line 6) |
| * functions, for text: Text Functions. (line 6) |
| * functions, syntax of: Syntax of Functions. (line 6) |
| * functions, user defined: Call Function. (line 6) |
| * g++ <1>: Implicit Variables. (line 49) |
| * g++: Catalogue of Rules. (line 39) |
| * gcc: Catalogue of Rules. (line 35) |
| * generating prerequisites automatically <1>: Automatic Prerequisites. |
| (line 6) |
| * generating prerequisites automatically: Include. (line 51) |
| * get <1>: Catalogue of Rules. (line 173) |
| * get: Implicit Variables. (line 69) |
| * globbing (wildcards): Wildcards. (line 6) |
| * goal: How Make Works. (line 11) |
| * goal, default <1>: How Make Works. (line 11) |
| * goal, default: Rules. (line 11) |
| * goal, how to specify: Goals. (line 6) |
| * grouped targets: Multiple Targets. (line 61) |
| * Guile <1>: Guile Integration. (line 6) |
| * Guile: Guile Function. (line 6) |
| * Guile example: Guile Example. (line 6) |
| * guile, conversion of types: Guile Types. (line 6) |
| * home directory: Wildcards. (line 11) |
| * IEEE Standard 1003.2: Overview. (line 13) |
| * ifdef, expansion: Reading Makefiles. (line 83) |
| * ifeq, expansion: Reading Makefiles. (line 83) |
| * ifndef, expansion: Reading Makefiles. (line 83) |
| * ifneq, expansion: Reading Makefiles. (line 83) |
| * implicit rule: Implicit Rules. (line 6) |
| * implicit rule, and directory search: Implicit/Search. (line 6) |
| * implicit rule, and VPATH: Implicit/Search. (line 6) |
| * implicit rule, definition of: Makefile Contents. (line 16) |
| * implicit rule, expansion: Reading Makefiles. (line 93) |
| * implicit rule, how to use: Using Implicit. (line 6) |
| * implicit rule, introduction to: make Deduces. (line 6) |
| * implicit rule, predefined: Catalogue of Rules. (line 6) |
| * implicit rule, search algorithm: Implicit Rule Search. |
| (line 6) |
| * implicit rules, secondary expansion of: Secondary Expansion. |
| (line 145) |
| * included makefiles, default directories: Include. (line 53) |
| * including (MAKEFILE_LIST variable): Special Variables. (line 8) |
| * including (MAKEFILES variable): MAKEFILES Variable. (line 6) |
| * including other makefiles: Include. (line 6) |
| * incompatibilities: Missing. (line 6) |
| * independent targets: Multiple Targets. (line 14) |
| * Info, rule to format: Catalogue of Rules. (line 158) |
| * inheritance, suppressing: Suppressing Inheritance. |
| (line 6) |
| * input during parallel execution: Parallel Input. (line 6) |
| * install (standard target): Goals. (line 92) |
| * installation directories, creating: Directory Variables. (line 20) |
| * installations, staged: DESTDIR. (line 6) |
| * interface for loaded objects: Loaded Object API. (line 6) |
| * intermediate files: Chained Rules. (line 16) |
| * intermediate files, preserving: Chained Rules. (line 46) |
| * intermediate targets, explicit: Special Targets. (line 44) |
| * interrupt: Interrupts. (line 6) |
| * job slots: Parallel. (line 6) |
| * job slots, and recursion: Options/Recursion. (line 25) |
| * job slots, sharing: Job Slots. (line 6) |
| * jobs, limiting based on load: Parallel. (line 35) |
| * jobserver: Job Slots. (line 16) |
| * jobserver on POSIX: POSIX Jobserver. (line 6) |
| * jobserver on Windows: Windows Jobserver. (line 6) |
| * joining lists of words: File Name Functions. (line 90) |
| * killing (interruption): Interrupts. (line 6) |
| * last-resort default rules: Last Resort. (line 6) |
| * ld: Catalogue of Rules. (line 86) |
| * lex <1>: Implicit Variables. (line 73) |
| * lex: Catalogue of Rules. (line 124) |
| * Lex, rule to run: Catalogue of Rules. (line 124) |
| * libraries for linking, directory search: Libraries/Search. (line 6) |
| * library archive, suffix rule for: Archive Suffix Rules. |
| (line 6) |
| * limiting jobs based on load: Parallel. (line 35) |
| * link libraries, and directory search: Libraries/Search. (line 6) |
| * link libraries, patterns matching: Libraries/Search. (line 6) |
| * linking, predefined rule for: Catalogue of Rules. (line 86) |
| * lint <1>: Implicit Variables. (line 80) |
| * lint: Catalogue of Rules. (line 146) |
| * lint, rule to run: Catalogue of Rules. (line 146) |
| * list of all prerequisites: Automatic Variables. (line 62) |
| * list of changed prerequisites: Automatic Variables. (line 52) |
| * load average: Parallel. (line 35) |
| * load directive: load Directive. (line 6) |
| * loaded object API: Loaded Object API. (line 6) |
| * loaded object example: Loaded Object Example. |
| (line 6) |
| * loaded object licensing: Loaded Object API. (line 32) |
| * loaded objects: Loading Objects. (line 6) |
| * loaded objects, remaking of: Remaking Loaded Objects. |
| (line 6) |
| * long lines, splitting: Splitting Lines. (line 6) |
| * loops in variable expansion: Flavors. (line 44) |
| * lpr (shell command) <1>: Wildcard Examples. (line 21) |
| * lpr (shell command): Empty Targets. (line 25) |
| * m2c <1>: Implicit Variables. (line 60) |
| * m2c: Catalogue of Rules. (line 74) |
| * macro: Using Variables. (line 10) |
| * make depend: Automatic Prerequisites. |
| (line 37) |
| * make extensions: Extending make. (line 6) |
| * make integration: Integrating make. (line 6) |
| * make interface to guile: Guile Interface. (line 6) |
| * make procedures in guile: Guile Interface. (line 6) |
| * makefile: Introduction. (line 7) |
| * makefile name: Makefile Names. (line 6) |
| * makefile name, how to specify: Makefile Names. (line 30) |
| * makefile rule parts: Rule Introduction. (line 6) |
| * makefile syntax, evaluating: Eval Function. (line 6) |
| * makefile, and MAKEFILES variable: MAKEFILES Variable. (line 6) |
| * makefile, conventions for: Makefile Conventions. |
| (line 6) |
| * makefile, how make processes: How Make Works. (line 6) |
| * makefile, how to write: Makefiles. (line 6) |
| * makefile, including: Include. (line 6) |
| * makefile, overriding: Overriding Makefiles. |
| (line 6) |
| * makefile, reading: Reading Makefiles. (line 6) |
| * makefile, remaking of: Remaking Makefiles. (line 6) |
| * makefile, simple: Simple Makefile. (line 6) |
| * makefiles, and MAKEFILE_LIST variable: Special Variables. (line 8) |
| * makefiles, and special variables: Special Variables. (line 6) |
| * makefiles, parsing: Parsing Makefiles. (line 6) |
| * makeinfo <1>: Catalogue of Rules. (line 158) |
| * makeinfo: Implicit Variables. (line 84) |
| * match-anything rule: Match-Anything Rules. |
| (line 6) |
| * match-anything rule, used to override: Overriding Makefiles. |
| (line 12) |
| * missing features: Missing. (line 6) |
| * mistakes with wildcards: Wildcard Pitfall. (line 6) |
| * modified variable reference: Substitution Refs. (line 6) |
| * Modula-2, rule to compile: Catalogue of Rules. (line 74) |
| * mostlyclean (standard target): Goals. (line 78) |
| * multi-line variable definition: Multi-Line. (line 6) |
| * multiple rules for one target: Multiple Rules. (line 6) |
| * multiple rules for one target (::): Double-Colon. (line 6) |
| * multiple targets: Multiple Targets. (line 6) |
| * multiple targets, in pattern rule: Pattern Intro. (line 44) |
| * name of makefile: Makefile Names. (line 6) |
| * name of makefile, how to specify: Makefile Names. (line 30) |
| * nested variable reference: Computed Names. (line 6) |
| * newline, quoting, in makefile: Simple Makefile. (line 41) |
| * newline, quoting, in recipes: Splitting Recipe Lines. |
| (line 6) |
| * nondirectory part: File Name Functions. (line 27) |
| * normal prerequisites: Prerequisite Types. (line 6) |
| * OBJ: Variables Simplify. (line 20) |
| * obj: Variables Simplify. (line 20) |
| * OBJECTS: Variables Simplify. (line 20) |
| * objects: Variables Simplify. (line 14) |
| * objects, loaded: Loading Objects. (line 6) |
| * OBJS: Variables Simplify. (line 20) |
| * objs: Variables Simplify. (line 20) |
| * old-fashioned suffix rules: Suffix Rules. (line 6) |
| * options: Options Summary. (line 6) |
| * options, and recursion: Options/Recursion. (line 6) |
| * options, setting from environment: Options/Recursion. (line 81) |
| * options, setting in makefiles: Options/Recursion. (line 81) |
| * order of pattern rules: Pattern Match. (line 30) |
| * order-only prerequisites: Prerequisite Types. (line 6) |
| * origin of variable: Origin Function. (line 6) |
| * output during parallel execution <1>: Options Summary. (line 169) |
| * output during parallel execution: Parallel Output. (line 6) |
| * overriding makefiles: Overriding Makefiles. |
| (line 6) |
| * overriding variables with arguments: Overriding. (line 6) |
| * overriding with override: Override Directive. (line 6) |
| * parallel execution: Parallel. (line 6) |
| * parallel execution, and archive update: Archive Pitfalls. (line 6) |
| * parallel execution, input during: Parallel Input. (line 6) |
| * parallel execution, output during <1>: Parallel Output. (line 6) |
| * parallel execution, output during: Options Summary. (line 169) |
| * parallel execution, overriding: Special Targets. (line 129) |
| * parallel output to terminal: Terminal Output. (line 6) |
| * parsing makefiles: Parsing Makefiles. (line 6) |
| * parts of makefile rule: Rule Introduction. (line 6) |
| * Pascal, rule to compile: Catalogue of Rules. (line 45) |
| * pattern rule: Pattern Intro. (line 6) |
| * pattern rule, expansion: Reading Makefiles. (line 93) |
| * pattern rules, order of: Pattern Match. (line 30) |
| * pattern rules, static (not implicit): Static Pattern. (line 6) |
| * pattern rules, static, syntax of: Static Usage. (line 6) |
| * pattern-specific variables: Pattern-specific. (line 6) |
| * pc <1>: Catalogue of Rules. (line 45) |
| * pc: Implicit Variables. (line 63) |
| * phony targets: Phony Targets. (line 6) |
| * phony targets and recipe execution: Instead of Execution. |
| (line 71) |
| * pitfalls of wildcards: Wildcard Pitfall. (line 6) |
| * plugin_is_GPL_compatible: Loaded Object API. (line 32) |
| * portability: Features. (line 6) |
| * POSIX <1>: Overview. (line 13) |
| * POSIX: Options/Recursion. (line 60) |
| * POSIX-conforming mode, setting: Special Targets. (line 142) |
| * post-installation commands: Install Command Categories. |
| (line 6) |
| * pre-installation commands: Install Command Categories. |
| (line 6) |
| * precious targets: Special Targets. (line 29) |
| * predefined rules and variables, printing: Options Summary. (line 185) |
| * prefix, adding: File Name Functions. (line 79) |
| * prerequisite: Rules. (line 6) |
| * prerequisite pattern, implicit: Pattern Intro. (line 22) |
| * prerequisite pattern, static (not implicit): Static Usage. (line 30) |
| * prerequisite types: Prerequisite Types. (line 6) |
| * prerequisite, expansion: Reading Makefiles. (line 93) |
| * prerequisites: Rule Syntax. (line 48) |
| * prerequisites, and automatic variables: Automatic Variables. |
| (line 17) |
| * prerequisites, automatic generation <1>: Include. (line 51) |
| * prerequisites, automatic generation: Automatic Prerequisites. |
| (line 6) |
| * prerequisites, introduction to: Rule Introduction. (line 8) |
| * prerequisites, list of all: Automatic Variables. (line 62) |
| * prerequisites, list of changed: Automatic Variables. (line 52) |
| * prerequisites, normal: Prerequisite Types. (line 6) |
| * prerequisites, order-only: Prerequisite Types. (line 6) |
| * prerequisites, varying (static pattern): Static Pattern. (line 6) |
| * preserving intermediate files: Chained Rules. (line 46) |
| * preserving with .PRECIOUS <1>: Special Targets. (line 29) |
| * preserving with .PRECIOUS: Chained Rules. (line 56) |
| * preserving with .SECONDARY: Special Targets. (line 49) |
| * print (standard target): Goals. (line 97) |
| * print target <1>: Wildcard Examples. (line 21) |
| * print target: Empty Targets. (line 25) |
| * printing directories: -w Option. (line 6) |
| * printing messages: Make Control Functions. |
| (line 43) |
| * printing of recipes: Echoing. (line 6) |
| * printing user warnings: Make Control Functions. |
| (line 35) |
| * problems and bugs, reporting: Bugs. (line 6) |
| * problems with wildcards: Wildcard Pitfall. (line 6) |
| * processing a makefile: How Make Works. (line 6) |
| * question mode: Instead of Execution. |
| (line 30) |
| * quoting %, in patsubst: Text Functions. (line 26) |
| * quoting %, in static pattern: Static Usage. (line 37) |
| * quoting %, in vpath: Selective Search. (line 38) |
| * quoting newline, in makefile: Simple Makefile. (line 41) |
| * quoting newline, in recipes: Splitting Recipe Lines. |
| (line 6) |
| * Ratfor, rule to compile: Catalogue of Rules. (line 49) |
| * RCS, rule to extract from: Catalogue of Rules. (line 164) |
| * reading from a file: File Function. (line 6) |
| * reading makefiles: Reading Makefiles. (line 6) |
| * README: Makefile Names. (line 9) |
| * realclean (standard target): Goals. (line 85) |
| * realpath: File Name Functions. (line 114) |
| * recipe: Simple Makefile. (line 74) |
| * recipe execution, single invocation: Special Targets. (line 136) |
| * recipe lines, single shell: One Shell. (line 6) |
| * recipe syntax: Recipe Syntax. (line 6) |
| * recipe, execution: Execution. (line 6) |
| * recipes <1>: Recipes. (line 6) |
| * recipes: Rule Syntax. (line 26) |
| * recipes setting shell variables: Execution. (line 12) |
| * recipes, and directory search: Recipes/Search. (line 6) |
| * recipes, backslash (\) in: Splitting Recipe Lines. |
| (line 6) |
| * recipes, canned: Canned Recipes. (line 6) |
| * recipes, comments in: Recipe Syntax. (line 29) |
| * recipes, echoing: Echoing. (line 6) |
| * recipes, empty: Empty Recipes. (line 6) |
| * recipes, errors in: Errors. (line 6) |
| * recipes, execution in parallel: Parallel. (line 6) |
| * recipes, how to write: Recipes. (line 6) |
| * recipes, instead of executing: Instead of Execution. |
| (line 6) |
| * recipes, introduction to: Rule Introduction. (line 8) |
| * recipes, quoting newlines in: Splitting Recipe Lines. |
| (line 6) |
| * recipes, splitting: Splitting Recipe Lines. |
| (line 6) |
| * recipes, using variables in: Variables in Recipes. |
| (line 6) |
| * recompilation: Introduction. (line 22) |
| * recompilation, avoiding: Avoiding Compilation. |
| (line 6) |
| * recording events with empty targets: Empty Targets. (line 6) |
| * recursion: Recursion. (line 6) |
| * recursion, and -C: Options/Recursion. (line 22) |
| * recursion, and -f: Options/Recursion. (line 22) |
| * recursion, and -j: Options/Recursion. (line 25) |
| * recursion, and -o: Options/Recursion. (line 22) |
| * recursion, and -t: MAKE Variable. (line 34) |
| * recursion, and -W: Options/Recursion. (line 22) |
| * recursion, and -w: -w Option. (line 20) |
| * recursion, and command line variable definitions: Options/Recursion. |
| (line 17) |
| * recursion, and environment: Variables/Recursion. (line 6) |
| * recursion, and MAKE variable: MAKE Variable. (line 6) |
| * recursion, and MAKEFILES variable: MAKEFILES Variable. (line 15) |
| * recursion, and options: Options/Recursion. (line 6) |
| * recursion, and printing directories: -w Option. (line 6) |
| * recursion, and variables: Variables/Recursion. (line 6) |
| * recursion, level of: Variables/Recursion. (line 115) |
| * recursive variable expansion <1>: Using Variables. (line 6) |
| * recursive variable expansion: Flavors. (line 6) |
| * recursively expanded variables: Flavors. (line 6) |
| * reference to variables <1>: Reference. (line 6) |
| * reference to variables: Advanced. (line 6) |
| * relinking: How Make Works. (line 46) |
| * remaking loaded objects: Remaking Loaded Objects. |
| (line 6) |
| * remaking makefiles: Remaking Makefiles. (line 6) |
| * removal of target files <1>: Interrupts. (line 6) |
| * removal of target files: Errors. (line 63) |
| * removing duplicate words: Text Functions. (line 155) |
| * removing targets on failure: Special Targets. (line 64) |
| * removing whitespace from split lines: Splitting Lines. (line 40) |
| * removing, to clean up: Cleanup. (line 6) |
| * reporting bugs: Bugs. (line 6) |
| * rm: Implicit Variables. (line 106) |
| * rm (shell command) <1>: Errors. (line 27) |
| * rm (shell command) <2>: Wildcard Examples. (line 12) |
| * rm (shell command) <3>: Simple Makefile. (line 85) |
| * rm (shell command): Phony Targets. (line 20) |
| * rule prerequisites: Rule Syntax. (line 48) |
| * rule syntax: Rule Syntax. (line 6) |
| * rule targets: Rule Syntax. (line 18) |
| * rule, double-colon (::): Double-Colon. (line 6) |
| * rule, explicit, definition of: Makefile Contents. (line 10) |
| * rule, how to write: Rules. (line 6) |
| * rule, implicit: Implicit Rules. (line 6) |
| * rule, implicit, and directory search: Implicit/Search. (line 6) |
| * rule, implicit, and VPATH: Implicit/Search. (line 6) |
| * rule, implicit, chains of: Chained Rules. (line 6) |
| * rule, implicit, definition of: Makefile Contents. (line 16) |
| * rule, implicit, how to use: Using Implicit. (line 6) |
| * rule, implicit, introduction to: make Deduces. (line 6) |
| * rule, implicit, predefined: Catalogue of Rules. (line 6) |
| * rule, introduction to: Rule Introduction. (line 6) |
| * rule, multiple for one target: Multiple Rules. (line 6) |
| * rule, no recipe or prerequisites: Force Targets. (line 6) |
| * rule, pattern: Pattern Intro. (line 6) |
| * rule, static pattern: Static Pattern. (line 6) |
| * rule, static pattern versus implicit: Static versus Implicit. |
| (line 6) |
| * rule, with multiple targets: Multiple Targets. (line 6) |
| * rules, and $: Rule Syntax. (line 34) |
| * s. (SCCS file prefix): Catalogue of Rules. (line 173) |
| * SCCS, rule to extract from: Catalogue of Rules. (line 173) |
| * search algorithm, implicit rule: Implicit Rule Search. |
| (line 6) |
| * search path for prerequisites (VPATH): Directory Search. (line 6) |
| * search path for prerequisites (VPATH), and implicit rules: Implicit/Search. |
| (line 6) |
| * search path for prerequisites (VPATH), and link libraries: Libraries/Search. |
| (line 6) |
| * searching for strings: Text Functions. (line 103) |
| * secondary expansion: Secondary Expansion. (line 6) |
| * secondary expansion and explicit rules: Secondary Expansion. |
| (line 105) |
| * secondary expansion and implicit rules: Secondary Expansion. |
| (line 145) |
| * secondary expansion and static pattern rules: Secondary Expansion. |
| (line 137) |
| * secondary files: Chained Rules. (line 46) |
| * secondary targets: Special Targets. (line 49) |
| * sed (shell command): Automatic Prerequisites. |
| (line 73) |
| * selecting a word: Text Functions. (line 159) |
| * selecting word lists: Text Functions. (line 168) |
| * sequences of commands: Canned Recipes. (line 6) |
| * setting options from environment: Options/Recursion. (line 81) |
| * setting options in makefiles: Options/Recursion. (line 81) |
| * setting variables: Setting. (line 6) |
| * several rules for one target: Multiple Rules. (line 6) |
| * several targets in a rule: Multiple Targets. (line 6) |
| * shar (standard target): Goals. (line 103) |
| * shell command, function for: Shell Function. (line 6) |
| * shell file name pattern (in include): Include. (line 13) |
| * shell variables, setting in recipes: Execution. (line 12) |
| * shell wildcards (in include): Include. (line 13) |
| * shell, choosing the: Choosing the Shell. (line 6) |
| * SHELL, exported value: Variables/Recursion. (line 23) |
| * SHELL, import from environment: Environment. (line 37) |
| * shell, in DOS and Windows: Choosing the Shell. (line 38) |
| * SHELL, MS-DOS specifics: Choosing the Shell. (line 44) |
| * SHELL, value of: Choosing the Shell. (line 6) |
| * signal: Interrupts. (line 6) |
| * silent operation: Echoing. (line 6) |
| * simple makefile: Simple Makefile. (line 6) |
| * simple variable expansion: Using Variables. (line 6) |
| * simplifying with variables: Variables Simplify. (line 6) |
| * simply expanded variables: Flavors. (line 56) |
| * sorting words: Text Functions. (line 146) |
| * spaces, in variable values: Flavors. (line 107) |
| * spaces, stripping: Text Functions. (line 80) |
| * special targets: Special Targets. (line 6) |
| * special variables: Special Variables. (line 6) |
| * specifying makefile name: Makefile Names. (line 30) |
| * splitting long lines: Splitting Lines. (line 6) |
| * splitting recipes: Splitting Recipe Lines. |
| (line 6) |
| * staged installs: DESTDIR. (line 6) |
| * standard input: Parallel Input. (line 6) |
| * standards conformance: Overview. (line 13) |
| * standards for makefiles: Makefile Conventions. |
| (line 6) |
| * static pattern rule: Static Pattern. (line 6) |
| * static pattern rule, syntax of: Static Usage. (line 6) |
| * static pattern rule, versus implicit: Static versus Implicit. |
| (line 6) |
| * static pattern rules, secondary expansion of: Secondary Expansion. |
| (line 137) |
| * stem <1>: Pattern Match. (line 6) |
| * stem: Static Usage. (line 17) |
| * stem, shortest: Pattern Match. (line 38) |
| * stem, variable for: Automatic Variables. (line 78) |
| * stopping make: Make Control Functions. |
| (line 11) |
| * strings, searching for: Text Functions. (line 103) |
| * stripping whitespace: Text Functions. (line 80) |
| * sub-make: Variables/Recursion. (line 6) |
| * subdirectories, recursion for: Recursion. (line 6) |
| * substitution variable reference: Substitution Refs. (line 6) |
| * suffix rule: Suffix Rules. (line 6) |
| * suffix rule, for archive: Archive Suffix Rules. |
| (line 6) |
| * suffix, adding: File Name Functions. (line 68) |
| * suffix, function to find: File Name Functions. (line 43) |
| * suffix, substituting in variables: Substitution Refs. (line 6) |
| * suppressing inheritance: Suppressing Inheritance. |
| (line 6) |
| * switches: Options Summary. (line 6) |
| * symbol directories, updating archive: Archive Symbols. (line 6) |
| * syntax of recipe: Recipe Syntax. (line 6) |
| * syntax of rules: Rule Syntax. (line 6) |
| * tab character (in commands): Rule Syntax. (line 26) |
| * tabs in rules: Rule Introduction. (line 21) |
| * TAGS (standard target): Goals. (line 111) |
| * tangle <1>: Catalogue of Rules. (line 151) |
| * tangle: Implicit Variables. (line 100) |
| * tar (standard target): Goals. (line 100) |
| * target: Rules. (line 6) |
| * target pattern, implicit: Pattern Intro. (line 9) |
| * target pattern, static (not implicit): Static Usage. (line 17) |
| * target, deleting on error: Errors. (line 63) |
| * target, deleting on interrupt: Interrupts. (line 6) |
| * target, expansion: Reading Makefiles. (line 93) |
| * target, multiple in pattern rule: Pattern Intro. (line 44) |
| * target, multiple rules for one: Multiple Rules. (line 6) |
| * target, touching: Instead of Execution. |
| (line 23) |
| * target-specific variables: Target-specific. (line 6) |
| * targets: Rule Syntax. (line 18) |
| * targets without a file: Phony Targets. (line 6) |
| * targets, built-in special: Special Targets. (line 6) |
| * targets, empty: Empty Targets. (line 6) |
| * targets, force: Force Targets. (line 6) |
| * targets, grouped: Multiple Targets. (line 61) |
| * targets, independent: Multiple Targets. (line 14) |
| * targets, introduction to: Rule Introduction. (line 8) |
| * targets, multiple: Multiple Targets. (line 6) |
| * targets, phony: Phony Targets. (line 6) |
| * terminal rule: Match-Anything Rules. |
| (line 6) |
| * terminal, output to: Terminal Output. (line 6) |
| * test (standard target): Goals. (line 115) |
| * testing compilation: Testing. (line 6) |
| * tex <1>: Implicit Variables. (line 87) |
| * tex: Catalogue of Rules. (line 151) |
| * TeX, rule to run: Catalogue of Rules. (line 151) |
| * texi2dvi <1>: Implicit Variables. (line 91) |
| * texi2dvi: Catalogue of Rules. (line 158) |
| * Texinfo, rule to format: Catalogue of Rules. (line 158) |
| * tilde (~): Wildcards. (line 11) |
| * tools, sharing job slots: Job Slots. (line 6) |
| * touch (shell command) <1>: Empty Targets. (line 25) |
| * touch (shell command): Wildcard Examples. (line 21) |
| * touching files: Instead of Execution. |
| (line 23) |
| * traditional directory search (GPATH): Search Algorithm. (line 42) |
| * types of prerequisites: Prerequisite Types. (line 6) |
| * types, conversion of: Guile Types. (line 6) |
| * undefined variables, warning message: Options Summary. (line 287) |
| * undefining variable: Undefine Directive. (line 6) |
| * updating archive symbol directories: Archive Symbols. (line 6) |
| * updating loaded objects: Remaking Loaded Objects. |
| (line 6) |
| * updating makefiles: Remaking Makefiles. (line 6) |
| * user defined functions: Call Function. (line 6) |
| * value: Using Variables. (line 6) |
| * value, how a variable gets it: Values. (line 6) |
| * variable: Using Variables. (line 6) |
| * variable definition: Makefile Contents. (line 22) |
| * variable references in recipes: Variables in Recipes. |
| (line 6) |
| * variables: Variables Simplify. (line 6) |
| * variables, $ in name: Computed Names. (line 6) |
| * variables, and implicit rule: Automatic Variables. (line 6) |
| * variables, appending to: Appending. (line 6) |
| * variables, automatic: Automatic Variables. (line 6) |
| * variables, command line: Overriding. (line 6) |
| * variables, command line, and recursion: Options/Recursion. (line 17) |
| * variables, computed names: Computed Names. (line 6) |
| * variables, conditional assignment: Flavors. (line 133) |
| * variables, defining verbatim: Multi-Line. (line 6) |
| * variables, environment <1>: Environment. (line 6) |
| * variables, environment: Variables/Recursion. (line 6) |
| * variables, exporting: Variables/Recursion. (line 6) |
| * variables, flavor of: Flavor Function. (line 6) |
| * variables, flavors: Flavors. (line 6) |
| * variables, how they get their values: Values. (line 6) |
| * variables, how to reference: Reference. (line 6) |
| * variables, loops in expansion: Flavors. (line 44) |
| * variables, modified reference: Substitution Refs. (line 6) |
| * variables, multi-line: Multi-Line. (line 6) |
| * variables, nested references: Computed Names. (line 6) |
| * variables, origin of: Origin Function. (line 6) |
| * variables, overriding: Override Directive. (line 6) |
| * variables, overriding with arguments: Overriding. (line 6) |
| * variables, pattern-specific: Pattern-specific. (line 6) |
| * variables, recursively expanded: Flavors. (line 6) |
| * variables, setting: Setting. (line 6) |
| * variables, simply expanded: Flavors. (line 56) |
| * variables, spaces in values: Flavors. (line 107) |
| * variables, substituting suffix in: Substitution Refs. (line 6) |
| * variables, substitution reference: Substitution Refs. (line 6) |
| * variables, target-specific: Target-specific. (line 6) |
| * variables, unexpanded value: Value Function. (line 6) |
| * variables, warning for undefined: Options Summary. (line 287) |
| * varying prerequisites: Static Pattern. (line 6) |
| * verbatim variable definition: Multi-Line. (line 6) |
| * vpath: Directory Search. (line 6) |
| * VPATH, and implicit rules: Implicit/Search. (line 6) |
| * VPATH, and link libraries: Libraries/Search. (line 6) |
| * warnings, printing: Make Control Functions. |
| (line 35) |
| * weave <1>: Catalogue of Rules. (line 151) |
| * weave: Implicit Variables. (line 94) |
| * Web, rule to run: Catalogue of Rules. (line 151) |
| * what if: Instead of Execution. |
| (line 38) |
| * whitespace, avoiding on line split: Splitting Lines. (line 40) |
| * whitespace, in variable values: Flavors. (line 107) |
| * whitespace, stripping: Text Functions. (line 80) |
| * wildcard: Wildcards. (line 6) |
| * wildcard pitfalls: Wildcard Pitfall. (line 6) |
| * wildcard, function: File Name Functions. (line 107) |
| * wildcard, in archive member: Archive Members. (line 36) |
| * wildcard, in include: Include. (line 13) |
| * wildcards and MS-DOS/MS-Windows backslashes: Wildcard Pitfall. |
| (line 31) |
| * Windows, choosing a shell in: Choosing the Shell. (line 38) |
| * word, selecting a: Text Functions. (line 159) |
| * words, extracting first: Text Functions. (line 184) |
| * words, extracting last: Text Functions. (line 197) |
| * words, filtering: Text Functions. (line 114) |
| * words, filtering out: Text Functions. (line 132) |
| * words, finding number: Text Functions. (line 180) |
| * words, iterating over: Foreach Function. (line 6) |
| * words, joining lists: File Name Functions. (line 90) |
| * words, removing duplicates: Text Functions. (line 155) |
| * words, selecting lists of: Text Functions. (line 168) |
| * writing recipes: Recipes. (line 6) |
| * writing rules: Rules. (line 6) |
| * writing to a file: File Function. (line 6) |
| * yacc <1>: Implicit Variables. (line 77) |
| * yacc <2>: Catalogue of Rules. (line 120) |
| * yacc: Canned Recipes. (line 18) |
| * Yacc, rule to run: Catalogue of Rules. (line 120) |
| * ~ (tilde): Wildcards. (line 11) |
| |