GNU Make User Manual (Chinese translation)

xiaoxiao2021-03-05  21

Original: http://lsec.cc.ac.cn/~peace/articles/gnumaketranslated.html

GNU Make User Manual (Chinese translation)

Translation: Yu Fengchang

Translator Note: I have found that if I want to fully understand Linux structures, I understand that the overall design and idea of ​​Linux can first read the Makefile files in the Linux source code. At present, although there is some work online, it is unable to explain the Makefile files in the Linux source code. Therefore, I carefully read the original text of the GNU Make User Manual (3.79). Only, the manual is translated, Meetings that are interested in Linux source code or wish to use GCC write programs but to lack the GNU Make's comprehensive understanding of people. I am amateur hobby is not a professional translator. If there is any problem, please contact me through an electronic mailbox, I'm: YFC70@public2.lyptt.ha.cn. Note that the plasma bolding word that appears in the article indicates the chapter.

GNU Make Version 3.79

April 2000

Richard M. Stallman and Roland McGrath

table of Contents

1 Make Overview

1.1 How to read this manual

1.2 questions and bugs

2 Makefile file introduction

2.1 Format of Rules

2.2 A simple makefile file

2.3make processes the process of processing the Makefile file

2.4 Simplify the Makefile file using the variable

2.5 Let Make Inference Command

2.6 another style of Makefile file

2.7 Rule of the file in the directory

3 Write the Makefile file

3.1makefile file content

Down 3.2makefile file

3.3 Contains other Makefile files

3.4 Variable Makefiles

3.5makefile file regenerated process

3.6 Observation Other Makefile Files

3.7make reads the process of reading the Makefile file

4 write rules

4.1 Syntax of the Rule

4.2 Using wildcards in the file name

4.2.1 Wildcard Example

4.2.2 Common errors using wildcards

4.2.3 Function Wildcard

4.3 Search for dependence in the catalog

4.3.1VPath: All dependent search paths

4.3.2VPath Directive

4.3.3 Directory Search Process

4.3.4 Write the shell command for the search directory

4.3.5 Directory Search and Implicit Rules

4.3.6 Search Contents for Library

4.4 Immortal Target

4.5 Rules without commands or dependencies

4.6 Using an empty directory file log event

4.7 Built-in special target name

4.8 Rules with multiple objectives

4.9 Targets with multiple rules

4.10 Static Format Rule

4.10.1 Syntax of Static Format Rule

4.10.2 Static format rules and implicit rules

4.11 double colon rules

4.12 Automatic generation dependence

5 Use the command in the rules

5.1 Command Back

5.2 Execute Commands

5.3 execution in parallel

5.4 Command error

5.5 Interrupt or close Make

5.6 Recursive Call Make

5.6.1 Variable Make works

5.6.2 Variables with the sub-Make communication

5.6.3 Options with the subkey communication

5.6.4` - Print-Directory 'option

5.7 Define the fixed order command

5.8 Using an empty command

6 use variables

6.1 Variable reference

Two features of 6.2 variables

6.3 Variable Advanced Reference Technology

6.3.1 Replacement reference

6.3.2 Nested variables reference

6.4 variable value

6.5 Settings Variables

6.6 Additional text for variable values

6.7Override instruction

6.8 Define Multi-Row Variables

6.9 environment variables

6.10 Value of specific target variables

6.11 Value of specific format variables

7 Makefile file conditional statement

7.1 Example of conditional statement

7.2 Syntax for conditional statement

7.3 Conditional statement of test logo

8 text conversion function

8.1 function call syntax

8.2 String Replacement and Analysis Functions

8.3 file name function

8.4 Function Foreach

8.5 functions IF

8.6 function CALL

8.7 Function Origin

8.8 function shell

8.9 Control Make function

9 Run Make

9.1 Specify the parameters of the Makefile file

9.2 Specify the parameters of the final goal

9.3 instead of execution command

9.4 Avoid recompiling files

9.5 variable overload

9.6 Test Compiler

9.7 Overview

10 Use implicit rules

10.1 Using implicit rules

10.2 Implied rules directory

10.3 Variables used in implicit rules

10.4 implicit rule chain

10.5 Define and redefine format rules

10.5.1 Introduction to Format Rules

10.5.2 Examples of format rules

10.5.3 Automatic variable

10.5.4 Format matching

10.55 million rules

10.5.6 Delete implicit rules

10.6 Defining the default rules of the latest type

10.7 Outdated suffix rules

10.8 Implied Rule Search Algorithm

11 Update file files using Make

11.1 Archive Member Goals

11.2 Implicit rules for file member objectives

11.2.1 Update the symbol index table of file members

11.3 Danger of using files

11.4 Suffix rules for file files

12 gnu make features

13 incompatibility and loss of characteristics

14 Makefile File Formula

14.1Makefile file universal practice

14.2makefile file tool

14.3 Specify the variable of the command

14.4 Installing the path variable

14.5 User Standard Target

14.6 Installing Command Category

15 Quick reference

16make generated error

17 complex Makefile file example

Appendix noun translation comparison table

1 Make Overview

Make automatically determines which files in a large program need to recompile and publish them to recompile them. This version of the GNU Make User Manual was composed of Richard M. Stallman and Roland McGrath, which is developed from the V3.76 version written by Paul D. Smith.

GNU Make complies with the provisions of the IEEE Standard 1003.2-1992 (POSIX.2) 6.2.

Because the C language program is more representative, our example is based on the C language program, but Make is not only able to handle the C language program, which can handle the various languages ​​of those compilers to run under the shell command. In fact, GNU Make is not limited to the program, but it can be applied to any tasks if some file changes have caused some files to be updated.

If you want to use Make, you must first write a file called Makefile, the interrelationship between the files in the file, and provides the update command for each file. In a program, the update of the executable program file relies on the OBJ file, and the OBJ file is compiled by the source file.

Once the appropriate makefile file exists, each time some source files are changed, simply in the shell command:

Make

You can perform all the necessary recompilation tasks. The Make program determines which files need to be updated based on the data in the Makefile file and the timestamp of each file. For these files that need to be updated, the Make is updated based on the Makefile file publishing command, and the updated mode is controlled by the provided command line parameters. Please see the Make chapter.

1.1 How to read this manual

If you don't know anything about Make or you only need to understand the general introduction to Make, please check the previous chapters, skip the subsequent sections. The first few chapters are general introductory content, and the following chapters are specific professional and technical content.

If you are very familiar with other Make programs, see the characteristics and incompatibility and loss of incompatibility and loss of incompatibility, and the chapter of GNU Make is listed by GNU Make's extension, incompatible and loss of Make programs. The chapter explains the characteristics of other Make programs and the lack of GNU Make.

For quick viewers, see Options Summary, Quick Reference, and Built - in - construction specific target names.

1.2 questions and bugs

If you have questions about GNU Make or you think you have discovered a bug, please report to the developer; we can't promise what we can do, but we will try our best. Before reporting BUG, ​​please make sure you really discover the bug and make a closer study of the documentation to confirm whether it is really pressing your instructions. If the documentation can't tell you how to do it, you have to report it, this is a bug of the document. Before you report or personally correct the bug, please separate it as much as possible under the premise that the problem is exposed, you will narrow the Makefile file as much as possible. Then send this Makefile file and the exact result given by Make. Also please make what you want to get, this can help us determine if the problem is on the document.

Once you find an exact problem, please send us E-mail, our E-mail address is:

Bug-make@gnu.org

In the email, please include the version number of the GNU Make you use. You can use the command 'make - version' to get the version number. At the same time, I hope that you provide your machine model and operating system type. If possible, you want to provide the config.h file at the same time (this file has a configuration process).

2 Makefile file introduction

The Make program requires a so-called Makefile file to tell it what. In most cases, the Makefile file tells make how to compile and connect into a program.

This chapter we will discuss a simple Makefile file that describes how to compile 8 C source files and 3 head files into a text editor. The Makefile file can tell Make how to run the messy commanded commands (for example, delete a specific file). If you want to see more detailed, complex Makefile file examples, see the Complex Makefile file example chapter.

When Make recompores this editor, all modified C language source files must be recompiled. If a header file changes, each C language source file containing the header file must be recompiled, so that the generated editor is an editor after all source files updated. Each C language source file is compiled and generated a corresponding OBJ file. If a source file recompiles, all OBJ files are newly connected, whether it is just compiled or originally compiled, forms a new executable.

2.1 Format of Rules

A simple Makefile file contains a series of "rules", the style is as follows:

Target ...: Prerequiries ...

Command (Command)

...

...

Target is usually the name of the file to be generated, and an example of the target is an executable file or an OBJ file. The goal is also an executive action name, such as 'clean' (see the imaginary target section).

Relying on files used to input to generate targets, one goal often has several dependencies.

The command is an action executed by Make, and a rule can contain several commands, each command occupies a row. Note: You must be a Tab character in front of each command line, that is, the first character of the command line is Tab. This is a place where it is easy to make mistakes.

Typically, if a dependency change, a rule call command is required to process the corresponding dependency and service to update or create a target. However, the rules specifying the command update target do not require dependence, for example, the rules of the delete command containing and deleting the target 'Clern' are not dependent.

Rules are generally used to explain how and when to rebuild specific files, these specific files are the target of this detailed rules. Make needs to first call the command to process dependencies, which in order to create or update the target. Of course, a rule can also be used to explain how to perform an action, see the rules chapter.

A makefile file can contain other texts other than rules, but a simple makefile file only needs to contain rules. Although the true rule is complicated than the example shown here, the format is exactly the same. 2.2 A simple makefile file

A simple makefile file describes a executable method called a text editor (edit), which relies on 8 OBJ files (.o files), which rely on 8 C source files and 3 A header file.

In this example, all C language source files contain the 'defs.h' header file, but only the source file of the edit command contains' command.h 'header file, only change the low-level file of the editor buffer contains' buffer .h 'header file.

Edit: main.o kbd.o command.o display.o /

INSERT.O Search.o Files.o Utils.o

Cc -o edit main.o kbd.o command.o display.o /

INSERT.O Search.o Files.o Utils.o

Main.o: main.c defs.h

cc -c main.c

Kbd.o: kbd.c Defs.h command.h

CC-C Kbd.c

Command.o: command.c defs.h command.h

CC-C Command.c

Display.o: display.c defs.h buffer.h

CC-C Display.c

INSERT.O: INSERT.C Defs.h buffer.h

CC-C insert.c

Search.o: search.c defs.h buffer.h

CC-C Search.c

FILES.O: FILES.C Defs.h buffer.h command.h

CC-C Files.c

Utils.o: utils.c defs.h

CC-C Utils.c

Clean:

Rm Edit main.o kbd.o command.o display.o /

INSERT.O Search.o Files.o Utils.o

We use a backslash in each long line to split into two rows or more, in fact, they are equivalent to a line, the intention is just for reading convenience.

Use the Makefile file to create a file called 'Edit', type: make

Use the Makefile file to remove executables and targets from the directory, type: make clean

In this Makefile file example, the target includes executable file 'edit' and OBJ file 'main.o' and 'kdb.o'. Dependencies are C language source files and C language headers such as 'main.c' and 'DEF.H', etc. In fact, every OBJ file is also dependent. Therefore, the command line includes 'cc -c main.c' and 'cc -c kbd.c'.

When the goal is a file, if any of its dependency changes, the target must recompile and connect. The first character of any command line must be 'Tab' characters, which can separate the command lines in the Makefile file from other rows. (Be sure to keep in mind: Make does not know how the command works, it can only provide you with the appropriate update of the guarantee target. All of the work is to execute the command as you develop as the specific rule of the target when the target needs to be updated.)

Target 'Clean' is not a file, just a name of action. Under normal circumstances, 'Clean' this action is not executed in the rules, and the target 'clean' does not require any dependencies. In general, the 'clean' command will never perform unless the 'clean' command is executed unless I specially told MAKE. Note that this rule does not require any dependence, and the purpose of their existence is to perform some special commands. I don't need to rely on the target of just expressing only the action is called the imaginary target. See the imaginary target for details; see how the command error can understand how the RM or other commands cause MAKE ignore the error. 2.3 Make Processing the Makefile file

By default, Make starts at the first target (the name of the false target ". '). This goal is called the default ultimate goal (ie Make finally updated targets. For details, please see the parameter section of the final goal).

In the simple example of the previous section, the default final goal is to update the executable file 'edit', so we set this rule to the first rule. This way, once you give the command:

Make

Make will read the makefile file in the current directory and start processing the first rule. In this example, the first rule is to generate 'edit', but before the Make completed this rule, the OBJ file rely on 'Edit' must be handled first. These OBJ files are processed in accordance with their respective rules, and each OBJ file update rule is to compile their source files. Re-compiling whether the source file or header file is more than the existing OBJ file is more 'new', or whether the OBJ file exists.

The processing of other rules is determined based on whether their goals and dependence on the default ultimate goals. If some rules and default ultimate goals have no associations, these rules will not be executed unless the Make enforcement (if the Make Clean Command is executed).

Before the OBJ file recompiles, make first checks its dependence C language source files and C language head files need to be updated. If these C language source files and C language head files are not the goals of any rules, Make will not do anything to them. Make can also automatically generate C language source programs, which require specific rules, such as generating C language source programs according to Bison or YACC.

After the OBJ file recompiles (if needed), make determines whether to reconnect to generate the EDIT executable. If the Edit executable does not exist or any OBJ file ratio existing Edit executable file 'new', the MAKE reconnects to generate the EDIT executable.

This way, if we modify the 'INSERT.C' file, then run make, make will compile the 'INSERT.C' file update 'insert.o' file, and then reconnect to generate an EDIT executable. If we modify the 'command.h' file, then run make, make will recompile the 'kbd.o' and 'command.o' files, and then reconnect to generate the EDIT executable file.

2.4 Simplify the Makefile file using the variable

In our example, we enumerated all OBJ files twice in the 'Edit' generation rules, and repeat it here:

Edit: main.o kbd.o command.o display.o /

INSERT.O Search.o Files.o Utils.o

Cc -o edit main.o kbd.o command.o display.o /

INSERT.O Search.o Files.o Utils.o

Such two enumerations may have an error, such as adding a new OBJ file in the system, and we are likely to join in a place where you need, but forgetting it in another place. We use variables to simplify the makefile file and eliminate this error. Variables are defined a string once, and can replace the string in multiple sites (for details, please read the use variable section). The variables named Objects, Objects, Objs, Objs, Objects, Objs, Objs, Objects, Objs, Objs, Objects, Objs, Objs, Objects, Objs, Objs, Objects, Objs, Objs, Objects, Objs, Objs, Objects, Objs, Objs, Objects, Objs, Objs, Objects are already agreed. In this makefile file we defined a variable named Objects, its definition format is as follows:

Objects = main.o kbd.o command.o display.o /

INSERT.O Search.o Files.o Utils.o

Then, in each where the OBJ file is required, we use variables written as `$ (objects) 'form (for details, please read the use variable section). Below is a complete Makefile file after using the variable:

Objects = main.o kbd.o command.o display.o /

INSERT.O Search.o Files.o Utils.o

Edit: $ (Objects)

CC -O Edit $ (Objects)

Main.o: main.c defs.h

cc -c main.c

Kbd.o: kbd.c Defs.h command.h

CC-C Kbd.c

Command.o: command.c defs.h command.h

CC-C Command.c

Display.o: display.c defs.h buffer.h

CC-C Display.c

INSERT.O: INSERT.C Defs.h buffer.h

CC-C insert.c

Search.o: search.c defs.h buffer.h

CC-C Search.c

FILES.O: FILES.C Defs.h buffer.h command.h

CC-C Files.c

Utils.o: utils.c defs.h

CC-C Utils.c

Clean:

RM Edit $ (Objects)

2.5 Let Make Inference Command

Compiling a separate C language source does not need to write commands, because Make can infer it out: Make has an implicitness of the OBJ file that uses the 'cc -c' command to update the C language source program to the same file name. rule. For example, Make can automatically use 'cc -c main.c -o main.o' command to compile 'main.o'. Therefore, we can omit the update rules for the OBJ file. Please see the implicit rule section for details.

If the C language source program can be automatically compiled, it can also automatically add dependencies. So we can omit the C language source program in the dependencies, which can be omitted. Below is an example of a full Makefile file using implicit rules and variables Objects:

Objects = main.o kbd.o command.o display.o /

INSERT.O Search.o Files.o Utils.o

Edit: $ (Objects)

CC -O Edit $ (Objects)

Main.o: Defs.h

Kbd.o: Defs.h command.h

Command.o: Defs.h command.h

Display.o: Defs.h buffer.h

Insert.o: Defs.h buffer.h

Search.o: Defs.h buffer.h

FILES.O: Defs.h buffer.h command.h

Utils.o: Defs.h.phony: Clean

Clean:

-rm edit $ (Objects)

This is an example of our actual writing makefile file. (With the complexity of the target 'Clean'. See the description of the imperial goals and command errors.) Because the implicit rules are very convenient, they are very important, often used in the makefile file.

2.6 another style of Makefile file

When you use an implied rule in your Makefile file to create an OBJ file, it is also possible to use another style Makefile file. In this style of Makefile file, you can replace the target packet according to the dependent packet. Below is a Makefile file using this style:

Objects = main.o kbd.o command.o display.o /

INSERT.O Search.o Files.o Utils.o

Edit: $ (Objects)

CC -O Edit $ (Objects)

$ (Objects): Defs.h

Kbd.o command.o files.o: command.h

Display.o INSERT.O Search.o Files.o: buffer.h

The defs.h here is a common dependence of all OBJ files; Command.h and buffer.h are common dependencies for the specific list of OBJ files.

Although the Makefile file is used in this style, it is more short, but some people think that the information of each goal is more clear and easy to understand without like this style.

2.7 Rule of the file in the directory

The compiler is not the only thing to write the Make rule. The Makefile file can tell Make to complete other tasks other than the compiler, for example, how to delete the OBJ file and executive file to keep the directory 'clean', etc. Here is an example of deleting an editor using the Make rule:

Clean:

RM Edit $ (Objects)

In practical applications, more complicated rules should be written to prevent unpredictable situations. Closer to the practical rule style:

.Phony: Clean

Clean:

-rm edit $ (Objects)

This prevents Make from chaos because there is a file called 'Clean', and causes an error in executing the RM command (see the desired target and command error two content).

Such a rule cannot be placed on the beginning of the Makefile file, because we don't want it to become the default final goal. Like our makefile file example, put the rules of Edit on front, thus setting compilation update Edit executable to the default final goal.

3 Write the Makefile file

The information based on the Make compile system is derived from a database called a makefile file.

3.1 Makefile file content

The Makefile file contains 5 aspects: specific rules, implicit rules, define variables, instructions, and comments. Rules, variables, and instructions will be introduced in subsequent chapters.

l Specific rules for explaining when or how to regenerate one or more files called rule targets. It enumerates the document that is depends on, which is called the dependence of this goal. Specific rules may also provide commands for creating or updating the target. See the rules chapter.

l The implicit rule is used to elaborate when or how to re-generate a series of files of the same file name. It describes the goal of creation or update based on the same file as its name, and provides a command to create or update the target. Details Refer to Implied Rule section.

l Defining variables to assign a fixed string value for a variable so that the variable can be used instead of this string in future files. Note Defining variables in a Makefile file accounts for an independent line. In the Makefile file example in the previous chapter, we define the variable objects representing all OBJ files (Details) Use variables to simplify the Makefile file section). l The command is the command that makes a certain task based on the Makefile file. These include the following aspects:

n Read other makefile files (see details of other makefile files).

n Judgment (value according to the value of the variable) is used or ignored some of the contents of the Makefile file (see the conditional statement of the Makefile file).

n Define multi-line variables, that is, the variable that defines a variable value can contain multi-line characters (see the multi-line variable section).

l The row starting with '#' is a comment line. The note will be ignored by Make when handling. If a note is running at the end of the row, it means that the next row continues to comment, so that the comment can last. In addition to the inside the Define instruction, the comment can appear anywhere in the Makefile file, even in the order (here the shell determines what is comment).

3.2 Makfile file naming

By default, when Make is looking for a Makefile file, it tries to search for files with the following name, in order: 'gnumakefile', 'makefile', and 'makefile'.

Normally you should name your makefile file 'makefile' or 'makefile'. (We recommend using 'Makefile' because it basically appears in front of the list of directory, followed by other important files such as 'Readme', etc.). Although we first search for 'gnumakefile', we are not recommended. Unless your Makefile file is written in GNU Make, you can't execute on other Make versions, you should use 'gnumakefile' as your Makefile file name.

If Make can't find a file with the names described above, it will not use any Makefile file. This way you must use the command parameter given the target, Make tries to use the built-in implicit rules to determine how to rebuild the target. See Using the Implied Rule section for details.

If you use a non-standard name Makefile file, you can specify your Makefile file using the '-f' or '-file' parameter. Parameters '-f name' or '--file = name' can tell the Make read the file as the 'name' as the Makefile file. If you use '-f' or '--file' parameters than one, you specify multiple Makefile files, all Makefile files act in specific order. Once you use the '-f' or '-file' parameter, it will no longer check if there is a Makefile file named 'gnumakefile', 'makefile' or 'makefile'.

3.3 Contains other Makefile files

The include instruction tells Make to suspend the current makefile file, first read the Makefile file specified by the include instruction. The instructions account for a single line in the Makefile file, and its format is as follows:

Include FileNames ...

FileNames can contain the format of the shell file name.

At the INCLUDE directive line, the extra spaces at the beginning of the row is allowed, but the Make is ignored when these spaces are processed, note that the row cannot start with TAB characters (because the line begins with Tab characters, Make considers the command line). Include and file names are spaced apart from spaces, and the two file names are also spaced apart from spaces, and excess space Make is ignored, and the tail of the row can be added with '#' as an annotation. File names can include variables and function calls, which are expanded by Make when processed (for specific contents). For example, there are three '.mk' files: 'a.mk', 'b.mk' and 'C.MK', Variable $ (BAR) extension to bish bash, then the following expression is:

INCLUDE FOO * .MK $ (BAR)

And 'include foo a.mk b.mk c.mk bish bash' is equivalent.

When Make meets the Include instruction, Make suspends the current Makefile file, read the listed Makefile file. After reading, make, then continue to read the contents of the include command in the current Makefile file.

One case using the include instruction is a single Makefile file, but they need a series of common variable definitions (detailed sequestration variables), or a series of common format rules (Details See definition and redefine Format rules).

Another use of the include instruction is a case where it is necessary to automatically generate dependencies from the source file. At this time, relying on the file contained in the main Makefile file. This approach is more simple than other versions of Make depends on the traditional way of attachment in the main Makefile file. Details of specific contents are automatically dependent.

If the Makefile file name does not start with '/', you can't find it in the current directory, you need to search for additional directories. First, search the directory specified by '- |' or '-include-Dir' parameter, then search the following directory (if they exist): 'prefix / include' (usually '/ usr / local / include' ) '/ usr / gnu / include', '/ usr / local / include', '/ usr / include'.

If the specified Makefile file cannot be found in all the directories described above, Make will generate a warning message, pay attention to this is not a fatal error. After processing the Makefile file included in the include instruction, continue to process the current Makefile file. Once the read operation of the Makefile file is completed, Make will try to create or update the outdated or not existing Makefile file. Details Refer to the Makefile file to regenerate the process. Only after all Make seek lost Makefile files fail, Make can determine the lost Makefile file is a fatal error.

If you want to ignore the Makefile file that does not exist and cannot recreate, and does not generate an error message, use the -include instruction instead of the include directive, the format is as follows:

-include filenames ...

The role of this instruction is to generate an error for any non-existing Makefile file (even if the warning information will not be generated). If you want to keep and other versions of Make compatible, use the Sinclude instruction instead of the -Include instruction.

3.4 Variable Makefiles

If the environment variable Makefiles is defined, the value of this variable is to be a column of attached Makefile file names, and the file name is spaced from the space, and these makefile files should first be read. Make Completes this work and the way the include instruction is completed in the same way, that is, search for these files in a specific directory. It is worth noting that the default ultimate goal does not appear in these makefile files, and if some Makefile files are not found, no error messages will occur. Environmental variables Makefiles mainly in the MAKE recursive call process (for details, see recursive Make). It is not a very good idea to set the environment variable before Make top call, because it is easy to make the Makefile file with the outside world more confusion. However, if you miss the Makefile file, the Makefile file in Environment Variable Makefiles can make the built-in implicit rules, such as the search defined path (see the search dependence in the directory).

Some users like to automatically set up temporary environment variables Makefiles while logging in, and the Makefile file is only used when the file specified by the variable is invalid. This is a very bad idea, and you should run in this case in this case for many Makefile files. The best way is to write specific Include instructions directly in the Makefile file (see the previous section).

3.5 Makefile file regenerated process

Makefile files can be regenerated by other files, such as generating from RCS or SCCS files. If a Makefile file can be regenerated from other files, be sure to let the makefile file after reading the Makefile file.

After reading all the makefile files, make checks each target and try to update it. If you have an Makefile file, how it is updated (whether it is in the current makefile file or other Makefile file), or there is a hidden rule to explain how it is updated (for details, please use an implicit rule), When the makefile file will be automatically updated. After all Makefile file checks, if you find that any Makefile file changes, make will empty all records and re-read all Makefile files. (Then try again to update these makefile files, normal conditions, because these makefile files have been updated, Make will no longer change them.)

If you know that your one or more Makefile files cannot be recreated, you may not want Make to search or rebuild them in accordance with the implicit rules, you should use the normal method to check them in accordance with the implicit rules. For example, you can write a specific rule that uses these makefile files as a target, but does not provide any commands (see empty commands).

If you specify a file in the Makefile file to rebuild a file, but no dependence, once the board will rebuild the file (see the Details Download Rules). Similarly, if you specify a Makefile file reconstructed in the Makefile rule using the command, and does not provide dependencies, once the makefile file is rebuilt, then re-read all makefile files, and then rebuild the makefile file. , Reread all Makefile files, so that you can fall into an infinite loop, can't make another task again. If you want to avoid the above situation, be careful not to use commands in accordance with the double-selling rules and do not provide dependencies to rebuild any Makefile files. If you don't use '-f' or '-file' to specify your Makefile file, Make will use the default Makefile file name (see section 3.2 for details). Not like using the '-f' or '--file' option to specify a specific Makefile file, then Make cannot determine if the Makefile file exists. If the default makefile file does not exist, but can be created by the rule based on the rule, you will need to run these rules to create the Makefile file you want to use.

If the default makefile file does not exist, Make will try to create them according to the order of search, until you have successfully created your Makefile file or make all the files in the name. Note Make can't find or create a makefile file is not an error, the makefile file is not running Make must.

Because even if you use '-t' special specified, '- t' or '--tonch' option does not generate any impact on the update makefile file, the Makefile file will still be updated, so when you use '-t' or '--Touch At the time of option, you don't use the outdated Makefile file to determine which target (specific meanings). Similarly, because '-Q' (or '--question') and '-N' (or '--just-print') can also prevent the Makefile file, it will generate an error to other targets for other goals. Output results. For example, 'make -f mfile -n foo' command will perform this: update 'mfile', then read, then output update 'foo' command and dependence, but do not perform the update 'foo', pay attention, all returns The update 'foo' command is specified in the updated 'mfile'.

In the actual use process, you will have to meet the situation that does want to block the update makefile file. If so, you can need to update your Makefile file in the Makefile file command line, so you can prevent the Makefile file. Once the Makefile file name is explicitly specified as a target, the option '-t' will work on it. As such, the 'make -f mfile -n foo' command will perform this: read the command and dependence of 'mfile', output Update 'foo', but does not perform update 'foo'. The renovation of the update 'foo' is included in the existing 'mfile'.

3.6 Observation Other Makefile Files

Sometimes a Makefile file is also useful to be similar to another makefile file. You can use the 'include' instruction to put more Makefile files in, so add more goals and defined variables. However, if the two Makefile files give different commands for the same target, Make will generate errors.

In the primary makefile file (where to include the other Makefile file), you can use the wildcard format rule instructions Only when you rely on the current Makefile file cannot re-create the target, Make searches for other Makefile files, see the details Redefine the format rules. For example: If you have a Makefile file that explains how to create a target 'foo' (and other targets), you can write another Makefile file called 'gnumakefile' containing the following statement:

Foo:

Frobnicate> foo

%: force

@ $ (Make) -f makefile $ @

FORCE:;

If you type 'make foo', Make will find 'gnumakefile', read, and then run 'froblicate> foo'. If you type 'make bar', the make found that 'Bar' cannot be created according to 'gnumakefile', which will use the command provided by the format rule: 'make -f makefile bar'. If the rule of 'bar' update is provided in 'Makefile', Make will use this rule. Target Make, which does not provide update, will also be processed without providing other 'gnumakefile'. This way of work is to use the format match in the format rule '%', which matches any target. This rule specifies a dependency 'force' to ensure that the command must be executed, regardless of whether the target file exists. When we give the target 'force', use an empty command, which prevents Make from searching and creating it according to implicit rules, otherwise, make, make the same match rule to the target 'Force' itself, causing a loop that creates dependencies in.

3.7 Make reads the process of makefile file

GNU Make divides its jobs into two phases. In the first phase, Make reads the Makefile file, including the Makefile file itself, built-in variables, and its values, implies rules, and specific rules, and construct all targets, depending on charts and their dependencies. In the second phase, MAKE uses these built-in organizations to determine the goals that need to be reconstructed and operate using the necessary rules.

Understanding the Make two phases is important because it directly affects variables, function extensions; this is also one of the main sources of errors when writing Makefile files. Below we will summarize the extension methods of different structures in the Makefile file. We said that the extension occurred in the first phase of Make is an immediate extension: In this case, Make uses the variable and function directly into a part of the structural unit when analyzing the Makefile file. We refer to the extended extension that cannot be performed immediately as delay expansion. Delay expansion structure until it has appeared in the context structure or Make has entered the second working phase.

You may not be familiar with this part. You can read this section after reading the following chapters.

Variable assignment

The definition of variables is as follows:

Immediate = deferred

Immediate? = deferred

immediate: = immediate

Immediate = deferred or immediate

Define immediate

Deferred

Endef

For additional operators ' =', the right variable is the immediate variable if the extension variable is used in front (: =), and the other is delay variable.

Conditional statements

Overall, the conditional statements are immediately analyzed according to the syntax, commonly used: IFDEF, IFEQ, IFNDEF, and Inneq.

Define rules

Regulations are expanded in the same way regardless of its form.

Immediate: immediate; defrreddeferred

Both the goals and dependencies are expanded immediately, and commands for constructing targets are usually delayed. This general law applies to specific rules, format rules, suffix rules, static format rules, and simple dependencies.

4 write rules

The rules in the makefile file are used to explain when and how to rebuild specific files, these specific files are called the target of this rule (usually, only one target for each rule). Other files listed in the rules are called target dependencies, while the rules also give the target creation, updated commands. Under normal circumstances, the order of rules is irrelevant, but it is an exception to the default final goal. The default final goal is that when you don't specify a final goal, the MAKE determines the final goal. The default ultimate goal is the goal of the first rule in the makefile file. If the first rule has multiple goals, only the first goal is considered to be the default ultimate goal. There are two exceptions: the goal begins with the period ('.') Is not the default final goal (if the target contains one or more slashes '/', the target may also be the default final target); One situation is that the format rule definition is not the default final goal (see definition and redefining format rules).

So, when we write Makefile files, the target of the first rule is usually set to compile all programs or all programs expressed by the makefile file (often set a target called 'all'). See the specified parameters of the final goal.

4.1 Syntax of the Rule

Usually a rule form is as follows:

Targets: Prerequisites

Command

...

or:

Targets: prerequisites; Command

Command

...

Target is the name of the file, separated by spaces. Wildcards can be used in the file name (see the file name in the file name), the file name in 'a (m)' form means member M in file a (see file member target). Under normal circumstances, a rule has only one goal, but occasionally a number of objectives due to other reasons (see rules with multiple targets).

The command line begins with Tab characters, the first command can be separated from the semicolon between one line, command and dependence, or the start of the Tab character is the start of the TAB character. The effects of these two methods are the same, see the commands in the rules.

Because the dollar symbol has been used for the start of the variable reference, if you really want to use the dollar symbol in the rule, you have to write twice, '$$' (see Use the variable). You can put a long walk in the middle into '/' make it divided into two lines, that is, the end of the end is '/', indicating that the next line is the continuation of the Bank. But this is not necessary, Make does not limit the length of the Makefile file. A rule can tell Make two things: When the goal is over, and how to update them if necessary.

Judging the criteria and dependencies of the target outdated guidelines and dependencies, depending on the file name, the file name is spaced from spaces, and wildcards and file members are also allowed to appear in dependencies. If a goal does not exist or it is better than one dependent modification time, the target is over. This idea is derived from the goal to calculate depending on the information, so the target file is no longer valid once any one dependent changes. The update method of the target is determined by the command. The command is performed by the shell, but there are some additional features. See Using commands in rules.

4.2 Using wildcards in the file name

A simple file name can represent many files by using wildcard characters. Wildcards in Make and the wildcards in the Bourne Shell are '*', '? 'with'[…]'. For example: '*. C' means all files ending with '.c' in the current directory. The characters '~' also has special meanings in front of the file name. If the characters '~' is separate or behind, you represent your home directory. Such as '~ / bin' extension is '/ home / bin'. If the character '~' is followed by one word, it extends to the list of the name of the name in the home directory, such as '~ john / bin' represents 'Home / John / bin'. There is no HOME directory in some operating systems (such as MS-DOS, MS-Windows), which can be simulated by setting environment variables Home.

Automatic extension of wildcards in target, dependency, and commands. In other context, wildcards are only expanded when you express the call.

Another feature of a wildcard is that if the front of the wildcard is a backslash '/', the wildcard is lost. If 'foo / * bar' represents a specific file, its name is made of 'foo', '*' and 'bar'.

4.2.1 Wildcard Example

A wildcard can be used in a rule command, and the wildcard is extended by the shell. For example, the following rule deletes all OBJ files:

Clean:

RM -F * .O

Wildcard is also useful in the dependence of rules. In the following Makefile rules, 'make print' will print all from the last time you print, '.c' files:

PRINT: * .C

Lpr -P $?

Touch Print

This rule uses 'Ptint' as an empty target file (see Using Air Target File Record Event); Automatic Variable '$?' Is used to print those files that have been modified, see Automatic variables.

When you define a variable, the wildcard will not expand, if you write:

Objects = * .o

The value of the variable Objects is actually string '* .o'. However, if you use the value of the variable Objects in a goal, dependent, and command, the wildcard will be extended at that time. Use the following statement to extend wildcard:

Objects = $ (Wildcard * .o)

Details Reference Function Wildcard.

4.2.2 Common errors using wildcards

There is an example of a naive use of wildcard expansion, but in fact this example cannot complete the task you want to complete. Suppose the executable file 'foo' is created by all OBJ files in the current directory, and its rules are as follows:

Objects = * .o

Foo: $ (Objects)

CC -O Foo $ (CFLAGS) $ (Objects)

Since the value of the variable Objects is the string '* .o', the wildcard is extended under the rules of the target 'foo', each OBJ file will become the dependence of the target 'foo', and recompile yourself if necessary.

But if you have deleted all OBJ files, what will happen? Due to the file that does not match the wildcard, the target 'foo' relies on a file "* .o 'with a strange name. Because the file does not exist in the directory, Make will issue an error message that cannot create '* .o'. This is not the task to be executed.

In fact, it is possible to obtain the correct result using wildcards, but you must use a slightly complicated technique, which includes using functions Wildcard and alternative strings. Details will be discussed in the next section.

Microsoft's operating system (MS-DOS, MS-Windows) uses a backslash to separate directory paths, such as:

C: /foo/bar/bar.c

This is the equivalent of UNIX style 'c: /foo/bar/bar.c' ('C:' is a drive letter). When Make is running on these systems, not only supports the back slant bums in the path, but also supports the front slash of UNIX style. However, this support for the backslash does not include wildcard expansion because the backslash is used as a reference character when the wildcard is expanded. So, in these occasions you must use the front slash of the UNIX style. 4.2.3 Function Wildcard

Wildcards can extends automatically in rules, but the wildcards are generally not expanded in the variable or in the parameters of the function. If you need to extend wildcards in these occasions, you should use the function wildcard, the format is as follows:

$ (Wildcard Pattern ...)

This string can be used anywhere in the Makefile file, which is used by a file that is included in the specified directory and the file name and the format given in the file name, and the file name is separated by the space. If there is no file consistent with the specified format, the output of the function Wildcard will be omitted. Note that this is different in the form of wildcard extensions in the rules, and uses typography extensions in rules, rather than omitting mode (see the previous section).

Use the function Wildcard to get the command format of all C language source file names in the specified directory:

$ (Wildcard * .c)

We can convert the string of the obtained C language source file name by converting the '.c' suffix to '.o' to the OBJ file name, its format is:

$ (PATSUBST% .c,%. O, $ (Wildcard * .c))

Here we use another function: PATSUBST, details Refer to the string replacement and analysis functions.

This way, a Makefile file that compiles all C language sources and connects them together, can be written as the following format:

Objects: = $ (PatSubst% .c,%. O, $ (Wildcard * .c))

Foo: $ (Objects)

Cc -o foo $ (Objects)

Here, the implied rules for compiling C language source programs are used, so there is no need to write specific compilation rules for each file. ': =' Is the variation of '=', the explanation of ': =', refers to the variables of two styles.

4.3 Search for dependence in the catalog

For large systems, place the source file in a separate directory, and put the binary file in another directory is very common. Make's directory search characteristics make automatic search dependence on several directory. You don't have to change your separate rules in a few directorys, you don't have to change the separate rules, just change the search path.

4.3.1 vPath: All dependent search paths

The value of the Make variable vPath specifies the Make search directory. It is often used by those directories that contain dependencies, not the current directory; but VPath specifies the directory search sequence that makes all files, including the files required for the rule.

If a file as a target or dependencies do not exist in the current directory, Make will search for the file in the directory specified by the VPath. If you find the file you want to find in these directories, just as these files are in the current directory, the rules specify these files as dependencies. See writing the shell command for the search directory.

In the vPath variable definition, the name of the directory is separated by a colon or space. The order listed in the catalog is also the order of Make search. In the MS-DOS, MS-Windows system, the name of the directory in the VPath variable definition is separated by a semicolon because in these systems, the colon is used as part of the path name (usually behind the drive letter). E.g:

Vpath = src: ../ Headers

Two directories, 'src' and '... / headers', and make also search in this order. Use the value of this vPath, the following rules, foo.o: foo.c

When executed, it will be interrupted as follows:

FOO.O: SRC / FOO.C

Then search for foo.c in the SRC directory.

4.3.2 VPATH Directive

VPATH instructions (note letters are lowercase) and VPath variables, but more flexible. The VPATH directive allows a search path to specify a search path to match the file name of a certain format. This way you can specify a search path to a file name of a format type, specify another search path to the file name of the additional format type. A total of three forms of VPATH instructions:

VPath Pattern Directories

Specify a search path to a file name of a certain format type. The search path consists of a directory to search. The directory is separated by a colon (in the MS-DOS, MS-Windows system separated by semicolons) or spaces, and the vPath variable defines the path format to search.

vPath Pattern

Clear the search path in connection with a certain type of format.

vPath

Clear all the search paths specified by the VAPTH instruction.

A VPath format pattern is a string containing a '%'. This string must match a dependent file name that is searching, character% can match any string (regarding format rules, see definition and redefining format rules). For example,%. H and any file name match the file ended with .h. If you do not use '%', the format must match dependence, which is rarely used.

The character '%' in the VPATH instruction format can be referenced by the front backslash. Reference other character '%''s backslash can also be referenced by more backslash. Reference characters '%' and other backslashes are separated before and in the format before comparing with the file name. If the characters '%' referenced by the backslash is not wrong, the backslash does not run any hazard.

If the VPath instruction format matches the dependencies, and the dependencies in the current directory do not exist, the directory specified in the VPATH command can be searched. E.g:

vpath% .h ../headers

Tell Make If there is no existence in '.h' end file in the current directory, search for any end of '.h' ending.

If there are several VPATH instruction formats and a dependent file name match, make an opportunity to handle them, search all the directories specified in the instruction. Make controls multiple VPATH instructions in the order that appears in the makefile file, although multiple instructions have the same format, but they are independent of each other. The following code:

vpath% .c foo

vpath% blish

vpath% .c bar

Represents the search `.c 'file first search the directory` foo', then `blish ', last` bar'; if it is the following code:

vpath% .c foo: bar

vpath% blish

Represents the search `.c 'file first search the directory' foo ', then' bar ', the last' Blish '.

4.3.3 Directory Search Process

When search through the directory, you may not be the dependency you listed in the list; sometimes the path to finding through the directory can also be discarded. Make decides that the algorithm based on the path saved or discarded through the directory search:

1. If a target file does not exist in the directory where the Makefile file is located, the directory search will be performed.

2. If the directory search is successful, the path and the resulting file are temporarily stored as the target file.

3. All the goals are based on the same method.

4. After the dependency processing is completed, the target may or does not need to be recreated: 1. If the target does not need to rebuild, the path of the file obtained when the directory search is used as the target of all dependencies, and contains the target file. . In short, if Make doesn't have to rebuild the target, you use the path to get through the directory.

2. If the target needs to rebuild, the path of the file obtained when the directory search will be discarded, and the target file is rebuilt in the directory where the Makefile file is located. Briefly, if Make wants to rebuild the target, it is to rebuild the target in the directory where the Makefile file is located, not the path of the file obtained when the directory search is.

This algorithm seems to be more complicated, but it can be very accurate explanation that is actually what you want.

Other versions of Make use a relatively simple algorithm: if the target file does not exist in the current directory, and it is available through the directory, whether or not the target needs to be rebuilt, always use the path to search through the directory.

In fact, if you have this behavior in GNU Make, you can use the GPath variable to specify these directories.

The GPath variable and VPath variable have the same syntax and format. If you search for an outdated goal through the directory, the target existing directory appears in the GPath variable, the path will not be discarded, and the target will be rebuilt under the path.

4.3.4 Write the SHELL command to search for the directory

Even if you find a depending in other directories through a directory, you cannot change the rule, which is also performed in the original written manner. Therefore, you should carefully write these commands so that they can handle dependencies in Make to find dependencies.

With automatic variables such as '$ ^', you can use the shell command (see Auto Variable). For example, the value of '$ ^' represents all depends on the list and contains the directory looking for the dependencies; '$ @''s value is the target.

Foo.O: foo.c

CC-C $ (cflags) $ ^ -o $ @

Variable CFLAGS has the existence that you can easily use the implicit rules to designate the flag of the C language source program. We use it here to maintain compilation C language source program consistency. See the variables used in implied rules.

Relying on usually contains header files, because the value of automatic variable '$ <' is the first dependence, these header files You do not have to mention in the command, for example:

Vpath = src: ../ Headers

FOO.O: foo.c defs.h Hack.h

CC-C $ (CFLAGS) $ <-O $ @

4.3.5 Directory Search and Implicit Rules

The search directory is specified by the VPATH instruction introduced by the variable vPath or implicit rules (detailed reference to use implicit rules). For example, if the file 'foo.o' has no specific rules, make uses an implicit rule: such as file foo.c exists, make uses built-in rules; if the file foo.c is not in the current directory, search for appropriate Directory, such as finding foo.c in other directories, Make also compiles it using built-in rules.

The commands of the implicit rules are required to use auto variables, so implicit rules can naturally use the files obtained by the directory.

4.3.6 Search Contents for Library

For the connection library file, the directory search uses a special way. This special way is derived from a joke: You write a dependence, its name is the form of '- | name'. (You can write some strange characters here, because depending on normal is some file names, library names usually have the form of 'libname.a', not '- | name' form.)

When a dependent name is' - | name ', Make specially in the current directory, in the directory of VPATH, and' / lib ',' / usr / lib ', and' Prefix / lib '(normal condition is `/ usr / local / lib", but MS-DOS, MS-Windows version of Make behavior seems to be the root directory of the PREFIX defined as the root directory of the DJGPP installation tree) The search name is' Libname.so 'files are then processed. If you don't search for 'libname.so' file, then search the 'libName.a' file in the aforementioned directory. For example, if you have '/usr/lib/libcursees.a' in your system, then:

Foo: foo.c -lcurses

CC $ ^ -o $ @

If 'foo' is older than 'foo.c', the command 'cc foo.c/usr/lib/libcurses.a -o foo' is executed.

By default, the 'libName.so' and 'libname.a' files, the specific search files and their types can be specified using .LibPatterns variables, each word in this variable value is a string format. When looking for dependencies named '- | name', Make first forms a library name to be searched using the format part in the first word in the NAME alternative list, and then use the library file name in the above directory. If the library file is not discovered, the next word in the list is used, and the rest is pushed.

The .LibPatterns variable default value is "'lib% .so lib% .a'", which supports the default behavior described earlier. You can completely close the extension of the connection library by setting this value to null value.

4.4 Immortal Target

The imaginary goal is not a real file name, it is just the name of some of the commands you have made by a specific rule. There are two reasons for using false ideas: to avoid and have the same name conflict and improve performance.

If you write a rule that does not create a target file, once you refer to this goal due to rebuild, the command of the rule will execute. Here is an example:

Clean:

Rm * .o Temp

Because the RM command does not create a file named 'Clean', there should be no file named 'Clean'. Therefore, whenever you release the `make Clean 'instruction, the RM command will execute.

Imaginary goals can terminate any files that create named 'Clean' in the directory. However, if the file Clean exists in the directory, because the target clean does not depend on, the file clean will always think that it has been updated, so its command will never perform. To avoid this, you should use the following special. Phony target format as a false destination target:

.Phony: Clean

Once this is declared, 'make clean' commands regardless of whether there is file named 'Clean' in the directory, the target command will execute.

Because Make knows the imaginary target is not a actual file that needs to be recreated according to other files, it will skip the steps of hidden rules to search for false ideas (detailed) Use implicit rules). This is why a goal declares for imaginary goals can improve the efficiency of performing efficiency, so you don't have to worry about whether there is actual file in the directory. In this way, the previous example can be written by imaginary objectives, and its format is as follows:

.Phony: Clean

Clean:

Rm * .o Temp

Another example using the imperative target is a case where the recursive call using Make: At this point, the Makefile file often contains a variable that enumerate a series of subdirectories that need to be created. The method of doing this task without imaginary goals is to use a rule, which is a shell command that is loop in each subdirectory, as follows: Subdirs:

For Dir IN $ (SubDirs); Do /

$ (MAKE) -C $$ DIR; /

DONE

However, there is a problem with this method: First, this rule does not discover any errors generated during the creating subdirectory, so when a subdirectory creates fails, the rule will continue to create the remaining subdirectory. Although this problem can add a surveillance error generated and exiting the shell command to solve, very unfortunately if Make uses '-k' options, this problem will still be generated. Second, maybe more importantly, you use this method to lose the feature capability that uses the Make parallel.

Use the imaginary target (if some subdirectories already exist, you must do this, otherwise, the subdirectory that does not exist will not be created), you can avoid the above problems:

Subdirs = foo bar baz

.Phony: SubDirs $ (Subdirs)

Subdirs: $ (SUBDIRS)

$ (Subdir):

$ (Make) -C $

Foo: baz

At this point, if the subdirector 'BAZ' is not created, the subdirectory 'foo' will not be created; this relationship is especially important when trying to use parallel creation.

A virtual goal should not be a dependency of an actual target file. If so, make each time the rule is executed, the target file is updated. As long as the imaginary goal is not a real goal, the hypothetical target is executed only when the fake goal is used as a special goal (see Specify the parameters of the final target).

Imaginary goals can also be dependent. When a directory contains multiple programs, you can easily describe the updates of multiple programs in a Makefile file using virtual objectives. The ultimate goal of reconstruction is the target of the first rule of the makefile file, but the multiple programs as the virtual target can be easily completed in a Makefile file to describe multiple programs updates. Such examples:

All: PROG1 PROG2 PROG3

.Phony: All

PROG1: PROG1.O Utils.o

cc -o prog1 prog1.o utils.o

PROG2: PROG2.O

Cc -o prog2 prog2.o

PROG3: PROG3.O Sort.o Utils.o

Cc -o prog3 prog3.o sort.o utils.o

In this way, you can rebuild all programs, or you can rebuild one or more of them (such as 'make prop1 prog3') in the form of parameters.

When a hypothetical goal is another imaginary target, the imaginary target will be a subroutine of an imaginary target. For example, here 'make cleanall' is used to delete the OBJ file, DIFF file, and program files:

.Phony: CleanAll Cleanobj Cleandiff

Cleanall: Cleanobj Cleandiff

RM Program

Cleanobj:

Rm * .o

CLEANDIFF:

Rm * .diff

4.5 Rules without commands or dependencies

If a rule does not depend on, there is no command, and the target of this rule is not an existing file, then make as long as the rule is running, the goal has been updated. This means that all targets dependent on this rule, and their commands will always be executed. Here is an example:

Clean: Forcerm $ (Objects)

FORCE:

The target 'FORCR' satisfies the above special conditions, so performs the commands of the total to force it with the target 'clean' it is dependent. Regarding the name of 'FORCR', there is no special requirement, but 'forcr' is the name of the habit.

Maybe you have understood that the use of 'FORCR' is the same as the result of using the imaginary target (.phony: Clean), but the use of false destination is more specifically and more flexible, because some other version of Make does not support the imaginary target, 'FORCR 'Appears in many makefile files. See the imaginary target.

4.6 Using an empty target file record event

Empty goals are a false target variable that controls some commands, which can be used to complete some specific tasks. But it is not like a real hypothetical goal, its target file can actually exist, but the content of the file is not related to this, usually, these files have no content.

The purpose of the empty target file is the time to record the last execution of the rule's command, and the time for the last change of the empty target file. It can be implemented like this is because there is a 'touch' command used to update the target file in the command of the rule. In addition, there should be some dependencies (otherwise the empty target file does not exist). If the empty target is more dependent on it, the relevant command will be executed when you command to rebuild the target file. Here's an example:

Print: foo.c bar.c

Lpr -P $?

Touch Print

According to this rule, if any source file changes from the last 'make print', type 'make print' to perform the LPR command. Automatic variable '$?' Is used to print those files that have changed (see auto variables).

4.7 Built-in special target name

Some names are used as the target to contain special significance:

l.phony

Special goals. PHONY relies on imaginary goals. The imaginary goal is such a target, and make the Make unconditionally to execute it command, and there is no relationship with the file in the directory and its last update. See the imaginary target for details.

l .quffixes

Special goals. The dependence on Suffixes is a suffix for the suffix rule check. Details Refer to the following suffix rules.

l .default

.Default specifies some commands, which are used for the goals that do not find the rules (specific rules or implicit rules). Details Reference Define the latest type - default rules. If .default specifies some commands, all mentioned files can only be used as dependencies, and cannot be used as any rule; these specified commands are only implemented in their own way. Details See implied rules search algorithms.

l.precious

Special goals. Pred dependence will be processed in accordance with the specific ways given below: If the commands of the commands are executed, make off or interrupts, these goals cannot be deleted, detailed See Close and Interrupt Make; if the target It is an intermediate file, even if it has no use, it cannot be deleted, the specific situation is normal, see the implicit rule chain; other functions of the target and special goals. Secondary overlap. If the rule's objective format matches the dependent file name, you can use the format of the implicit rule (such as '% .o') to list the dependent file as a special goal. PRECIOS to save the intermediate file created by these rules.

l.intermediate

Special goals. Intermediate depends processed as intermediate files. See the implicit rule chain for details. . AllMediate If there is no dependencies, it will not take action.

l.Secondary Special Goals. Secondary's dependencies are processed as intermediate files, but they can never be automatically deleted. See the implicit rule chain for details. .Secondary If there is no dependencies, all targets in all makefile files will be processed as intermediate files.

l .delete_on_error

If the .delete_on_ERROR is mentioned as a target, if the rule changes or its command does not have correct completion, Make will delete the target of the rule, the specific behavior and it is deleted. . Details Refer to the command error.

l .ignore

If you specifically target .ignore points to dependence, make will ignore errors that execute the command when processing these dependencies. If .IGNORE is proposed as an unlinkable target, Make will ignore errors generated when all files are processed. The .ignore command does not have a special meaning, and the use of .Ignore is only compatible with earlier versions. Because .ignore affects all commands, it is not very useful; we recommend you to use other methods to ignore errors generated by a particular command. Details Refer to the command error.

l .silent

If you specifically depends on .silent, Make will not return to recheck the file before executing. If .silents are asked as a no dependence, no command is printed before execution. .Silent does not have a special meaning, which is only compatible with earlier versions. We recommend that you use other methods to handle those who are not printed. Details See the command back. If you want all the commands, please use the '-s' or '-silent' option (detailed reference options).

l. EXPORT_ALL_VARIABLES

As a simple target, as a goal is mentioned, Make will pass the default to the child process. Refer to the variables that communicate with the child Make.

l .notparallel

If .NotParallel is mentioned as a target, even if the '-j' option is given, Make does not use parallel execution. However, the make command that recursively calls can still be executed in parallel (exceptions to the target of .NotParallel in the calling makefile file). Any dependency of .NotParallel will ignore.

Any defined implicit rule suffix is ​​considered a special rule as a target, even if the two suffixs are connected in series, such as '.c.o'. These objects are called suffix rules, which is an excessive definition of implicit rules (currently widely used). In principle, if you want to divide it into two and add them to the suffix list, any target name can be specified. In fact, the suffix is ​​typically start with '.', Therefore, these special targets are also starting with '.'. Refer to the preceding suffix rules.

4.8 Rules with multiple objectives

Rules with multiple targets are equivalent to writing multiple rules, which except for the target difference, in addition to the target difference. The same command is applied to all goals, but the results executed by the command may vary, so you can use '$ @' to assign different actual target names in the command. This rule also means that all goals have the same dependencies.

Rules with multiple targets are quite useful in the following two cases:

l You just need to rely on, but don't need any commands. E.g:

Kbd.o command.o files.o: command.h

Additional common dependencies are given for three objectives.

l All targets use the same command. However, the execution of the command may not be exactly the same, as the auto variable '$ @' can specify the target (see the automatic variable) at the time of reconstruction. E.g:

BIGOUTPUT LITTLEOUT: TEXT.GGGGGGGenerate Text.g - $ (Subst Output, $ @)> $ @

Equivalent to:

Bigoutput: Text.g

Generate text.g -big> Bigoutput

LittleOutput: Text.g

Generate text.g -little> LittleOutput

Here we assume that the program can generate two output file types: one gives '-big', another gives '-Little'. Refer to the string instead and analysis function, interpretation of the function Subst.

If you like to transform depending on the target transform, like the variable '$ @' transform command. You don't have to use a rule with multiple targets, you can use a static format rule. See below for details.

4.9 Targets with multiple rules

A target file can have multiple rules. The dependencies mentioned in all rules will be fused in a list of dependent lists. If the target is more dependent on 'old', all commands will perform the rebuild.

But if one of the above rules give multiple commands to the same file, Make will use the last rule to print an error message. (As a special case, if the file name starts with a point '.' Started, the error message is not printed. This quirky behavior is just to compatibility with other versions of Make). You don't have to write your Makefile file like this, this is what made will give you an error message.

A special dependency rule can be used to provide some additional dependence on multiple target files. For example, using variables named 'Objects', the variable contains list of all output files generated. If the 'Congfig.h' changes all output files must be recompiled, you can use the following simple method:

Objects = foo.o bar.o

FOO.O: Defs.h

Bar.o: Defs.h test.h

$ (Objects): config.h

These can be freely inserted or removed without affecting the actual target file generation rules, if you want to add dependence on the target, this is a very convenient method.

Another method of adding dependencies is to define a variable and use the variable as the parameter of the Make command. Details Refer to variable overload. E.g:

EXTRADEPS =

$ (Objects): $ (EXTRADEPS)

Command` Make Extradeps = foo.h 'The meaning is the dependence of' foo.h 'as all OBJ files, and is not the case if only the' make 'command is entered.

If there is no specific rule to generate a specified command, Make will search for a suitable implicit rule to determine some commands to complete the generated or rebuild. See Using Implicit Rules for Details.

4.10 Static Format Rule

Static format rules are specified multiple targets and can construct a corresponding dependence on each target name. Static format rules are more commonly used than usual rules when used for multiple targets, as the target can do not have to have exactly the same dependence;

4.10.1 Syntax of Static Format Rule

Here is the syntax format of static format rules:

Targets ...: target-pattern: dep-patterns ...

Commands

...

The target list indicates the goal of the rule application. The target can contain wildcards, specifically using the normal target rules (see wildcards) in the file name).

The format of the target and dependence is how to calculate how each target-dependent method. Some strings are extracted from the format of the target name in the match target format, which is called the second. Distribute the track to each dependency format.

Each format usually contains characters '%'. When the target format matches the target, '%' can match any string in the target name; this part of the matching string is called the second; the remaining part must be exactly the same. As the target 'foo.o' match format '% .o', string 'foo' is called a path. The target 'foo.c' and 'foo.out' do not match the format. The dependency name of each target is the use of the '%' generated in each dependency. For example, if a dependent format is'% .c ', the path' foo 'replaces the' foo.c 'generated file name "gene' in the dependency format. In the dependency format, it is not included in the format, and it is the same for all goals.

In the format rule, characters '%' can be referred to in front of the inversion. The backslash of the reference '%' can also be referenced by more backslash. Reference '%', '/' The backslash is compared to the file name or from the format to be removed from the format before replacing it. The backslash does not confuse because of the reference '%'. For example, format `the /% weird //% pattern // 'is` the% weird /' plus character '%', back and string 'pattern //' connection. The last two backslash must remain unchanged because it cannot affect any of the stroke '%'.

There is an example here that compiles the corresponding '.c' file into 'foo.o' and 'bar.o'.

Objects = foo.o bar.o

All: $ (Objects)

$ (Objects):% .o:% .c

$ (Cc) -c $ (cflags) $ <-o $ @

Here '$ <' is an automatic variable, the control-dependent name, '$ @' is also an automatic variable, master the name of the target. See the automatic variable for details.

Each specified goal must match the target format, and if it does not match, a warning is generated. If you have a list of files, only part of these and the format match, you can use the Filter function to remove unqualified files (see string replacement and analysis functions):

FILES = foo.elc bar.o lose.o

$ (Filter% .o, $ (files)):% .o:% .c

$ (Cc) -c $ (cflags) $ <-o $ @

$ (Filter% .elc, $ (files):% .elc:%.

Emacs -f Batch-byte-compile $

In this example, the result of '$ (Filter% .o, $ (files))' is 'bar.o lose.o', the first static format rule is to update the corresponding C language source file to an OBJ file The result of '$ (Filter% .elc, $ (files))' is 'foo.elc', which is constructed by 'foo.el'.

Another example is to clarify how to use '$ *' in static format:

BIGOUTPUT LITTLEOUT:% OUTPUT: TEXT.G

Generate Text.g - $ *> $ @

When the command generate is executed, the $ * extension is diameter, namely one of 'Big' or 'little'.

4.10.2 Static format rules and implicit rules

Static format rules and definitions are a lot of hidden rules for format rules (detailed see definition and redefine format rules). Both sides have formats on the format and constructive relying on the target, the difference is that Make uses their timing.

The implicit rule can be applied to any target it matches, but it is just that the target does not have a specific rule specified command and the dependence that can be searched. If there are multiple implied rules suitable, only one rule is executed, select the definition order according to implicit rules.

Instead, static format rules are used in the target indicated in the rules. It cannot be applied to any other target, and its usage is fixed to each target. If you use two rules with commands, it is wrong. Static format rules may be better than implicit rules because of the following reasons:

l Files that cannot be classified by some file names but can give a list of files, using static format rules to overload implicit rules chains.

l If you cannot accurately determine the path used, you cannot determine whether some irrelevant files causal that Make uses errors implicit rules (because the options for implicit rules are defined according to their definition order). With a static format rule without these uncertainties: Each rule is precisely used for the specified target.

4.11 double colon rules

The two-colon rule uses '::' instead of ':' rules after the target name. When the same goal occurs in one or more rules, the rule processing of the two-colon rules and the usual rules is different.

When a goal occurs in multiple rules, all rules must be the same type: either is a two-depth rule or is all ordinary rules. If they are all double-cut rules, they are independent of each other. If the target is more than a double colon rule, the command of the double colon rule will execute. This can result in all or partially executed with the same target dual colon rules.

The two-colon rules are actually separated by multiple rules with the same objectives, each running independently of each two-colon rules, just like these rules.

For a goal, the double-cut number rules are executed in the order in which they appear in the makefile file. However, a double-colon rule really meaningful occasion is a two-colon rule and an execution order.

The two-colon rules are a bit blurred, which only provides a mechanism for updating the target in different ways in different ways depending on the redeeined files in a particular situation. The actual application of the double-selling rules is very rare.

Each two-colon rule should specify a command. If you do not specify a command, you will use an implicit rule. See Using Implicit Rules for Details.

4.12 Automatic generation dependence

In the Makefile file written for a program, many often need to write only the rules that describe some OBJ files on the header file. For example, if 'main.c' uses 'DEFS.H' through a #include statement, you need to write the rule:

Main.o: Defs.h

You need this rule to let Make know if 'Defs.h' has changed the 'main.o'. Thus, you can understand that you need to write a lot of such rules in your Makefile file. And once you add or remove a #include statement, you must change your Makefile file very carefully.

To avoid this trouble, the modern C compiler can write these rules according to the #include statement in the original procedure. If you need this feature, you can usually add a '-m' switch when you compile the source program, for example, the following command:

cc -m main.c

Generate the following output:

Main.o: main.c defs.h

This way you don't have to write these rules yourself, and the compiler can do this for you.

Note that because of the MakeFile file, the 'main.o' will never be hidden by the hidden rules to be intermediate files, which means that Make will not automatically use it. Delete it; see implied rule chains.

For the old version of the Make program, through a request command, such as 'make depend', the characteristics of the compiler is used to generate dependence is a traditional habit. These commands will generate a 'Depend' file that contains all auto-generated dependencies; then the makefile file can be read using the include command (see containing other makefile files).

In GNU Make, the characteristics of re-constructing the Makefile file make this convention a time-out thing - you will never tell Make to regenerate dependence, because Gnu Make always recombines any Out-of-time Makefile file. See the regenerative process of the Makefile file. We recommend using automatic generation-dependent habits to bring your Makefile file and source files one by one. For example, there is a Makefile file that is 'name.d' 'name.c' and it corresponds to the filefile file, which lists the files represented by the 'name.o' OBJ file. The advantage of this approach is that it is only necessary to rescan new dependencies only if the source program file changes.

Here is a format rule named 'name.d' dependent file based on C language source program 'name.c':

% .d:% .c

Set -e; $ (cc) -m $ (cppflags) $

| SED 's // ($ * /) /. o [:] * // 1.o $ @: / g'> $ @; /

[-s $ @] || RM -F $ @

Information on Define Format Rules See Definition and Redefining Format Rules. The '-e' switch is telling the shell to exit if the $ (cc) command runs failed (non-zero status exit). Under normal circumstances, the SHELL has a status (SED) in the pipe when shell exits, so Make cannot notice the non-zero status generated by the compiler.

For the GNU C compiler, you can use the '-MM' switch instead '-m', which omits the dependence on the system header file. Details Refer to "GNU CC User Manual" Control Pretreatment Options.

The role of the command SED is to translate (for example:):

Main.o: main.c defs.h

To:

Main.o main.d: main.c Defs.h

This allows each '.d' file and the corresponding '.o' file relying on the same source program file and header file, as far, Make can know if any source file and header file change, must be re- Constructs dependencies.

Once you have defined the rules for rebuilding '.d' files, you can use the include command to read them directly, (see containing other Makefile files), for example:

Sources = foo.c bar.c

INCLUDE $ (Sources: .c = .d)

(This example uses an instead of variable references from the source program file list 'foo.c bar.c' to the dependent file list 'foo.d bar.d'. Details Review Replacement references.) So, '. D' The Makefile file is the same as other Makefile files, even if you don't have any further instructions, Make will also rebuild them when necessary. See the regeneration process of the Makefile file.

5 Use the command in the rules

The commands in the rules consist of a series of shell command lines, and one of them is executed in order. In addition to the first command line, the semicolon begins to be attached to the target - dependencies, all of the command lines must start with Tab. The blank line and the notes can appear in the middle of the command line, they are ignored. (But you must pay attention to the 'blank line' starting with Tab is not blank, it is an empty command, see the use of empty commands.)

The user uses a variety of different shell programs, and if other shells are not specified in the makefile file, the commands in the Makefile file are explained using the default '/ bin / sh'. See the command execution.

The shell species used determines whether it is possible to write comments on the command line and write a syntax used by the comment. When using '/ bin / sh' as ​​a shell, the annotation starting with '#' has extended to the end of the line. '#' Don't have to be in the lead, and '#' is not part of the comment.

5.1 Command Back

Under normal circumstances, Make printed first before executing commands, and we can output your commands to the commands you can elapse.

The row of '@' started cannot be exposed, '@' is discarded when it is transferred to the shell. Typical situations, you can use a command to print some content in the Makefile file, such as the echo command to display the process of the Makefile file:

@echo about to make distribution files

When using Make, give the '-n' or '--just-print' flag, only the command is returned and the command is not executed. See Options Overview. In this case, only in this case, all command lines are exposed, even if the command line starting with '@' is also displayed. This logo is very useful for what is the necessary commands that makes Make think that Make thinks is very useful without using the command.

'-S' or '--silent' flag allows Make to block all commands from appearance, as if all rows start with '@'. Use the rules of special targets that do not depend on the Makefile file to reach the same effect (see the built-in special target name). Because '@' uses more flexible so that special goals have now been basically no longer used. Silent.

5.2 Execute Commands

When the command update target needs to be executed, each command line will use a separate sub-shell environment to ensure that the command line is executed. (In fact, MAKE may not affect the shortcut of the result.)

Please note: This means that the shell command to set local variables such as CD will not affect the tight command line; if you need to use the CD command to affect the next command, please put these two commands in one line, Sectional separation, Make will think they are a single command line, put them together to the shell, and then execute them in order. E.g:

Foo: bar / Lose

CD bar; gobble Lose> ../foo

If you like to divide a single command into multiple text, you must use a backslash as the end of each row, except the last line. In this way, multiple text rows constitute a new row by deleting a backslash, then pass it to the shell. As such, the following examples and the previous example are equivalent:

Foo: bar / Lose

CD BAR; /

GOBBLE LOSE> ../foo

The program used as the shell is specified by the variable shell, default, using the program '/ bin / sh' as ​​the shell.

Run on MS_DOS, if the variable shell is not specified, the value of the variable COMSPEC is used instead of the specified shell.

Running on MS_DOS and running on other systems, the processing of setting a variable shell in the Makefile file is different. Because MS_DOS's shell, 'command.com', the function is very limited, so many MAKE users tend to install an instead of shell. Therefore, running on MS_DOS, the MAKE detects the value of the variable shell, and changes its behavior based on the Unix style or DOS style shell. Even if the variable shell is used to point to 'command.com', Make still detects the value of the variable shell.

If the variable shell specifies the unix style shell, Make runs on MS_DOS will attach the specified shell to be truly found; if you can't find it, ignore the specified shell. On MS_DOS, GNU Make searches for the shell as follows:

1. In the directory specified in the variable shell. For example, if Makefile indicates that `shell = / bin / sh ', make will look for subdirectorial' / bin 'under the current path. 2, under the current path.

3, search the variable path specified by sequential PATH.

In all search catalogs, make first looks for a specified file (such as 'sh' in the example). If the file does not exist, Make will search for files with certain executable executable extensions in the above directory. For example: '. EXE', '.com', '.bat', '.btm', '.sh' files and other files, etc.

If you can successfully search for a shell during the above process, the value of the variable shell will be set to the full path file name of the SHELL found. However, if the above efforts have failed, the value of the variable shell will not change, and the validity of the line set will be ignored. This is the reason why the UNIX style shell is only installed in the Make running system, and the make only the reason why the specified UNIX style shell feature is supported.

Note that this extension search for Shell limits the case where the variable shell is set in the Makefile file. If set in the environment or command line, I hope you specify the full path file name of the shell, and the full path file name requires the same accuracy as it is running in the UNIX system.

After the above DOS features, and you also install 'Sh.exe' in the directory specified by the variable Path, or set the `shell = / bin / sh 'in the Makefile file (same as most UNIX Makefile files), Then the operational effect on MS_DOS is exactly the same as in UNIX.

Unlike most of the other variables, the variable shell is never set according to the environment. This is because the environment variable shell is used to specify the shell program that you choose to interact. If the variable shell is set in the environment, it will affect the function of the Makefile file, which is very disadvantage, see environment variables. However, the value of setting the variable shell in the environment in the environment in MS-DOS and MS-Windows is to use, because in these systems, most users do not set the value of the variable, so Make is likely to specify the variable The value to use. On MS-DOS, if the set of variable shell is inappropriate for Make, you can set the variable makeeshell to specify the shell used by Make; this setting will make the value of the variable shell fail.

5.3 execution in parallel

GNU Make can execute several commands at the same time. Under normal circumstances, Make executes a command once, and after it is complete, execute the next command. However, using the '-j' and '--jobs' options will tell Make to perform multiple commands at the same time. On MS-DOS, the '- j' option does not work because the system does not support multi-process processing.

If the '-j' option is followed by an integer, the integer represents the number of the commands of the command executed; this is called the number of Job Slots. If the '-j' option is not integrated, it is not the number of Job Slots. The default Job Slots is one, which means executing in order (executing a command at a time). A less ideal result of simultaneous implementing multiple commands is that the output generated by each command corresponds to the time sent by each command, that is, the message generated by the command can be more confusing.

Another problem is that the two processes cannot be entered using the same device, so it must be determined that only one command can enter from the terminal, and make can only guarantee the standard input stream that is running, and other standard input streams will fail. This means that if there are several ways to input from standard input devices, the most sub-process will produce fatal errors (ie generate a 'Broken Pipe' signal).

Commands are unpredictable to a valid standard input stream (it enters the standard input device from the terminal input or the standard input device for MAKE). The first running command always gets a standard input stream, and another command started after the completion of a command will get the next standard input stream, and so on. If we find a better replacement, we will change this way of working. During this time, if you use parallel processing features, you should not use any commands that need to be entered. If you don't use this feature, any command that requires the standard input will work properly.

Finally, MAKE recursive calls also lead to problems. More detailed content See the option to communicate with the child Make.

If a command fails (aborted by a signal, or non-zero exits), and the error generated by the command cannot ignore (see the command error), the remaining build line will stop working. If a command fails, and '-k' or '--keep-going' option has not given (see Options Overview), make will give up continue execution. If Make is aborted due to some reason (including signals), the child process is running, which will wait until the end of these sub-processes, then actually exit.

When the system is full of load, you may wish to add a task when the load is light. At this time, you can use the '- |' option to tell MAKE to limit the number of tasks running at the same time according to the average load. '- |' or '--max-load' options are generally followed by a floating point number. E.g:

- | 2.5

Make will not be allowed to start a task at an average load of 2.5. '- |' Options If there is no data, cancel the previous '- |' given load limit.

More precisely, when Make launches a task, and it has already running at this time, it will check the current average load; if it is not less than the '- |' option given the load limit Make will wait until the average load is lower than the limit or all other tasks are restarted after all other tasks are completed.

There is no load limit in the default.

5.4 Command error

After each shell command returns, make check the status of the command exits. If the command is successfully completed, the next command line will be executed in the new sub-shell environment. When the last command line is completed, this rule is also done. If an error occurs (non-zero exit status), Make will give up the current rules, perhaps all rules.

Sometimes a specific command failure does not have a problem. For example: You may use the mkdir command to create a directory, if the directory already exists, MKDIR will report an error, but you may want Make to continue.

To ignore an error to execute an error, use character '-' (behind initialization Tab) as the beginning of the command line. The character '-' is discarded when the command passes to the shell execution. E.g:

Clean:

-RM -F * .O

This command is also enforced even if it cannot delete a file.

Using the '-i' or '--ignore-Erroors' when running make, the command running generated by all rules will be ignored. Use the special goals in the makefile file. IGNORE rules, also have the same effect. But because the use of characters '-' is more flexible, the rules are rarely used.

Once the '-' or '-i' option is used, the error generated when the command is run, and the MAKE is handled as a command that has been successfully run. The only difference is to print a message, tell you command. The encoded state is exit and indicates that the error has been ignored. If an error occurs, Make does not indicate that it is ignored, it is impossible to successfully reconstruct the current goal, and the target is also directly related or indirectly related. Since the previous process is not completed, there is no further execution of other commands. In the above case, MAKE generally discards the task and returns a non-zero state. However, if the '-k' or '-keep-onding' option is specified, Make continues to consider the other dependence of this goal, if necessary, redefining them before the Make is discarded returning non-zero status. For example, after compiling an OBJ file error, even if Make already knows that all Obj files are connected together, the 'make -k' option continues to compile other Obj files. Details Reference Options Overview. Typically, Make behavior is based on assumption that your purpose is to update the specified target. Once make know that it is impossible, it will immediately report failed. The '-k' option is to tell the real purpose to test all the changes in all changes in the test program, might find a few independent problems so that you can correct them before compiling. This is the reason why the EMACS compiling command is default the '-k' option.

Typically, when a command is run failure, if it has changed the target file, the file is likely to be confusing without using or if the file is at least not fully updated. However, the timestamp of the file indicates that the file has been updated to the latest, so it will no longer update the file when Make is running next time. This condition and the signal sent by the command forcibly shut down, see Interrupt or close Make. Therefore, if the command is wrong after starting changing the target file, the target file should generally be deleted. If .delete_on_error appears as the target, Make will automatically do these things. This is what you should clearly ask Make execution, not the previous practice; especially when compatibility issues, you should clearly propose such requirements.

5.5 Interrupt or close Make

If Make gets a fatal signal at a command runtime, Make will determine whether it deletes the target file to be updated based on the timestamp of the first check and the timestamp of the last change.

The purpose of deleting the target file is to ensure that the target file is updated from the original file when Make is running next time. why? Suppose you type Ctrl-C when you are compiling, and then you have started writing OBJ file 'foo.o', Ctrl-c shut down the compiler, resulting in an incomplete OBJ file 'foo.o' timestamp ratio The timestamp of the source program 'foo.c' is new. If Make receives the Ctrl-C signal without deleting the OBJ file 'foo.o', the next time make Update Obj file 'foo.o', make will consider it. The file has been updated to the latest without need to update, and the result is a strange error message when Linker connects the OBJ file to the executable file.

You can use the target file as a special target. Precious dependence to prevent Make from deleting the target file. Before rebuilding a goal, make first check if the target file appears in a special target. Precious depends on the list of dependencies, which decides whether to delete the target file when the signal occurs. The reason you do not delete this target file may be: Target update is an atomic style, or the target file exists only for recording change time (its content is not critical), or the target file must always exist, to prevent other types of errors Wait.

5.6 Recursive Call Make

Cassetting means that Make can be used as a command in the makefile file. This technique is very useful when it contains a large system to separate MakeFile into a variety of subsystems. For example, suppose you have a subdirectory 'subdir', which has its own makefile file, you want to use the makefile file when running Make in the subdirector, then you can write: Subsystem:

CD SUBDIR && $ (MAKE)

Or, waiting to write this (see Options):

Subsystem:

$ (Make) -c Subdir

You can only copy the above example to implement Make recursive calls, but you should understand how they work, why do they work, and the relationship between submbe and upper Make.

For convenience, GNU Make sets the value of the variable Curdir to the path currently working. If the '-C' option is valid, it will contain a new path instead of the original path. This value has the same priority as the value set in Makefile (default, environment variable Curdir cannot be overloaded). Note that this value is invalid when operating Make.

5.6.1 Variable Make works

The command to recursively call Make always use the variable make, not a clear command name 'make', as shown below:

Subsystem:

CD SUBDIR && $ (MAKE)

The value of this variable is the file name called Make. If this file name is' / bin / make ', the executed command is `CD subdir && / bin / make'. If you use a specific version of Make when you are on the upper Makefile file, you also use the same version when you perform recursive calls.

Use the variable Make in the command line to change '-t' ('--touch'), '-n' ('--just-print'), or '-Q' ('--question') option . If you use the character ' ' of the command to use the variable make, you will play the same role. See instead of executing commands.

Imagine the execution process of command 'make -t' in the above example. ('-T' option flag target has been updated, but do not perform any commands, see instead of execution commands.) Follow the usual definition, command 'make -t' in the previous example, only create files named 'Subsystem' in the previous example Do other work. What do you actually ask for 'cd subdir && make -t'? Is the execution command or according to '-T' requirements?

This feature of Make is this: As long as the command line contains the variable Make, the flag `-t ',` -n' and `-q 'will not work. Although there is a sign not let the command execute, but the command line containing the variable make is running normally, the Make is actually passed to the child Make via the variable Makeflags (see the option to communicate with the sub-Make). So your verification file, requests for print commands can be passed to the subsystem.

5.6.2 Variables with the sub-Make communication

By clear requirement, the value of the upper MAKE variable can be passed to the child Make with the environment, which can be defined in the submbe. In the case where you do not use the '-e' switch, the value passed by the variable cannot be substituted. Make. The value specified in the Makefile file (see the command summary).

When you pass or output a variable, make the variable and its value into the environment running every command. Submake, acting as a response, using this environment to initialize its variable value table. See environment variables.

In addition to explicitly specifying, Make only outputs downwards and initialized or initialized or in the command line, and the variable names of these variables must consist only from letters, numbers, and underscores. Some shells cannot handle the environment variables of characters other than letters, numbers and underscores. Special variables such as shell and makeflags generally always output down (unless you do not output them). Even if you set the variable makefile to another value, it also outputs down. Make automatically passes the value of the variable defined in the command line, which is placed in the MakeFlags variable. See the next section for details. Make default variable value of variables cannot be passed down, and subkey can define them themselves. If you want to output the specified variable to subkee, use the export directive, the format is as follows:

Export variable ...

You have to block some variables from output to subke, please use the UNEXPORT command, the format is as follows:

UNEXPORT VARIABLE ...

For convenience, you can define and output a variable simultaneously:

Export variable = value

The following format has the same effect:

Variable = Value

Export variable

as well as

Export variable: = value

Has the same effect:

Variable: = Value

Export variable

same,

Export variable = Value

Also also:

Variable = Value

Export variable

See the text for variable values.

You may notice that the Export and UNExport instructions are the same as working in the shell, such as SH.

If you want to output all the variables, you can use export:

Export

This tells Make to output the variables not mentioned in Export and UNEXPORT, but any variables mentioned in UNEXPORT still cannot be output. If you use Export as the default output variable, the names of characters other than letters, numbers, and underscores will not be output, unless you explicitly use the Export instruction to output.

Use Export's behavior alone is the behavior of the boss GNU Make default default. If your makefile relies on these behaviors, and you want to compatibility with the boss GNU Make, you can write a rule for special targets .Export_all_variables instead of the Export instruction, it will be ignored by the boss's GNU Make, but if you use the Export instruction.

Similarly, you can use UNEXPORT to tell make Make not to output variables default, because this is the default behavior, only Exports in front (perhaps in a Makefile) it is necessary. You cannot use the Export and UNExport instructions simultaneously to use the Export and UNEXPORT instructions to do not output to other commands. One of the last instructions (Export or UNEXPORT) will determine all of the MAKE running results.

As a feature, the value of the variable MakeElevel changes when passed from a hierarchy. The value of this variable is a character type, which represents the depth of the layer with a decimal number. '0' represents the top lay Make, '1' representative Make, '2' representative - sub-Make, and so on. Make creates an environment for a command, which increases 1.

The main role of this variable is to test in a conditional command (see the condition statement of the Makefile file); use this method, you can write a makefile, if recursive call uses a way of operation, you control directly to perform another Operation mode. You can use variables madefiles to make all subkey using additional makefile files. The value of the variable Makefiles is a list of Makefile file names, and the file name is separated from spaces. This variable is defined in the outer Makefile, which will be passed downward by the environment; so it can be read as an additional Makefile file as a subkey, before reading normal or specified Makefile files before the subkey reads. See Variable Makefiles.

5.6.3 Options with the subkey communication

Such as '-S' and '-k' flags are automatically passed to subkey via variable Makeflags. This variable is automatically established by Make and contains the logo letter received by Make. So, if you use 'make -ks' variable makeflags to get value 'ks'.

As a result, any submake assigns a value of the variable Makeflags in its operating environment; as a response, MAKE uses this value as a flag, just like the parameters are given as parameters. See Options Overview.

Similarly, the variables defined in the command line will also pass to the subkey by means of the variable makeflags. The words in the Variable Makeflags value can contain '=', Make will process them by variable definition, the process, and the same variable defined in the command line. Refer to the variable overload.

Options `-c ',` -f', `-o ', and' -w 'cannot put into the variable Makeflags; these options cannot be passed down.

The '-j' option is a special example (see parallel execution). If you set it to some value 'n', and your operating system supports it (most UNIX system support, other operating systems are not supported), parent Make and all subkey communication guarantees only 'n' in them. Task run. Note that any task containing recursive calls (see instead of execution command) cannot be calculated within the total task number (otherwise, we can only get the 'n' Make Make run, without excess time slice running).

If your operating system does not support the above communication mechanism, '-j 1' will place the variable Makeflags instead of the value you specified. This is because if the '-j' option passes to the child make, you may get the number of tasks that are more than you have more than you have. If you give the '-j' option without digital parameters, it means that multiple tasks are processed as parallel, which is transferred down because the unlimited system of multiple is 1.

If you don't want other signs to pass down, you must change the value of the variable Makeflags, which changes the way as follows:

Subsystem:

CD SUBDIR && $ (MAKE) Makeflags =

The defined variable in this command line appears in the variable MakeOverrides, and the variable MakeFlags contains the reference value of the variable. If you want to pass the flag down without delivering the variable defined in the command line, then you can set the value of the variable MakeOverrides, the format is as follows:

Makeoverrides =

This is not very useful. However, some systems have a fixed limit on the size of the environment, and this value is smaller, so many information may be more than the value of the variable MakeFlags. If you see 'Arg List Too long''s error message, it is probably due to this problem. (According to strict POSIX.2, if you define a special target '.posix', change the value of the variable MakeOverrides does not affect the variable MakeFlags. Maybe you don't care about it, it is compatible with earlier versions, with the same function Variables MFLAGS also exists. In addition to it does not include the command line definition variable, it has the same value as the variable Makeflags, and unless it is null, its value always starts with a short-term (Makeflags only starts with the multi-character option. " Such as "--Warn-undefined-variables'). Variable MFlags Traditional use in a clear recursive call Make, for example:

Subsystem:

CD SUBDIR && $ (MAKE) $ (MFLAGS)

But now, the variable Makeflags makes this method more. If you want your makefile file and old version of the Make program, use this way; this method can also work well in modern version Make.

If you want to use a specific option to set each time make, for example, '-k' option (see Options), the variable makeflags is very useful. You can simply assign a value to the variable makeflags, or set the variable Makeflags in the Makefile file, and the specified additional flag can work on the entire Makefile file. (Note: You cannot use variables MFlags in this way, and the variable MFlags is only compatible with earlier versions, and it will not be explained in other ways.

When Make explains the variable Makeflags value (regardless of the definition in the environment or defined in the makefile file), if the value does not start with a short-term, make first assumes a short line for this value; then divides the value into words, words and The word is spaced apart from space, and then these words are syntax, as if they are the options given in the command line. ('-C', '-f', '- h', '- o', '- w' options and their long name scripts will be ignored, and error messages are not generated for invalid options.)

If you define a variable Makeflags in an environment, you don't use severely affecting your Make run, destroy your Makefile file and make your own options. For example, '-t', '-n', and '-q' options, if one of them is placed in the value of the variable Makeflags, there may be catastrophic consequences, or at least the annoying result.

5.6.4 '--Print-Directory' option

If you use a few layers of Make recursive calls, use the '-w' or '-Print-Directory' option, by displaying the output of each Make start processing and processing completed, you get more easily understood. For example, if you use the 'make -w' command to run Make in the directory '/ u / gnu / make', make the following format output information:

Entering Directory `/ u / gnu / make '.

Description Enter the directory, no tasks have been made. The following information:

Make: Leaving Directory `/ u / gnu / make '. Description Task has been completed.

Typically, you don't have to specify this option, because Make has done it: When you use '-C' option, '- w' option has been automatically opened, and this is true in child Make. If you use the '-s' option,' - w 'option will not open automatically, because the' -s' option is not printing information, the same use` --NO-print-Directory 'option' -w 'option will not automatically open.

5.7 Define the fixed order command

When you create a variety of targets, you can use the DEFINE command to define a fixed order command when you use the DEFINE instruction, and reference the fixed order according to the rules of these objects. The fixed order is actually a variable, so its name cannot be conflicted with other variable names.

Below is an example of defining a fixed order command:

Define Run-Yacc

Yacc $ (Firstword $ ^)

Mv Y. Tab.c $ @

Endef

Run-yacc is the name of the defined variable; the endef flag is ended; the middle line is the command. The Define instruction does not call the variable reference and function call extension in the fixed order; characters '$', parentheses, variable names, and the like are all part of the value of the variable you define. Define multi-line variables to explain in detail in the command define.

In this example, for any rule that uses the fixed order, the first command is the first output file that relies on the YACC command, YACC command, is named "second Command, is the target file that moves the content of the output file into the rule.

When using a fixed order, the variables used in the rules should be determined instead, and you can replace these variables like alternative to other variables (details of details). Since variables defined by the define directive are variables that are recursively extended, all variable references are expanded when used. E.g:

FOO.c: foo.y

$ (Run-Yacc)

When the fixed order 'run-yacc' is running, 'foo.y' will replace the variable '$ ^', 'foo.c' will replace the variable '$ @'.

This is an example of a realistic example, but it is not necessary, because Make has a hidden rule to determine the command used according to the type of file name involved. See Using an implicit rule.

When the command is executed, each row in the fixed order is processed as the same as the command line in the rule. The front plus a Tab, Make also provides a separate child shell for each line. You can also use the prefix characters (`@ ',` -', and ` ') that affect the command line on each line of the fixed order, see the commands in the rule. For example, use the following fixed order:

@echo "frobnicating target $ @"

FROB-STEP-1 $ <-O $ @ - STEP-1

FROB-STEP-2 $ @ - step-1 -o $ @

Endef

Make will not return the first line, but it is necessary to return to the two command lines behind.

On the other hand, if the prefix character is used in the command line of the reference fixed order, the prefix character will be applied to the fixed order. For example, this rule:

Frob.out: frob.in

@ $ (frobnicate)

Any commands will not be returned to the fixed order. Refer to the command emission.

5.8 Using an empty command

Commands that define what are not dry are sometimes useful, define empty commands to give a command that only contains space without any other things. E.g:

Target:;

Define an empty command for string 'target'. You can also define an empty command using the command line starting with TAB characters, but this is easy to cause confusion because it looks like it looks. Maybe you feel weird, why do we define an empty command? The only reason is to prevent commands provided by hidden rules when preventing target updates. (See Using Implied Rules and Defining the Latest Types of Default Rules)

Maybe you love a null command for the actual target file, because it can be rebuilt. However, this is not a good way, because if the target file actually exists, depending on it is possible to not rebuild, using the imaginary goal is a good choice, see the imaginary target.

6 use variables

The variable is the name defined in the makefile, which is used instead of a text string, which is called the value of the variable. Under specific requirements, these values ​​can replace the target, dependencies, commands, and other parts in the Makefile file. (In other versions of Make, variables are called macros.)

When the Makefile file is read, divided by the shell command in the rule, using the variable defined by '=' defined '=', the variables and functions of the other parts of the Makefile file without expanding the variables defined using the Define instruction. Will expand.

Variables can replace file lists, passed to the compiler's option, the program to perform, find the directory of the source file, output the written directory, or any text you can imagine.

The variable name is not included in ':', '#', '=', any string of the front guide or end space. However, the variable name contains other characters other than letters, numbers, and underscores, as they may be given special meaning in the future, and they cannot pass to subkey through the environment for some shells (see with sub-Make communication variable). Variable names are case sensitive, such as variable name 'foo', 'foo', and 'foo' represent different variables.

Using uppercase letters as the variable name is the previous habit, but we recommend using lowercase letters as a variable name inside Makefile, reserved uppercase letters as a variable name of the control implicit rules or user overload command option parameters. Refer to the variable overload.

A small number of variables use a punctuation or several characters as a variable name, which are automatic variables, and their specific use. See Automatic variables.

6.1 Variable reference

Write a dollar symbol After coming with parentheses or braces, a variable name can be referenced to the value of the variable: '$ (foo)' and '$ {foo}' are valid references to variable 'foo'. This special role of '$' is why you must write '$$ with a single' $ 'in the command or file name.

Quotes of variables can be used anywhere in context: target, dependency, command, vast number of instructions, and the value of new variables, and more. Here is a common example, in the program, the variable saves all the file names of all OBJ files:

Objects = program.o foo.o utils.o

Program: $ (Objects)

CC -O Program $ (Objects)

$ (Objects): Defs.h

The reference to the variable is replaced by strict text, so that this rule is

FOO = C

Prog.O: PROG. $ (foo)

$ (foo) $ (foo) - $ (foo) PROG. $ (foo)

Can be used to compile C language source program 'prog.c'. Because the space in front of the variable value is ignored when the variable is allocated, the value of the variable FOO is 'c'. (Don't write this in your Makefile file!)

The dollar symbol is followed by a character but is not the dollar symbol, parentheses, braces, the character will be processed as a single-character variable name. Therefore, the '$ x' reference variable X can be used. However, in addition to the use of automatic variables, this should be completely avoided in other actual work. See Automatic variables. Two features of 6.2 variables

In the GNU Make, in two ways are assigned to the variable, we will refer to two features of the variable (Two flavors). The difference between the two features is different from their definition and extension.

The first feature of the variable is that recursive call extension variables. This type of variable definition method: uses '=' definition in the command line (see Setting Variable) or use the Define command definition (see Defining Multi-line variables). Variable replacement is replaced by words for the value you specify; if it contains references to other variables, these references are expanded when the variable is replaced (or during the extension to other strings). This extension method is called recursive adjustment type extension. E.g:

Foo = $ (bar)

BAR = $ (UGH)

UGH = huh?

All:; Echo $ (foo)

The appearance of 'Huh?': '$ (Foo)' extension is '$ (bar)', further expands to '$ (UGH)', and finally expands to 'huh?'.

This type of variable is the variable type supported by other version makers, and there is a shortcoming. The advantages of most people think this type of variables are:

CFLAGS = $ (include_dirs) -o

INCLUDE_DIRS = -ifoo -ibar

It is possible to complete the task you want to complete: When 'cflags' is extended in the command, it will eventually expand to '-ifoo -ibar'. The biggest disadvantage is that it cannot add content after variables, as follows:

Cflags = $ (cflags) -o

In the variable expansion process, there may be infinite loops (actually Make detect infinity loops will generate error messages).

Another disadvantage is that when any functions referenced in the definition (see Text Conversion Functions), once the function will be executed once the function is expanded. This can cause MAKE running slow, performance deteriorate; and cause wildcards and shell functions (due to how many times cannot be controlled or how many times) generate unpredictable results.

Another feature variable appears to avoid this problem and recursive call extended variables: Simple extension variables.

Simple extended variables are defined in ': =' in the command line (see Setting Variables). The value of simple extension variables is a scan forever, and other variables and functions referenced are defined when the referenced variables and functions are defined. The value of the simple extension variable is actually the result of the text extension you wrote. Therefore, it does not contain any reference to other variables; there is a value thereof when the variable is defined. and so:

x: = foo

Y: = $ (x) bar

x: = Later

Equivalent to:

Y: = foo bar

x: = Later

When a simple extension variable is referenced, its value is also replaced by word. There is a slightly complex example, illustrated ': =' and shell function connection (see Function shell). This example also indicates the usage of variable MakeElevel, which changes at the time between the layer and the layers. (Refer to the variable of the subkey communication, you can get the information about the variable MakeElevel.)

IFEQ (0, $ {MakeElevel})

Cur-dir: = $ (Shell PWD)

Whoami: = $ (Shell Whoami)

Host-type: = $ (Shell Arch)

Make: = $ {make} host-type = $ {host-type} whoami = $ {whoami} Endif

According to this method, the advantage of using ': =' is to look like a typical 'dropped to the directory' command:

$ {subdirs}:

$ {Make} cur-dir = $ {cur-dir} / $ @ -c $ @ all

Simple extension variables can work like variables in most programming languages, so it enables complex Makefile programs more predictable. They allow you to use its own value to redefine (or it can be processed in some ways by an extension), which also allows you to use more efficient extensions (see text conversion functions).

You can use a simple extension variable to introduce the predecessor space into the value of the variable. The front guiding character is generally discarded when the variable reference and function call. This feature of simple extension variables means that you can include front-conducting felics in a variable value and protect them when variable references. Like this:

nullstring: =

Space: = $ (NULLSTRING) # End of the line

The value of the variable space here is a space, and the comment '# end of the line' includes it here in order to make people more easily understood. Because the space in the tail cannot be separated from the variable value, there is only the same effect on the end of the end (but it is quite difficult to read), if you leave a space after the variable value, you like this on the end of the line. Clearly indicating that your intention is a very good idea. Conversely, if you don't have spaces after the variable value, you must remember not to leave a few spaces later in the back of the row. E.g:

Dir: = / foo / bar # Directory to Put the febs in

The value of the variable DIR here is '/ foo / bar' (four tail spaces), which is not expected. (Suppose '/ foo / bar' is the expected value).

Another operator assigned to the variable is '? =', It is called the condition variable assignment operator because it is only valid if the variable is not defined. This statement:

Foo? = Bar

And the following statement is strictly equivalent (see Function Origin)

IFEQ ($ (Origin foo), undefined)

FOO = BAR

ENDIF

Note that a variable is still defined even if it is a null value, so use '? =' Definition invalid.

6.3 Variables Reference Advanced Technology

This section describes the advanced techniques of variable references.

6.3.1 Replacement reference

The replacement reference is to replace the value of a variable with the variable you specify. Its form '$ (var: a = b)' (or '$ {var: a = b}'), its meaning is to replace the A. of each of the values ​​of the variable var.

We said 'in the end of a word', what we mean is A must appear in the end of a word, and the space is either a space or the end of the variable value, at this time A is replaced, otherwise elsewhere A is not replaced. E.g:

Foo: = a.o B.O C.O

Bar: = $ (foo: .o = .c)

Set the value of the variable 'bar' to 'a.c B.c C.c'. See Variable Settings.

The replacement reference is actually using the extension function PATSUBST (see string replacement and analysis functions). We provide an alternative reference to measures that make the extended function PatSubst and other implementations of Make.

Another replacement reference is to use a powerful extension function PATSUBST. It is the same as the above '$ (var: a = b)' described above, in fact it must contain a single '%' character, in fact, this form is equivalent to '$ (PatSubst A, B, $ (var))'. Refer to the string replacement and analysis functions for the description of the function PATSUBST extension. For example: foo: = a.o B.O C.O

Bar: = $ (foo:%. o =%. c)

The value of the social value variable 'bar' is 'a.c B.c C.c'.

6.3.2 Nested variable reference (calculated variable name)

Nesting variables (calculated variable name) is a complex concept that is used in very complex Makefile programs. Most of the cases you don't have to consider them, just know that the variables containing the dollar logo in the creation of the name may have a strange result. However, if you are interested in people who do what you do, you are interested in how they work, please read the following.

Variables can reference other variables in its name, which is called nested variable references (calculated variable names). E.g:

X = Y

Y = z

A: = $ ($ (x))))

Defining A is 'Z': '$ (x)' extension to 'Y' in '$ ($ (x))', so '$ ($ (x))' extension is '$ (y)', The final expansion is 'Z'. The statement of the referenced variable name here is not clear; it is calculated according to the extension of '$ (x)', so reference '$ (x)' is nesting in outer variable references.

The previous example shows two layers of nested, but any hierarchical nest is allowed, for example, there is a three-layer nested example:

X = Y

Y = z

z = u

A: = $ ($ ($ (x))))))))

Here the most inside of the '$ ($)' Y ', so' $ ($ (x)) 'extension is' $ (y)', '$ (y)' extension is' Z ', ultimately expand 'u'.

Recursive call extension variables in a variable name, then expand in the usual style. E.g:

X = $ (y)

Y = z

z = Hello

A: = $ ($ (x))))

The defined A is 'Hello': '$ ($)' extension to '$ ($ (y)', '$ (y)' change to '$ (z)', $ (z) ) 'Finally expanded to' Hello '.

Nesting variables can also include modifying references and function calls (see text conversion functions) and other references. For example, use a function subs (see string replacement and analysis function):

X = variable1

Variable2: = Hello

Y = $ (SUBST 1, 2, $ (x)))

z = y

A: = $ ($ ($ (z)))))))

Defined A is 'Hello'. Anyone will not write like this is a puzzling nested reference program, but it does work: '$ ($ ($ (z)))' extension is' $ (Y)) ',' $ ( $ (y) 'changes to' $ (SUBST 1, 2, $ (x)) '. It obtains value 'variable1' from the variable 'x', and the transformation is replaced with 'variable2', so the whole string becomes '$ (variable2)', a simple variable reference, its value is 'Hello'.

Nested variables are not all simple variable references, which can contain several variable references, or some fixed text can also be included. E.g,

A_DIRS: = DIRA DIRB

1_DIRS: = DIR1 DIR2

A_Files: = filea fileb

1_files: = file1 file2ifeq "$ (using_a)" YES "

A1: = a

Else

A1: = 1

ENDIF

IFEQ "$ (user_dirs)" YES "

DF: = DIRS

Else

DF: = files

ENDIF

DIRS: = $ ($ (a1) _ $ (df))

The same values ​​of DIRS, 1_DIRs, A_Files or 1_files can be assigned to A_DIRS, 1_DIRS, A_FILES or 1_FILES, depending on the setting of the set of USE_A and USE_DIRS.

Nesting variables can also be used for replacement references:

A_Objects: = a.o B.O C.O

1_Objects: = 1.o 2.o 3.o

Sources: = $ ($ (a1) _Objects: .o = .c)

According to the value of A1, the defined Sources can be `a.c B.c C.c 'or` 1.c 2.c 3.c'.

Using a nested variable reference unique limit is that they cannot be partially specified to be called, because the test used to identify the function name is completed before the nested variable is expanded. E.g:

IFDEF Do_Sort

Func: = sort

Else

Func: = Strip

ENDIF

Bar: = a d b g q c

Foo: = $ ($ (FUNC) $ (bar))

The value to the variable 'foo' is value to 'sort a d B g q c' or 'Strip A D B G q C', rather than the parameters of 'A D B G q C' as a function SORT or STRIP. If this restriction in the future is a good idea.

You can also use a nested variable reference to the left of the variable assignment, or in the Define instruction. Such as:

Dir = foo

$ (DIR) _Sources: = $ (Wildcard $ (DIR) / *. C)

Define $ (DIR) _Print

Lpr $ ($ (dir) _Sources)

Endef

This example defines the variable 'dir', 'foo_sources', and 'foo_print'.

Note: Although nested variables and recursive call extended variables are used in complex Makefile files, they are different (see Two features of variables).

6.4 variable value

The variables have the following ways to get their values:

l You can specify a reload value for the variable when running Make. Refer to the variable overload.

l You can specify a value in the makefile file, ie the variable assignment (see Setting Variable) or use the word-by-word definition variable (see Defining Multi-line variables).

l Change the environment variable to Make variable. See environment variables.

l Auto variables can provide values ​​according to rules, which are simple habitual usage, referred to automatic variables.

The L variable can be initialized with constant. See the variables used in implied rules.

6.5 Settings Variables

Set the variable in the makefile file, write the one line of '=' or ': =' after the variable name begins. Any content that follows '=' or ': =' is changed to the variable. E.g:

Objects = main.o foo.o bar.o utils.o

Define a variable called Objects, the space before and after the variable name and the space that keeps with '=' will be ignored.

The variable defined using '=' is a recursive call extension variable; the variable defined by ': =' is a simple extension variable. Simple extension variable definitions can include variable references, and variable references are expanded immediately while defining. See the variables.

The variable name can also contain variable references and function calls, which extends when the row is read, which can calculate the variable name capable of actually used. The length of the variable value is not limited, but is limited to the actual switching space in the computer. When defining a long variable, insert a backslash in a suitable place, divide the variable value into a plurality of text lines is a good choice. This does not affect the function of Make, but makes makefile files more easy to read.

Most variables If you do not set a value for it, the empty string will automatically use the initial value. Although some variables have built-in non-empty initial values, you can assign values ​​to them at any time (see the variables used by implicit rules.) Another variable can be automatically set up according to the rules, they are called Automatic variable. See Automatic variables.

If you prefer to assign a value for unsealed variables, you can use the speed diary '? =' Instead of '='. The following two sets of variables are completely equivalent (see Function Origin):

Foo? = Bar

with

IFEQ ($ (Origin foo), undefined)

FOO = BAR

ENDIF

6.6 Additional text for variable values

Additional text is generally useful for additional variables. You can use ' =' in your stand-alone to implement the above ideas. Such as:

Objects = another.o

This adds text 'annother.o' (there is a front guide felile in front of it) for the value of the variable Objects. such:

Objects = main.o foo.o bar.o utils.o

Objects = another.o

The variable Objects is set to 'main.o foo.o bar.o utils.o another.o'.

Use ` = 'the same as:

Objects = main.o foo.o bar.o utils.o

Objects: = $ (Objects) another.o

For use complex variables, the difference in different methods is very important. If the variable is not defined before, the ' =' 's and' = 'is the same: it defines a recursive call type variable. However, if there is a definition in previous, ' =' 'role relies on the characteristics of the original defined variable, and details the details of the variable.

When you use ' =' to add text for variable values, make the role of Make, as you contain the text you want to add when you initially define variables. If you start using ': =' Define a simple extension variable, then add text with ' =', the variable is expanded by the new text value, as if you will add text when you originally defined. As defined, please refer to the set variable. In fact,

Variable: = Value

Variable = more

Equivalent to:

Variable: = Value

Variable: = $ (Variable) More

On the other hand, when you use the ' =' and the recursive call type variable defined by the unsigned "= ', the MAKE is different. When you reference the recursive call type variable, Make does not immediately extend the value you set when the variable reference and function calls; but it is stored by word, and the variable references and function calls are also stored for future expansion. . When you use ' =' for a recursive call type variable, it is equivalent to adding new text to a non-extended text.

Variable = Value

Variable = more

Rough equation:

Temp = Value

Variable = $ (TEMP) more, of course, you never define a variable called TEMP. If you have the original defined variable, the variable is included in the variable reference, which can be more deeply reflected in the use of different ways defined Sex. Take a common example of it,

Cflags = $ (includes) -o

...

CFLAGS = -pg # enable profile

The first line defines the variable CFLAGS, and the variable CFLAGS references other variables, including incdude. (Variable CFLAGS is used for rules of the C compiler. See implied rules directory.) Since the '=' is defined, the variable CFLAGS is a recursive call type variable, meaning '$ (incrudes) -O' at the MAKE processing variable CFLAGS It is not extended when defined; that is, the variable INCLUDES does not have to be defined before it is entry, it only needs to be defined before any reference variable cflags. If we try not to use ' =' to add text for variable cflags, we may follow the way:

CFLAGS: = $ (cflags) -pg # enable profile

This seems to be very good, but the result is never what we hope. Use ': =' to redefine the variable cflags as simple extension variables, which means that Make extends '$ (cflags) -pg' before setting the variable CFLAGS. If the variable INCLUDES is not defined at this time, we will get '-0 -pg', and the definition of variable INCLUDES will not be valid later. Instead, use ' =' Set Variable CFLAGS We get no extended '$ (cflags) -0 -pg', which retains a reference to variable INCLUDES, in the back, if the variable INCLUDES is defined, '$ (cflags) 'Can still use it.

6.7 Override Directive

If a variable setting uses a command parameter (see Variable Overload), the usual value of the variable is not taken effect on the Makefile file. At this point, the variable is set, you need to use the Override directive, its format is as follows:

OVERRIDE VARIABLE = VALUE

or

OVERRIDE VARIABLE: = Value

Add more text to this variable, use:

Override variable = more text

See the text for variable values.

The OVERRIDE instruction is not intended to expand the conflict of makefile and command parameters, but to use it you can change and append the value of the variable of the command parameter when setting up.

For example, suppose you always use the '-G' switch when you run the C compiler, but you allow users to specify other switches like the command parameters like usually, you can use Override instructions:

OVERRIDE CFLAGS = -g

You can also use Override instructions in Define instructions. The following example may be you want:

Override define foo

Bar

Endef

Information about the Define instruction is reviewed.

6.8 Define Multi-Row Variables

Use the DEFINE directive when setting the variable value. This instruction has a special usage that can define a variable containing multi-line characters. This makes it easy to define the fixed order of the commands (see Defining Secure Order Commands).

Before the Define directive is generally a variable name, of course, there is no. The value of the variable is given by the following lines, and the end of the value is indicated by a row of only the endef. In addition to the above-mentioned syntax, the Define instructions work like '=': it creates a recursive call type variable (see two features of the variable). The name of the variable can include function calls and variable references, which are extended when the instruction is read, so that the actual variable name can be calculated. Define two-lines

Echo foo

Echo $ (BAR)

Endef

The value of the variable can only be completed in a row in the usual assignment statement, but all rows in the middle of the DEFINE instruction line after the Define instruction line are part of the variable value (except for the last line, because the line of the indicator endef cannot It is considered part of the variable value). The previous example is equivalent to:

Two-line = echo foo; echo $ (bar)

Because the two orders are separated by semicolons, their behavior is close to two separate shell commands. However, pay attention to the use of two separate rows, meaning that Make requests the shell twice, each row runs in a separate child shell. See the execution command.

If you want to define the variable definition of the define instruction, you can use the define instruction and the Override instruction by using the variable defined by the command line:

Override Define Two-Lines

foo

$ (bar)

Endef

See the Override instruction.

6.9 environment variables

Make uses variables from Make's operating environment. Any Make's environment variables can be seen when Make starts to run the MAKE variable of the same name. However, the specific assignment of variables in the makefile file, or uses a command with parameters, the environment variable can be overloaded (if the '-e' flag is explicitly used, the value of the environment variable can be performed on the assignment in the Makefile file. Overload, see the option summary, but this is not recommended in actual use.)

This way, by setting variable cflags in an environment, you can implement compilation of all C source programs in most Makefile files in most Makefile files. Because you know that there is no Makefile to use the variable for other tasks, this variable using standard simple meaning is safe (but this is also unreliable, some Makefile files may set the variable cflags, so that the value of the variable CFLAGS in the environment can be lost ). When using the recursive call, the variable defined in the outer MAKE environment can be passed to the inner layer (see Recursive Make). In the default mode, only environment variables or variables defined in the command line can be passed to the inner Make. You can pass the other variables using the Export instruction, see the variables communicated with the sub-make.

Other ways of use of environment variables are not recommended. The operation of Makefile completely relies entirely on the setting of environment variables, which exceeds the control range of the Makefile file, which is unwise, because different users run the same makefile file may have different results. This is contrary to most of the Makefile files.

The variable shell exists in the environment, used to specify the selection of the user's interacting shell, so use the variable shell to display a similar problem. This method of affecting the make run according to the selected value is very unwelcome. Therefore, Make will ignore the value of the variable shell in the environment (run an exception in MS-DOS and MS-Windows, but this time the variable shell usually does not set the value, see the execution command).

6.10 Value of specific target variables

The value of the variables in make is generally global; both, whether they are used anywhere, their value is the same (especially, except for you to reset); Automatic variables are an exception (see Automatic variable). Another exception is the value of a particular target variable, which allows you to change the definition of variables based on the change of the Make construction target. As with automatic variables, these values ​​can only work in the context of one target's command script.

You can set the value of a specific target variable like this:

Target ...: variable-associNMent

Or this:

Target ...: Override Variable-Assignment

The 'Target ...' can contain multiple objects, so that the value of the set specific target variables can be used in any of the target list. 'Variable-assignment' is valid using any assignment mode: recursive call type ('='), static (': ='), add (' =') or condition ('? ='). All variables in 'variable-assignment' can be used in the context of specific target Target ..., that is, the value of any particular target variable defined for a particular target Target ... is valid in these specific goals. of. Note that such variable values ​​and global variables are local values: these two types of variables do not have to have the same type (recursive call vs. static).

The value of a particular target variable and other MakeFile variables have the same priority. The value typically defined in the command line (and enforces the value of the environment variable in the case of '-e') occupies a priority, and the value of a particular target variable defined using the Override command is prejected.

The value of a particular target variable has another feature: When you define a specific target variable, the value of the variable is valid for all dependencies of specific target target ... unless these dependencies use their own specific target variables to this variable Overload. E.g:

PROG: cflags = -g

PROG: Prog.o foo.o bar.o

The value of the variable cflags is set to '-G' in the command script of the target prog, and the value of the variable cflags in the command script created by `prog.o ',` foo.o', and `bar.o 'is also' -g ', and prog.o', 'foo.o', and 'bar.o' dependent Create command script value is '-G'.

6.11 Value of specific format variables

In addition to the value of a specific target variable (see the upper section), the GNU Make also supports the value of a particular format variable. Using the value of a specific format variable, the variable can be defined for the target of the specified format. After defining a specific target variable for the target, the variables defined in a specific format will be searched, and the variables defined in a particular format are also available before the specific target variable defined for the parent destination of the target.

Set the specific format variable format as follows:

Pattern ...: variable-associNMent

Or this:

Pattern ...: Override Variable-Assignment

The 'Pattern' here is%-format. Like the value of a specific target variable, 'Pattern ...' can contain multiple formats, so, the value of the set specific format variable can be used in any of the formats in the match list. 'Variable-assignment' uses any assignment method to be valid, the value of the variable defined in the command line occupies a priority, and the value of a particular format variable defined using the Override command is prioritized. E.g:

% .o: cflags = -O

Search all the targets of all matching formats .o, and set it to '-0' to the value of its variable CFLAGS.

7 Makefile file conditional statement

A conditional statement can result in a part of the script in the Makefile file based on the value of the variable or ignore the Makefile file. The conditional statement can compare one variable with the value of other variables or compare a variable to a string constant. The conditional statement is used to control the Makefile file part that the Make actually see is not used to control the shell command at execution.

7.1 Example of conditional statement

An example of the conditional statement below tells Make If the value of the variable CC uses a database when 'GCC', if not, other databases are used. It works by controlling one of the two command lines as the rule. The result of 'cc = gcc' as the parameter changed by MAKE is not only used to determine which compiler is used, but also determine which database is connected.

Libs_for_gcc = -lgnu

NORMAL_LIBS =

Foo: $ (Objects)

IFEQ ($ (cc), GCC)

$ (Cc) -o foo $ (ibjects) $ (libs_for_gcc)

Else

$ (Cc) -o foo $ (bjects) $ (Normal_Libs)

ENDIF

This conditional statement uses three instructions: IFEQ, ELSE, and ENDIF.

The IFEQ instruction is the beginning of the conditional statement and specifies the condition. It contains two parameters that are separated by commas and is extended in parentheses. The two parameter variables are first replaced when running, and then compare. The lines followed by IFEQ in makefile are commands executed when they meet the conditions; otherwise they will be ignored.

If the previous condition fails, the ELSE instruction will result in the command followed by it. In the above example, it means that when the first option is not executed, the commands together with the second option will be executed. In the conditional statement, the ELSE instruction is optional.

ENDIF instruction end condition statement. Any conditional statement must end with the ENDIF instruction, followed by normal content in the Makefile file.

The above example indicates that the conditional statement works in the original level: the row of conditional statements is either part of the Makefile file based on the condition or ignored. This is a major grammatical unit (for example, rules) that makes the Makefile file (for example, rules) can span the start or end of the conditional statement.

When the value of the variable CC is GCC, the effect of the above example is:

Foo: $ (Objects)

$ (Cc) -o foo $ (ibjects) $ (libs_for_gcc)

When the value of the variable CC is not GCC but is other than other values, the above example is:

Foo: $ (Objects)

$ (Cc) -o foo $ (bjects) $ (Normal_Libs)

The same result can also be obtained using another method: the value of the variable is first, and then the variable is used:

Libs_for_gcc = -lgnu

NORMAL_LIBS =

IFEQ ($ (cc), GCC)

LIBS = $ (libs_for_gcc)

Else

LIBS = $ (Normal_Libs)

ENDIF

Foo: $ (Objects)

$ (Cc) -o foo $ (ibjects) $ (libs)

7.2 Syntax for conditional statement

The syntax for the conditional statement without the ELSE instruction is:

Conditional-Directive

TEXT-IF-TRUE

ENDIF

'Text-if-true' can be any text line, which is considered part of the makefile file when the condition is 'true'; if the condition is 'false', it will be ignored. The syntax of a complete conditional statement is:

Conditional-Directive

TEXT-IF-TRUE

Else

TEXT-IF-FALSE

ENDIF

If the condition is 'true', use 'text-if-true'; if the condition is 'false', use 'Text-if-false'. 'Text-if-false' can be any multi-row text. The syntax on 'Conditional-Directive' is exactly the same for simple conditional statements and complex conditions statements. There are four different instructions for testing different conditions. Here is the instruction table:

IFEQ (arg1, arg2)

Ifeq 'Arg1' 'Arg2'

IFEQ "arg1" "arg2"

IFEQ "Arg1" 'Arg2'

Ifeq 'arg1' "arg2"

All variables in Arg1, Arg2 are referenced, and they are compared. If they are exactly consistent, use 'text-if-true', otherwise use 'text-if-false' (if present). You often test if a variable has a non-null value, and the complex variable and function extension get a value, which is actually considered null value for you to consider space, which may cause confusion. . For this, you can use the strip function to avoid spaces as non-null disturbances. E.g:

IFEQ ($ (Strip $ (foo)),)

TEXT-IF-EMPTY

ENDIF

Even with spaces in $ (foo), 'text-if-empty' is also used.

IFNEQ (Arg1, Arg2)

IFNEQ 'Arg1' 'Arg2'

IFNEQ "Arg1" "Arg2"

IFNEQ "Arg1" 'Arg2'

IfNEQ 'Arg1' "Arg2"

All variables in Arg1, Arg2 are referenced, and they are compared. If they are different, use 'text-if-true', otherwise 'text-if-false' (if present).

IFDEF Variable-Name

If the variable 'variable-name' is a non-null value, 'Text-if-true' is valid, otherwise, 'text-if-false' is valid (if present). Variables are never defined, variables are null. Note that ifdef only tests whether the variable is worth it. It cannot be extended to see if there is a non-null value. Thus, all defined variables are returned to 'true', but those like 'foo =' are except. Test Null Value Please use IFEQ ($ (foo),). E.g:

Bar =

Foo = $ (bar)

IFDef foo

Frobozz = YES

Else

Frobozz = NO

ENDIF

Set the value of 'frobozz' 'yes', and ::

Foo =

IFDef foo

Frobozz = YES

Else

Frobozz = NO

ENDIF

Set 'frobozz' to 'NO'.

IFNDEF Variable-Name

If the variable 'variable-name' is a null value, 'text-if-true' is valid, otherwise, 'text-if-false' is valid (if present).

Excessive spaces are allowed in front of the command line, they are ignored during processing, but tabs are not allowed (if a row begins with Tab, the row will be considered a rule line). In addition, spaces and Tabs can insert anywhere in the row, except for the intermediates of the instruction name and parameters. Note starting with '#' can end at the end of the row. The other two affected instructions in the conditional statement are ELSE and ENDIF. These two instructions appear in the form of a word without any parameters. Excessive spaces, spaces, and Tabs can be inserted in front of the instruction line, and the annotations starting with '#' can end at the end of the row.

The conditional statement affects the makefile file used by Make. If the condition is 'true', Make reads the row containing 'text-if-true'; if the condition is 'false', make reads 'text-if-false' contains rows (if present); Makefile file Grammatical units, such as rules, can across the start or end of the conditional statement.

When reading the Makefile file, the value of the MAKE calculates the value of the condition. Thus, you cannot use automatic variables when testing conditions because they are defined when they are executed (see Auto Variables).

In order to avoid unbearable confusion, start a conditional statement in a Makefile file, and in another Makefile file is not allowed. However, if you try to introduce the included Makefile file uninterrup condition statement, you can write an Include instruction in the conditional statement.

7.3 Conditional statement of test logo

You can write a conditional statement using the variable Makeflags and the FindString function, with it to test the Make command flags such as '-T', etc. (see the string replacement and analysis function). This applies to occasions that only use the Touch flag that cannot completely change the file.

The FindString function checks if a string is a sub-string of another string. If you want to test the '-t' flag, use '-t' as the first string, make the value of the variable Makeflags as another string. For example, the following example is to arrange the update of using 'ranlib -t' to complete a file file:

Archive.a: ...

IFNEQ (, $ (Findstring T, $ (Makeflags)))

Touch Archive.a

ranlib -t archive.a

Else

Ranlib Archive.a

ENDIF

The prefix ' ' indicates that these command lines are recursive calls, even with the '-T' flags to be executed. See recurrencing Make.

8 text conversion function

The function allows you to handle text, calculate files, and use commands in your Makefile file. You must specify the function name and the parameters used by the function operation when the function is called. The result of the function processing will return to the call point in the Makefile file, which is the same as the variable replacement.

8.1 function call syntax

Function calls and variables are similar, its format is as follows:

$ (Function Arguments)

Or this:

$ {function arguments}

Here 'Function' is a function name, which is one of the Make built-in function list. Of course, you can also use your own functions created by creating a function CALL. 'Arguments' is the parameter of this function. The parameters and function names are spaced from spaces or TAB, if there are multiple parameters, they are separated from commas between them. These spaces and commas are not part of the parameter value. The delimiter that encloses the function call, regardless of the parentheses or braces, can be paired in the parameter, and there can be only one delimiter in a function call. If you contain variable references or other function calls in the parameter, it is best to use the same delimiter, such as writing as '$ (Subst A, B, $ (x))', not `$ (Subst A, B, $ {x}) '. This is because this method is not only more clear, but also in a function call can only have a set of delimitizes. For each parameter written by variable replacement or function call processing, the value of the parameter is finally obtained, which is the function that the function must rely on. In addition, the variable replacement is processed in the order in which the variable appears in the parameter.

The comma and inconvenient parentheses, braces cannot appear as text in parameters, and the front guidance can not appear in the first parameter. These characters cannot be handled by variables to the value of parameters. If you need to use these characters, first define variables COMMA and SPACE, their value is a separate comma and space character, and then use them because of them, as in the following example:

COMMA: =,

EMPTY: =

Space: = $ (EMPTY) $ (EMPTY)

Foo: = a b c

Bar: = $ (Subst $ (SPACE), $ (Comma), $ (Foo))

# BAR is now `a, b, c '.

The function of the function Subst here is to replace the space in the fooo, and then return the result.

8.2 String Replacement and Analysis Functions

Here are some functions for operating strings:

$ (Subst from, To, Text)

Use 'to' to replace each 'from' in text 'Text'. E.g:

$ (Subst Ee, Ee, Feet on The Street)

The result is 'feed on the street'.

$ (PatSubst Pattern, Replacement, Text)

Look for 'text' in compliance with the format 'Pattern', replace them with 'replacement'. Here 'Pattern' contains wildcard '%', which matches any number of characters in one word. If the 'replacement' also contains wildcard '%', this '%' is replaced with the text that matches the 'Pattern' CNC '%'. The '%' in the function PATSUBST can be referenced by a backslash ('/'). The backslash of the reference characters '%' can be referenced by more backslash. Reference characters '%' and other backslashes are removed from the format before the comparison file name or a STEM (path) instead of it. Use a backslash reference character '%' will not bring other troubles. For example, format 'the /% weird //% pattern //' is 'the% weird /' plus wildcard '%' and then connects to string 'pattern //'. The last two backslash must remain unchanged because it cannot affect any of the stroke '%'. The space between the words is compressed as a single space, the front guide, and the endless space is discarded. E.g:

$ (PATSUBST% .c,%. O, X.c.c bar.c)

The result is: 'x.c.o bar.o'. Replacement reference is a simple method for implementing function PATSUBST features:

$ (var: pattern = replacement)

Equivalent to :

$ (Patsubst Pattern, Replacement, $ (VAR))

Another simple way to use the function PATSUBST is: replacing the suffix of the file name.

$ (var: suffix = replacement) equivalent:

$ (Patsubst% SUFFIX,% Replacement, $ (var))

For example, you may have a list of OBJ files:

Objects = foo.o bar.o baz.o

To get the source file of these files, you can simply write as:

$ (Objects: .o = .c)

Instead of specification format:

$ (PatSubst% .o,%. C, $ (Objects))

$ (Strip String)

Remove the leading and end spaces and compress the middle spaces into individual spaces. Thus, '$ (Strip A B C)' results are 'a b c'. Functions Strip and conditional statements are useful. When using IFEQ or IFNEQ compares some values ​​and empty strings '', you typically want to consider a string consisting only of space by spaces (see the condition statement in the Makefile). The following example may fail when implementing the expected results:

.Phony: All

IFNEQ "$ (needs_made)" ""

All: $ (Needs_made)

Else

All:; @ echo 'Nothing to make!'

ENDIF

Call '$ (Strip $ (NEEDS_MADE))' instead of the variable reference '$ (NEEDS_MADE)' will no longer occur.

$ (Findstring Find, IN)

Search 'find' in string 'in', if you find it, the return value is 'Find', otherwise the return value is empty. You can use this function to test whether the given string contains a specific sub-string in a given string. In this way, the following two examples:

$ (Findstring A, A B C)

$ (Findstring A, B C)

Values ​​'A' and '' are generated separately. See the conditional statement of the test mark for a specific usage of functions FindString.

$ (Filter Pattern ..., Text)

Returns the word that is separated by spaces in 'text' and matches the format 'Pattern ...', for the word that does not match the format 'Pattern ...'. The format is written with '%' and the format of the function PATSUBST discussed above. Function FILTER can be used to variable separation types of strings. E.g:

Sourcees: = foo.c bar.c baz.s ugh.h

Foo: $ (SOURCES)

CC $ (Filter% .C%. S, $ (Sources)) -O Foo

Indicates 'foo' relying on 'foo.c', 'bar.c', 'baz.s' and 'ugh.h'; but only 'foo.c', 'bar.c' and 'baz.s' Compile with commands.

$ (Filter-Out Pattern ..., Text)

Returns the word that is separated from the space in 'text' and does not match the format 'Pattern ...', and the word extension that matches the format 'Pattern ...'. It is just the reverse function of the function filter. E.g:

Objects = main1.o foo.o main2.o bar.o

MAINS = main1.o main2.o

The following is a list of files that are not included in the variable 'mains':

$ (Filter-Out $ (MAINS), $ (Objects))

$ (Sort List)

Sort the words in 'List' in alphabetical order and remove the repeated words. The output is a list of words separated by a single space.

$ (Sort Foo Bar Lose)

The return value is 'bar foo lose'. By the way, since the function SORT can remove the repeated word, you are not careful to sort this feature.

Here is an example of actual use of Subst and PatSubst. Suppose a Makefile file uses the variable vPath to specify a series of paths for the Make search dependencies (see vPath: dependent on the search path). This example shows how to tell the C compiler to search for head files in the same path list.

The value of the variable vPath is a zip name that is separated by colon, such as 'src: ../ Headers'. First, the function SUBST changes the colon into spaces:

$ (Subst :,, $ (VPATH))

This generates value 'src ../headers'. Then, the function PATSUBST adds to the '- |' flag for each path name, so that these paths can be added to the CFLAGS, they can be automatically passed to the C compiler:

Override cflags = $ (PatSubst%, - I%, $ (Subst:,, $ (vPath)))

The result is the case after the previously given variable CFLAGS, adding text '-isrc -i ../ Headers'. The role of the OVERRIDE instruction is to function even if the value of the command parameter is used to specify the value of the variable CFLAGS. See the Override instruction.

8.3 file name function

Several built-in extended functions and split file names are associated with the listing file name. The functions listed below can perform specific conversions for the file name. The parameters of the function are a series of file names, and the file name is separated by spaces (the leader and the end of the space are ignored). Each file name in the list is converted in the same way, and the results are connected in series with a single space.

$ (Dir Names ...)

Patting the path portion of each file name in 'Names', the path portion of the file name includes all characters before the start of the beginning of the file name to the last slash (including the kerquee). If there is no slash in the file name, the path portion is './'. Such as:

$ (Dir src / Foo.c Hacks)

The result is the result of 'src / ./'.

$ (Notdir Names ...)

Extract each file name in 'Names' except the path portion (the real file name). If there is no slash in the file name, the file name remains unchanged, otherwise the path portion is removed. A file name will become an empty string if only the path portion contains only the path portion (the file name ends with the slash). This is very unfortunate, because this means that if there is such a file name in the result, the space between the two file names will not be separated by the same number of spaces. But now we can't see any other effective substitute. E.g:

$ (Notdir Src / Foo.c Hacks)

The result produced is 'foo.c Hacks'.

$ (SUFFIX NAMES ...)

Extract the suffix of each file name in 'Names'. If the file name is in the file name (or a slash, and after the last slash) contains a period, then the suffix is ​​all the characters after the last period, otherwise, the suffix is ​​an empty string. If the result is empty, the 'names' has no suffix file name. If the file contains multiple filenames, the number of recipings listed is likely to be less than the number of original file names. E.g:

$ (SUFFIX SRC / FOO.C SRC-1.0 / bar.c Hacks)

The result is '.c .c'.

$ (BaseName Names ...)

Extract each file name in 'Names' in addition to the sep. If the file name (or a slash, and after the last slash) contains a period, the basic name is all characters from the beginning to the last period (not included). If there is no period, the basic name is the entire file name. E.g:

$ (BaseName Src / Foo.c SRC-1.0 / Bar Hacks)

The result is the 'SRC / FOO SRC-1.0 / bar Hacks'.

$ (Addsuffix Suffix, Names ...) Parameters 'Names' As a series of file names, the file name is separated by spaces; Suffix is ​​used as a unit. Adding the value of the suffix (suffix) at the back of each independent file name, connect the file name in series after completion, which is separated from a single space. E.g:

$ (Addsuffix .c, Foo Bar)

The result is 'foo.c bar.c'.

$ (AddPrefix Prefix, Names ...)

The parameter 'names' uses spaces between file names in a series of file names; Prefix is ​​used as a unit. Attach the value of the Preffix (prefix) in front of each of the separate file names, connect the file name in series, which is separated from a single space. E.g:

$ (AddPrefix SRC /, FOO BAR)

The result is 'SRC / FOO SRC / BAR'.

$ (Join List1, List2)

The two parameters are connected in series: the first word of the two parameters is connected to the first word of the result, and the second word of the two parameters is connected to the second word of the result, and so on. If a parameter is more than the one of the other parameters, the excess letter is unstopped to the result. For example, '$ (Join A B, .c .o)' generates 'a.c B.O'. The extra spaces between words are no longer retained, and they are replaced by a single space. This function combines the results DIR, NOTDIR to generate the originally given file list.

$ (Word N, Text)

Returns the nth word in 'Text'. The legal value of n starts with 1. If the N is larger than the number of words in 'Text', the null value is returned. E.g:

$ (Word 2, Foo Bar Baz)

Return 'Bar'.

$ (WordList S, E, Text)

Returns a word from the first word from the first word to the Ethlier in 'Text'. The legal value of S and E starts with 1. If the S is large, return null values; if the e-than the number of words in 'Text', return all words from the beginning to 'Text'; if S No value is not returned. E.g:

$ (WordList 2, 3, Foo Bar Baz)

Return `Bar Baz '.

$ (Words text)

Returns the number of characters in 'Text'. The last word in the 'Text' is '$ (Word $ (Words Text), Text)'.

$ (Firstword Names ...)

The parameter 'Names' is used as a series of file names, and the file name is separated by spaces; returns the first file name, the rest ignore. E.g:

$ (FIRSTWORD FOO BAR)

Produce results 'foo'. Although $ (FirstWord Text) and $ (Word 1, Text) have the same effect, the first function is retained because it is simple.

$ (Wildcard Pattern)

Parameter 'Pattern' is a file name format, typically containing wildcards (same as those in the SHEL). The result of the function Wildcard is a column and format matching and file names, and the file name is separated from a space, see Using wildcards in the file name.

8.4 Function Foreach

The function foreach and other functions are very different, which causes a text block to reuse, and each time you use this text block for different replacement; it is similar to the command for command in the shell SH, and the command foreach in the C-shell CSH.

The FOREACH syntax is as follows:

$ (Foreach Var, List, Text)

The first two parameters, 'var' and 'list' will first extends, note that the last parameter 'text' does not expand this at this time; then, the word generated for each 'list' extension will be used for 'var' expansion The rear named variable assignment; then 'text' references the variable extension; therefore it is different. The result is a new 'List' that is multi-expanded in 'Text' in 'List' in Space Spaces. 'Text' Multiple extensions are connected, and the words and words are spaced from spaces, so that the return value of the FOREACH is generated.

This is a simple example that sets the value of the variable 'files' to all files in all directories in DIRS':

DIRS: = a b C d

Files: = $ (Foreach Dir, $ (DIRS), $ (Wildcard $ (DIR) / *))

Here 'text' is '$ (Wildcard $ (DIR) / *)'. The first value found for the variable DIR is 'a', so the first word of the function FOREACH result is '$ (Wildcard A / *)'; the second repetition value is 'b', so the function is generated. The result of the second word is '$ (Wildcard B / *)'; the third repeated value is 'c', so the third word of the function foreach result is '$ (Wildcard C / *)'; etc. Wait. This example and the following example have a common result:

FILES: = $ (Wildcard A / * B / * C / * D / *)

If 'Text' is more complicated, you can use additional variables to name it, which can improve the readability of the program:

Find_files = $ (Wildcard $ (DIR) / *)

DIRS: = a b C d

Files: = $ (Foreach Dir, $ (DIRS), $ (Find_Files))

Here we use variables Find_File. When we define the variable find_file, use '=', so the variable is a recursive call type variable, so that the variable find_file The function call will be extended under the FOREACH control; for simple extension variables, not this, in the variable find_file Call the function wildcard when defined.

FOREACH has no long-term impact on variable 'var', and its value and variable feature will be the same as before the function foreach call, the value obtained from 'List' only works only when the function foreach is executed, and they are temporary . Variable 'Var' is a simple extension variable during function Foreach, and if the variable 'var' is not defined before the function foreach is not defined, the function foreach is not defined. See the two features of the variable.

When using complex variable expressions to generate variable names, be careful, because many strange characters are valid as variable names, but it is likely not what you need, for example:

Files: = $ (Foreach Esta Escrito EN ESPANOL!, B C CH, $ (Find_Files))

If the variable find_file extension reference is the 'Esta Escrito En Espanol!' Variable, the above example is valid, but it is easy to bring an error.

8.5 functions IF

Function IF provides support for extended conditions in the function context (compared to conditional statements in the GNU Make Makefile file, such as the IFEQ instruction, see the syntax of the conditional statement).

A function IF call, can contain two or three parameters:

$ (if Condition, Then-Part [, Else-Part])

The first parameter 'condition', first remove the front guide, end space, and then expand. If the extension is a non-empty string, the condition 'condition' is 'true'; if the extension is an empty string, the condition 'condition' is 'false'. If the condition 'condition' is 'true', the value of the second parameter 'TEN-Part' is calculated and the value is used as the value of the entire function IF.

If the condition 'condition' is 'false', if there is a third parameter, the value of the third parameter 'else-part' is calculated, and the value is used as the value of the entire function IF; if the third parameter does not exist, The function IF does not calculate anything, returns null value.

Note that only one of 'Then-Part' and 'Else-Part' can only be calculated, and cannot be calculated at the same time. This is likely to generate side effects (eg, a function shell call).

8.6 function CALL

Function Call is the only creation of a new function with parameter functions. You can write a complex expression as a value of a variable, then use the function call to call it with a different parameter.

The syntax of the function Call is:

$ (Call Variable, Param, Param, ...)

When Make expands the function, it assigns each parameter 'param' to the temporary variable $ (1), $ (2), etc .; the value of the variable $ (0) is the variable 'variable'. There is no maximum number of limitations for the number of parameter 'param', and there is no minimum limit, but if the function Call is used without any parameters, its meaning is not large.

Variable 'variable' is extended to a MAKE variable in the context of these temporary variables, so that the reference value '$ (1)' in the variable 'variable' determines the first parameter 'param' when the call function CALL is called. usage of.

Note that the variable 'variable' is a variable name, not a reference to the variable, so you cannot write this variable in the format of '$' and parentheses, of course, if you need a very quite file name, you can Use variable references in the file name.

If the variable name is an internal function name, the built-in function will be called (even if the MAKE variable using this name already exists). Function CALL pre-extension parameters before assigning the temporary variable, which means that the variable 'variable' uses special rules to expand, icon funach or IF, and their extension results and the results you expect may be different. . Some of the following examples can be clearer to express this.

When the example is used to flip the order of the parameters:

REVERSE = $ (2) $ (1)

Foo = $ (Call Reverse, A, B)

The value of the variable foo here is 'b a'.

Here is a very interesting example: it defines a macro that uses this macro to search for the first specified type of program in all directories contained in PATH:

PathSearch = $ (FirstWord $ (Wildcard $ (Addsufix / $ (1), $ (Subst:,, $ (PATH)))))))))

Ls: = $ (Call PathSearch, LS)

The value of the variable LS is now '/ bin / ls' or other similar values.

Nesting can be used in the function Call. Each recursive call can be assigned to its own local variable '$ (1)', so that instead of the value assigned to the last layer function Call. For example: This implements the image function function.

Map = $ (Foreach A, $ (2), $ (CALL $ (1), $ (a))))))))

Now you can image only a function of a parameter, such as a function Origin, get multiple values ​​in one step:

o = $ (Call Map, Origin, O Map Make)

The last variable O contains a value such as 'file file default'. Warning: Use spaces in the parameters of the function Call must be very careful. Because in other functions, the space in the second or next parameter is not deleted, which may result in a very strange result. When you use a function call, any extra space in the parameter is the safest way.

8.7 Function Origin

Function Origin does not want a general function, it does not operate any variable; it only tells you some information about a variable; it specifically tells you the source of variables.

Function Origin's grammar:

$ (Origin Variable)

Note that the variable 'variable' is a name of a query variable, not a reference to the variable, so you cannot use the format of '$' and parentheses, of course, if you need a very quite file name, you can Use variable references in the file name.

The result of the function Origin is a string that is defined by the string variable:

'Undefined'

If the variable 'variable' is never defined.

'Default'

Variable 'variable' is the default definition, usually used with command CC, etc., see the variables used in implicit rules. Note If you redefine a default variable, the function Origin will return to the rear definition.

'Environment'

Variable 'variable' as an environment variable definition, option '-e' is not open (see Options Overview).

'Environment Override'

Variable 'variable' is defined as an environment variable, the option '-e' is turned on (see Options).

'File'

Variable 'variable' is defined in Makefile.

'Command Line'

Variable 'variable' is defined in the command line.

'OVERRIDE'

Variable 'Variable' is defined in the Makefile (see Override instruction) in makefile.

'Automatic'

Variable 'variable' is an automatic variable that defines that it is to execute commands in each rule (see Auto Variables).

The basic use of this information (other uses is to satisfy your curiosity) is the basis for making you need to understand the variable value. For example, suppose you have a Makefile file called 'foo', which contains another Makefile file named 'bar', if you have defined variables' Bletch 'in the environment variable, you want to run command' make -f bar 'Re-define the variable' Bletch 'in the Makefile file' bar '. But makefile file 'foo' has defined variable 'Bletch' before including Makefile file 'bar', and you don't want to use Override command definition, then you can use Override instructions in makefile file 'foo', because the Override instruction will Overloads the definition in any command line, the priority it defines beyond the definition of the Makefile file 'bar'. So the Makefile file 'bar' can include:

IFDEF BLETCH

Ifeq "$ (Origin Bletch)" Environment "

Bletch = BARF, GAG, ETC.

ENDIF

ENDIF

If the variable 'Bletch' is defined in the environment, it will redefine it here.

Even in the case of using Option '-e', you have to define the variable 'Bletch' over the environment, you can use the following:

IFNEQ "$ (ORIGING BLETCH)" "" "Bletch = BARF, GAG, ETC.

ENDIF

If '$ (Origin Bletch) returns' Environment' or 'Environment Override', the variable 'Bletch' is redefined here. See string replacement and analysis functions.

8.8 function shell

In addition to the function wildcard, the function shell and other functions are different, which is the communication tool for Make and the external environment. Function shell and function execution in most shells ('): It is used for an extension of the command. This means that it plays a role of calling the shell command and returns the parameters of the command output. Make only processes the return result, before returning the result replacement call, make each of the newline characters or a pair of carriage returns to a single space; if the return result is finally a newline (and the carriage return), MAKE will put They remove. When the command called by the function shell, once the function call is expanded, it is executed immediately. In most cases, the command that the function shell call is called when the Makefile file is read. The exception is called in the rule command line, because in this case only the function of the command running can be extended, the other call function shell is similar.

Here are some examples of using functions shell:

Contents: = $ (Shell Cat Foo)

Set the value of the file foo to the variable contents, which is separated by spaces (rather than a newline).

Files: = $ (shell echo * .c)

Set the extension of '* .c' to the value of the variable Files. This statement is the same as the result of 'Wildcard * .c' unless Make uses a very weird shell.

8.9 Control Make function

These functions control the mode of operation of Make. Normally, they are used to provide users with information on the Makefile file or interrupt Make operation when detecting some types of environment errors.

$ (Error Text ...)

Usually 'Text' is a fatal error message. Note that the error is generated when the function is calculated, so if you put the function in the script of the command or the right side of the recursive call type variable, it cannot be calculated until expired. 'Text' will extend before the error, for example:

IFDef Error1

$ (Error Error IS $ (Error1))

ENDIF

If the variable error01 has defined, a fatal error is generated when the Makefile file is read. or,

Err = $ (Error Found An Error!)

.Phony: ERR

Err:; $ (ERR)

If the ERR target is called, a fatal error is generated at the MAKE.

$ (WARNING TEX ...)

This function is similar to the way the function error works, but Make does not quit, that is, although 'text' extends and displays the result information, Make continues to execute. The result of extending this function is an empty string.

9 Run Make

The Makefile files that describe the compiler can be implemented in a variety of ways. The easiest way is to compile all expiration files, for the usual Makefile file, if you do not run Make without any parameters, then do this.

But you may only update some files; you may need to use different compilers or different compilation options; you may just want to find out the time of time without updating them. These can only be implemented by giving parameters when running Make. There are three cases of exiting the MAKE state:

0

Indicates that Make has successfully completed exit.

2

The exit status is 2 indicates that the MAKE is running an error, which will print the information describe the error. 1

Exit Status 1 indicates that the '-q' flag is used when you run Make, and make determines that some files are not updated. See instead of executing commands.

9.1 Specify the parameters of the Makefile file

The method specifies that the Makefile file name is to use the '-f' or '--file' option ('--makefile' can also work). For example, '- f altmake' illustrates files named 'altmake' as a Makefile file.

If you use the '-f' flag several times, and each '-f' has parameters, all specified files will be together as a makefile file.

If you don't use the '-f' or '-file' option, the default is to look for 'gnumakefile', 'makefile', and 'makefile', using the first one of the firsts that can be found or Files that can be created, see Write the Makefile file.

9.2 Specify the parameters of the final goal

The ultimate goal (GAOL) is the goal of Make finally worked. Other updated goals are because they serve as the dependence of the ultimate goal, or the dependence, and so on.

By default, the first goal in the makefile file is the ultimate goal (do not calculate those targets starting at the beginning). Therefore, the first compilation target of the Makefile file is to describe the entire program or program group. If the first rule has several goals, only the first goal of this rule is the default ultimate goal.

You can specify the final goal using the parameters of Make. The method is to use the name of the target as a parameter. If you specify a few final goals, make a one after the order in the order you named.

Any goals that appear in the makefile file can be parsed as a switch as a final goal (except for the start of '-' "= ', they are parsing to the switch, the other is a variable definition). Even if there is no target in the makefile file, how to generate it according to the implicit rule, or may be specified as the ultimate goal.

Make will set the final goal you specify using special variables Makecmgoals in the command line. If the final goal is not specified at the command line, the value of the variable is null. Note that the variable value can be used in special occasions.

A suitable example is to avoid deleting files including '.d' (see automatically dependent) in the clear rules (see Automatically generate it), and immediately delete them immediately:

Sources = foo.c bar.c

IFNEQ ($ (Makecmdgoals), Clean

INCLUDE $ (Sources: .c = .d)

ENDIF

One purpose specifying the ultimate goal is to only compile a few programs in the program group. If so, you can specify the file you want to mutated as the ultimate goal. For example, in a path containing several programs, a Makefile file begins:

.Phony: All

All: Size NM LD AR AS

If you only compile the program size, you can use the 'make size' command so that only the program you specify is recompiled.

Another use specifying the final goal is to compile which there is no normal file. For example, another file requires debugging, or a version program requires compiling, but the file is not dependent on the final goal of the Makefile file rule. At this time, you can specify them using the final target parameter.

Another use of the specified ultimate goal is to run and contact a hypothetical target (see the imaginary target) or an empty target (using an empty target recording event). Many makefile files contain a false destination 'clean' delete all files other than the original file. Under normal circumstances, only you specifically specifically indicate using the 'make clean' command, Make can perform the above tasks. The name of the typical hypothetical goals and empty targets are listed below. Refer to the user standard target for all standard target names used by the GNU Make package: 'all'

Create all top-level targets for your Makefile file.

`clean

Delete files created normally in Make.

`MostlyClean '

Imagine the fake object 'Clean', but avoid deleting a small number of files that do not re-build under normal circumstances. For example, target 'Mostlyclean' is not deleted with 'libgcc.a' because it is very rare, and it takes a lot of time to reconstruct it.

`distclean '

`Realclean '

`Clobber '

These objects may define more files than target 'clean'. For example, delete a configuration file or prepare a normal creation, or even the Makefile file itself cannot create a file.

'INSTALL'

Copy the executable file in the command to the command; look for the auxiliary file used by the executable to perform the executable file.

'Print'

Print a list of files that changes.

'Tar'

Create a compressed 'Tar' file of the source file.

'Shar'

Create a SHELL file file for the source file.

'Dist'

Create a release file for the source file. This may be 'Tar' file, 'Shar' file, or multiple of the above-described compressed version files.

'Tags'

Update the 'tags' tag of the program.

`check '

`test '

The program created by the makefile file performs self-test.

9.3 instead of execution command

The Makefile file tells make how to identify if a goal needs to be updated and how to update each goal. But update goals are not you need, some specific options can be used to specify other activities of Make:

`-n '

`--just-print '

`- DRY-Run '

`--Recon '

'NO-OP'. Make's activity is to print the commands used to create the target, but do not perform them.

`-t '

`- touch '

'Touch'. This activity is to do update markers, but do not change them. In other words, Make pretend to be compiled, but actually does not change it.

`-q '

`--question '

'Question'. This activity is secretly viewing whether the target has been updated; however, the command is not executed. In other words, it is not yet to be compiled.

`-W file '

`--What-if = file '

`--ssume-new = file '

`--new-file = file '

'What if'. Each '-w' flag is followed by a file name. The change time of all file names is recorded as the current time, but it is actually changeable. If you want to update the file, you can use the '-w' flag and '-n' flag to use to see what will happen.

Use the flag '-n', Make prints the commands that are properly executed, but do not perform them.

Use the logo '-t', make ignore the commands in the rules, and use the 'touch' command for those that need to be updated. If you do not use '-s' or .silent, 'Touch' command is also printed. In order to improve the execution efficiency, Make does not actually call the program Touch, but the Touch is run directly. Use the logo '-Q', Make does not print the output does not execute the command, if all the goals have been updated to the latest, make exit status is 0; if a part need to update, exit status is 1; if Make encounters errors, exit status Is 2, so you can look for errors based on no updated goals.

If you run Make, if you are more than two or three, you will generate an error. Signs' -n ',' - t 'and' -s' do not work for those command lines starting with character ' ' and contain string '$ (opportune) commands. Note that these options are not noticed when these command lines starting with character ' ' and contain strings '$ (opportunities)' or '$ {make}' command lines do not pay attention to these options. Refer to the Make Make Make.

The '-w' logo has two features:

l If you use the flag '-n' or '-q' at the same time, if you change a part of the file, see what make will do.

l Do not use flag '-n' or '-q', if the Make is running, Make preserves all files that have been updated, but do not change any files.

Note Options '-p' and '-V' Allows you to get more Make information or information on the Makefile file being used (see Options).

9.4 Avoid recompiling files

Sometimes you may change a source file, but you don't want to compile all files that rely on it. For example, suppose you add a macro or a statement that you rely on a number of files that rely on a lot, follow the conservative rules, Make thinks any changes to the header file, you need to compile all the files that rely on it, but you know that is Unnecessary, and you don't wait for them to completely compile.

If you understand the problem before changing the header file in advance, you can use the '-t' option. This flag tells Make not running commands in the rules, but changes all target timestamp to the latest. You can implement the above plan as follows:

1. Recyclade the source files that need to be compiled by the make command;

2, change the header file;

3, use the 'make -t' command to change the timestamp of all target files, which will not compile any files because of the change of the header file next time.

If you have changed the header file before recompilating the source files that need to be compiled, it is too late to do it in the above steps; as a remedy, you can use the '-o file' flag, it can use the specified file time The poke is changed to the previous timestamp (see the option summary). This means that the file has not changed, so you can do it as follows:

1. Use the 'make -o file' command to recompilate the files that need to be updated because of changing the header file. If you involve a few header files, you can specify each header file using the '-o' flag.

2. Use the 'make -t' command to change the timestamp of all target files.

9.5 variable overload

Use the variable defined by '=': 'v = x' set the value of the variable V to x. If you define a variable with this method, any normal assignment of the variable will be ignored by Make, to make them overload them in the command line.

The most common way is to use the delivery of additional markers to the compiler flexibility. For example, in a Makefile file, the variable CFLAGS already contains each command running the C compiler, so if only the command MAKE is typed, the file 'foo.c' will compile the following manner (cflags) ) foo.c

This way you can take effect on any options that affect the compiler in the Makefile file, but you can overload the variable, for example, if you say 'make cflags =' - g - O '', any C compiler will use the 'cc -c -g -o' compiler. This also illustrates how to use the reference in the shell command including the value of the variables in the shell command in the overload variable.

Variables CFalags are merely one of many standard variables you can use in this way, and these standard variables are fully listed in the variable used by hidden rules.

You can also write Makefile to see your own additional variables so that users can control other faces at Make runtime by changing these variables.

When you use the command parameter overload variable, you can define recursive call extensions or simple extension variables. As defined in the above example, recursive call extension variables, if you define a simple extension variable, use ': =' instead '='. Note that the two variables do not differ unless you use variable references or function calls in variables.

With this way, you can change the variables you overloaded in the Makfile file. The overloaded variables in the Makfile file is the command line similar to the 'Override Variable = Value'. See the Override instruction in details.

9.6 Test Compiler

Under normal circumstances, once there is an error while executing the shell command, make immediately exits returns a non-zero status; does not continue to run commands for any target. Error indicates that Make does not create the final goal correctly, and immediately reports an error in an error.

This is not what you want when you compile the program you modified. You want Make to try to compile each program and display each error as much as possible.

In this case, you can use the '-k' or '--keep-going' option. This option tells Make to continue to find the goal dependence before the error returns a non-zero state, if necessary, recreate them. For example, the error is found when compiling a target file, even if Make already knows that it is impossible, 'make -k' will continue to compile other object files. In addition to running after the shell command fails, even after Make does not know how to create the goals and dependencies, 'make -k' will continue to run as much as possible. These errors will be fatal when there is no '-k' option (see Options).

Under normal circumstances, make behavior is based on assumption that your goal is to update the final target; once it finds that it is impossible, it is immediately reported immediately. Option '-K' says the real goal is to test changes to the impact of the program and find the existing problem so that you can correct them before running. This is the reason why the Emacs m-x compile command defaults to the '-k' option.

9.7 Overview

Here is the list of options that make it understandable:

`-b '

`-m '

These options are ignored when compatible with other version Make.

`-C Dir '

`- Directory = DIR '

Switch the path to 'DIR' before reading the makefile. If you specify multiple '-C' options, each is interpreted relative to the previous one: '- c / -c etc' is equivalent to '-C / etc. This option is typically used in recursive call Make, see recursive calling Make. '-D'

Print debug information after normal processing. Debugging Information Description Which files are used for updates, which file is used as a standard for timestamp and the result of comparison, which file actually needs to be updated, need to consider, which implies rules, etc. Best. '-D' option is equivalent to '--debug = a' option (see below).

`- Debug [= Options] '

Print debug information after normal processing. You can choose the output of various levels and types. If there is no parameters, print the 'basic' level debugging information. The following is a possible parameter, just consider the first letter, and the comma or spaces are separated between each value:

A (all)

Display all debugging information, this option is equivalent to the '-d' option.

B (Basic)

Basic debugging information Prints every outdated goal, and their rebuild is successful.

v (verbose)

Commissioning information compared to 'basic' high one level. Including the syntax analysis result of the makefile file, there is no need to update dependence, etc. This option also contains basic debugging information.

IMPlicit

Print information about search targets for implicit rules. This option also contains basic debugging information.

J (JOBS)

Print the details of each subcommand call.

M (Makefile)

The above option does not contain information that recreate the makefile file. This option contains information on this. Note that option 'all' does not contain this information. This option also contains basic debugging information.

`-e '

`--environment-overrides'

Set the priority of variables inherited from the environment than priority to variables in the Makefile file. See environment variables.

`-f file '

`--file = file '

`--Makefile = file '

Set the file named 'file' to the Makefile file. See writing a makefile file.

`-h '

`--help '

Remind you to the option that make understands and exits.

`-i '

`--ignore-errors'

Ignore all errors generated when the rebuild file executes commands.

`-I dir '

`--include-dir = dir '

Specifies the path 'DIR' that contains the Makefile file. See containing other makefile files. If you use a few '-i' options at the same time, you can search for these paths in the specified order.

`-j [jobs] '

`--jobs [= jobs] '

Specifies the number of commands that perform simultaneously. If there is no parameter make will perform as many tasks as possible; if there are multiple '-j' options, only the last option is valid. Details See parallel. Note Under MS-DOS, this option is ignored.

`-k '

`--keep-going '

After the error occurs, continue as much as possible. When a target creation fails, all target files that rely on it will not be rebuilt, and other dependencies of these goals can continue to process. See Test Compiler.

`-l [load] '

`--Load-average [= loading] '

`--max-load [= loading] '

Specify if there is any other task being running, and the average load is close or more than 'load' (a floating point number), the new task is not launched. If there is no parameters, the previous limit on the load is canceled. See parallel. `-n '

`--just-print '

`- DRY-Run '

`--Recon '

Print the command to be executed, but do not perform them. See instead of executing commands.

`-o file '

`--OLD-file = file '

`--ssume-il = file '

Even if the file file is better than its dependence, it does not rebuild the file. Don't rebuild any other files because of the change of file file. This option is essentially a timestamp that pretend to turn the file to an old timestamp, so that it is ignored by its rules. See avoiding recompiling files.

`-p '

`--Print-data-base '

Print the database (the value of the rules and variables), which are from the result of reading the Makefile file; then execute or follow other specified options as usual. If you give a '-V' switch, you print version information (see below). Use 'make -qp' to print the database after you try to rebuild any files. Print the database of predefined rules and variables using 'make -p -f / dev / null. The database output contains the file name, and the line number information defined by the command and variable. It is a good debugging tool in a complicated environment.

`-q '

`--question '

'Problem mode'. Do not execute the command, if all goals have been updated to the latest, make exit status is 0; if a part needs to update, the exit status is 1; if Make encounters an error, the exit status is 2, see instead of execution command.

`-r '

`--NO-Builtin-Rules'

Exclude using built-in implicit rules (see Using Implied Rules). You can still define your own format rules (see definition and redefine format rules). Option '-r' also clears the default suffix list and suffix rules (see Outdown suffix rules). But you can use the .Suffixes rules to define your own suffix. Note that using option '-r' simply affects rules; default variables are still valid (see the variables used in implicit rules); see Option '-r' described below.

`-R '

`- NO-Builtin-Variables'

Exclude using built-in rule variables (see the variables used by implicit rules). Of course, you can still define your own variables. Option '-r' automatically enables the option '-r' to take effect; because it removes the definition of the variable used by the implicit rule, the implicit rules lose the meaning of existence.

`-s'

`--silent '

`--quiet '

Silence option. Do not return to those executed commands. See the command back.

`-S '

`--NO-Keep-going '

`--stop '

The option '-k' is invalidated. Unless you are calling MAKE, you don't have to use this option by the variable makeflags, or you set the option '-k' in the environment.

`-t '

`- touch '

The logo file has been updated to the latest, but it does not update them. This is pretending those commands that have been executed and used to fool future Make calls. See instead of executing commands.

`-v '

`--Version '

Print the version of the Make program, the author list and the notes not guaranteed, then exit. `-w '

`--Print-directory '

Print all the working directories involved when performing your Makefile file. This is very useful for complex nested errors when tracking MAKE recursive calls. See recurrencing Make. In fact, you rarely need to specify this option because Make has completed the specified for you. See '--Print-Directory' options.

`--NO-print-Directory '

In the case of specifying option '-w', the print job path is prohibited. This option is turned on automatically in Option '-w' and you don't want to see excess information. See '--Print-Directory' options.

`-W file '

`--What-if = file '

`--new-file = file '

`--ssume-new = file '

Pretending the target file has been updated. When using flag 'n', it will show you what will change. If there is no sign 'n' it and the result of the given file is almost the same as the result of the given file before running Make, but using this option Make just change the timestamp of the file. See instead of executing commands.

`--Warn-undefined-variables'

A warning message is issued when Make sees a variable that is not defined. This option is useful if you use a variable in complicated ways when you debug your Makefile file.

10 Use implicit rules

Some standard methods that recreate the target file are often used. For example, a traditional way to create an OBJ file is to use a C compiler, such as CC, compiling C language source programs.

The implicit rule can tell Make how to use traditional technology to complete tasks so that you don't have to specify them in detail when you use them. For example, there is an implicit rule for compiling the C language source program. The file name determines which implicit rules are running; Therefore, MAKE can determine the implicit rules of compilation C language source programs according to the suffix of this and file name. A series of implicit rules can be applied in order; for example, Make can rebuild a '.o' file from a '.c' file, refesting a '.o' file, see implied rule chains. The commands of the built-in implicit rules need to use variables. By changing the values ​​of these variables, you can change the hidden rules. For example, the variable CFLAGS control implicit rule is used to compile the C program to the flag of the C compiler, see the variables used by implicit rules. By writing format rules, you can create your own implicit rules. See Definition and redefine the format rules.

Suffix rules are most restrictive for definition implicit rules. Format rules are generally common and clear, but suffix rules are maintained compatibility. See the next time suffix rules.

10.1 Using implicit rules

Allow Make to look for a traditional update method for a target file, all of you do is to avoid designating any commands. You can write rules that do not have a command line or do not write any rules. In this way, Make will determine what implicit rules that use according to the type of source file or the file type to be generated.

For example, suppose the Makefile file is the following format:

Foo: foo.o bar.o

Cc -o foo foo.o bar.o $ (cflags) $ (ldflags)

Because you mentioned the file 'foo.o', you didn't give it a rule, and make will automatically find an implicit rule that can tell Make how to update the file. Regardless of the file 'foo.o', Make will execute this.

If you can find a hidden rule, it can support commands and one or more dependencies (source files). If you want to specify additional dependencies, such as header files, but implicit rules cannot be supported, you need to write a rule that does not command line without command 'foo.o'. Each implicit rule has a target format and a dependency format; perhaps a number of implicit rules have the same objective format. For example, there is a few unclear rules generate '.o' file: compile '.c' files using the C compiler; compile the '.p' file using the Pascal compiler; and so on. Rules for practical applications are those that depend on existence or can create. So, if you have a '.c' file, make will run the C compiler; if you have a '.p' file, make will run the Pascal compiler; etc.

Of course, when you write a Makefile file, you know which implied rules you want make, and you know which rules you will choose, because you know that the dependency file is assumed to exist. Details of the predefined implicit rule list See the implied rule directory.

First, we say that a hidden rule can be applied, the dependence of this rule must 'exist or can create'. A file 'can create' is that this file is mentioned as a target or dependencies in makefile, or that file can be created after a hidden rule is recursive. If a hidden rule is dependent on another implicit rule, we say that the 'chain' is generated. See implied rule chains.

Overall, MAKE searches for implicit rules for each target, and search for implicit rules for the double-cut rules without command lines. Just as the file mentioned, it will be considered a target. If the target is not specified, the make will search for implicit rules. See the search algorithm for implicit rules for detailed search procedures.

Note that any specific dependencies do not affect the search for implicit rules. For example, it is considered that this is a specific rule:

FOO.O: foo.p

File foo.p is not a primary condition, which means that Make can create an OBJ file from a PASCAL source ('.p' file) according to implicit rules, which means a '.o' file can be based on '.p' files Update. But the file foo.p is not absolutely necessary; for example, if the file foo.c exists, it is rebuilt foo.o from the file foo.c according to the implicit rule, because the C compilation rule is in a predefined implicit rule. Refer to the implicit rule directory than the PASCAL rules.

If you don't want to use an implicit rule to create a target without a command line, you can specify the empty command by adding a semicolon to the target. See Using empty commands.

10.2 Implied rules directory

Here is the directory of predefined implicit rules. These implications rules are often applied. Of course, if you overload or delete in your Makefile file, these implications will lose their role, detailed reference to delete hidden rules. . Option '-r' or '--NO-Builtin-Rules' will delete all predefined implicit rules.

Not all implicit rules are predefined. Many predefined implicit rules in Make are extensions of suffix rules, so those predefined implicit rules and suffix rules are related (special goals. Suffixes) Relying on the list). The default suffix list is: .out, .a, .ln, .o, .c, .cc, .c, .p, .f, .f, .r, .y, .l, .s,. S, .mod, .ssym, .def, .h, .info, .dvi, .tex, .texinfo, .Texi, .txinfo, .w, .ch, .web, .sh, .elc, .l. All the implicit rules described below, if their dependencies have an appearance in this suffix list, is a suffix rule. If you change this suffix list, only those predefined suffix rules nammered by one or two appears in the list you specify; those suffixes are disabled in the list. For detailed descriptions of the description of the suffix, see the outdated suffix rule. Compiableing C Programs (Compiling C Programs)

'N.o' is automatically generated by 'n.c' using command '$ (cc) -c $ (cppflags) $ (cflags)'.

Compiableing C Programs (Compile C )

'N.o' is automatically generated by 'n.cc' or 'n.c' uses command '$ (cxx) -c $ (cppflags) $ (cxflags)'. We encourage you to use the suffix '.cc' instead of the suffix '.c' for the C source file.

Compiling Pascal Programs (Compiling Pascal Programs)

'N.o' is automatically generated by 'n.p' uses command '$ (pc) -c $ (pflags)'.

Compiling Fortran and Ratfor Programs (Compile Fortran and Ratfor Programs)

'N.o' is automatically generated by 'n.r', 'n.f' or 'n.f'. The exact order used is as follows:

`.f '

`$ (Fc) -c $ (fflags) '.

`.F '

`$ (Fc) -c $ (fflags) $ (cppflags) '.

`.r '

`$ (Fc) -c $ (fflags) $ (rflags) '.

PreProcessing Fortran and Ratfor Programs (Prerequisite Fortran and Ratfor Programs)

'N.f' is automatically obtained from 'n.r' or 'n.f'. This rule is merely converting a Ratfor program or a pre-processed Fortran program to a standard FORTRAN program. The exact order used is as follows:

`.F '

`$ (Fc) -f $ (cppflags) $ (fflags) '.

`.r '

`$ (Fc) -f $ (fflags) $ (rflags) '.

Compiling Modula-2 Programs (Compile Modula-2 Program)

'N.sym' is automatically generated by 'n.def' using command '$ (m2c) $ (m2flags) $ (deflags)'. 'N.o' is generated from 'n.moD'; command is: '$ (M2C) $ (M2Flags) $ (MODFLAGS)'.

Assembling and PreProcessing Assembler Programs (Compilation, and Preprocessing Compilation) 'n.o' From 'N.S' Run C Compiler, CPP, Generate. The command is: '$ (CPP) $ (cppflags)'.

LINKING A SINGLE Object File (Connect a simple OBJ file)

'N' Automatically generates the connection program Linker in the 'n.o' running the C compiler. The command is: '$ (cc) $ (ldflags) N.O $ (LDLIBS)'. This rule works normally to a simple program with only one source program or a program that contains multiple OBJ files (possibly from different source files). If you contain multiple OBJ files, you must have an OBJ file name and the executable file name. E.g:

x: y.o z.o

When 'x.c', 'y.c' and 'z.c' exist:

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

For more complex situations, such as no name and executable file names of an OBJ file, you must write a specific command for the connection. Each file that can automatically generates '.o', can use the compiler ('$ (cc)', '$ (fc)' or '$ (pc)' without the '-C' option; c Compiler '$ (cc)' also applies to assembler) automatic connection. Of course, you can also use the OBJ file as an intermediate file, but compile, the connection is a lot of speed.

YACC for C Programs (Generated by Yacc)

'N.c' automatically runs YACC generated by 'n.y' uses command '$ (YACC) $ (YFLAGS)'.

Lex for C Programs (Generated by Lex)

'N.c' automatically runs LEX by 'n.l'. Command is: '$ (lex) $ (lflags)'.

Lex for Ratfor Programs (Generate a Rator Program)

'N.r' automatically runs LEX generated by 'n.l'. Command is: '$ (lex) $ (lflags)'. For all LEX files, whether they generate C code or RatFor code, use the same suffix '.l' to convert, under specific occasions, use Make to automatically determine which language you use is impossible. If Make uses '.l' file to rebuild an OBJ file, it must guece which compiler to use. It is likely to guess the use of C compiler because the C compiler is more common. If you use the Ratfor language, make sure that 'n.r' is mentioned in the makefile file, enabling Make to know your choice. Otherwise, if you dedicate the Ratfor language, do not use any C file, please write '.c' in the hidden rule suffix:

.SUFFXES:

.Suffixes: .o .r .f .l ...

Making Lint Libraries from C, Yacc, or Lex Program (Create a LINT library by C, YACC, or LEX program)

'N.ln' can run from 'N.c' to generate. The command is: '$ (lint) $ (lintflags) $ (cppflags) -i'. Commands for the C program and for the 'n.y' or 'n.l' program.

Tex and Web (TEX and Web) 'n.dvi' can be obtained from 'n.tex' using command '$ (tex)'. 'n.tex' can be obtained from 'N.Web' using command '$ (weave)'; or from 'NW' (and 'n.ch', if 'n.ch' exists or can be constructed) Use command '$ CWEAVE '. 'N.p' can be generated from 'N.Web' using command '$ (tangle)'. 'N.c' can be obtained from 'N.W' (and 'n.ch' if 'n.ch' or can be built) uses command '$ (ctangle)'.

Texinfo and info (TexInfo and Info)

'N.dvi' can be obtained from 'n.texinfo', 'n.texi', or 'n.txinfo', using command '$ (texi2dvi)' to get. 'N.info' can create from 'n.texinfo', 'n.texi', or 'n.txinfo', creation using command '$ (makeinfo_flags)'.

RCS

File 'n' can be extracted from the RCS file named 'N, V' or 'RCS / N, V', if necessary. The specific command is: '$ (CO) $ (COFLAGS)'. File 'n' If already exists, even if the RCS file is more new, it cannot be extracted from the RCS file. Rules for RCS are ultimate rules, referred to a universal rule, so RCS cannot be generated from any source file, they must exist.

SCCS

The file 'n' can be extracted from the SCCS file named 'S.n' or 'sccs / s' name when necessary. The specific command is: '$ (GET) $ (gflags)'. Rules for SCCS are ultimate rules, referred to a universal rule, so SCCS cannot be generated from any source file, they must exist. The advantage of SCCS is that file 'n' can copy and generate executables from file 'n.sh' (anyone can). This is used for SHELL scripts that check within SCCS. Because the RCS allows keeping the file's executability, you don't have to use this feature for the RCS file. We recommend that you avoid using SCCS, RCS is not only wide, but also free software. Choosing free software replaces quite (or poor) toll software is your support for free software.

Normally, you have to change the variables in the top table, you need to see the following document.

The hidden rules actually use variables such as Compile.c, Link.p, and PreProcess.s, whose values ​​contain the commands listed above. Make is processed according to the convention, such as compiling the rules of '.x' source files Use variables 'compile.x'; from '.x' source file generating executable Use variable 'link.x'; pre-processing '.x' Source file uses variable 'preprocess.x'.

Any rule that produces an OBJ file uses variable 'output_option'; Make Defines the value of this variable based on compilation time options is '-o $ @' or null value. When the source file is distributed in different directories, you should use the '-o' option to ensure that the output is used to the correct file; the same variable vPath is used (see the search directory). Some system compilers do not accept '-O' switches for Obj files; if you run on such a system and use variable vPath, some file compilation output may be placed. The solution is to set the variable Output_Option value to: '; mv $ *. O $ @'. 10.3 Variables used in implicit rules

The built-in implicit rule command is open to the predefined variable; you can change the value of the variable in the makefile file, or you can use the Make's running parameters or change in the environment, and do not redefine these rules itself In the case of it, these rules can be changed. You can also use option '-r' or '--no-builtin-variables' to delete all implicit rules used by all implicit rules.

For example, the command to compile the C program is actually '$ (cc) -c $ (cflags) $ (cppflags)', and the variable default value is 'cc' or null value, which is actually 'cc -c'. If the value of the redefined variable 'cc' is 'NCC', all implicit rules will use 'NCC' as a compiler that compiles the C language source. By redefining the value of the variable 'cflags' '-G', you can pass the '-G' option to each compiler. Use '$ cc' to get the name of the compiler when you compile the C program, and you contain '$ (cflags)' in the parameters passing to the compiler.

The variables used by hidden rules can be divided into two categories: one is a program name variable (like CC), and the other is a variable containing the program running parameters (like CFLAGS). ('Program Name) may also contain some command parameters, but it must start with a program name that can be executed.) If a variable value contains multiple parameters, they are separated from spaces.

Here is the list of program name variables in built-in rules:

Ar

Archive management program; default: 'ar'.

AS

Compilation compiler; default: 'as'.

CC

C language compiler; default: 'cc'.

CXX

C compiler; default: 'g '.

CO

Unpacking the extracted file program from the RCS file; default is: 'CO'.

CPP

C language pre-processing with standard output; default: '$ (cc) -e'.

FC

Compilation and pre-processing procedures for Fortran and Ratfor language; default: 'f77'.

Get

Unpacking the extracted file program from the sccs file; default is: 'get'.

Lex

Transfer the Lex language into a program for C or Ratfor programs; the default is: 'lex'.

PC

Pascal program compiler; default: 'pc'.

Yacc

Change the YACC language into a program for C program; default: 'yacc'.

Yaccr

Change the Yacc language to the Ratfor program; default: 'yacc -r'.

Makefo

Converting the TexInfo source file to a program of an information file; default: 'makeinfo'.

TEX

The program from the TEX source generates a Tex DVI file; the default is: 'tex'.

Texi2DVI generates a program from TexInfo Source; default is: 'texi2dvi'.

WEAVE

Translate the Web into Tex; default: 'weave'.

CWEAVE

Translate CWEB to Tex; default: 'cweave'.

Tangle

Translate the web into a PASCAL; default: 'tangle'.

Ctangle

Translate the Web into C's procedure; default: 'ctangle'.

RM

Delete the command of the file; default is: 'RM-F'.

Here is a list of variables for the above program attached to the above program. In the case where there is no indication, the value of all variables is null.

Arflags

The logo for the file management program is default: 'rv'.

Asflags

Additional flags for assembly compilers (when the '.s' or '.s' file) is called.

Cflags

Additional flags for the C compiler.

CXXFlags

Additional flags for C compilers.

Coflags

Additional flags for RCS CO programs.

CPPFlags

An additional flag (C and Fortran compiler) for C pre-processing and using it.

Fflags

Additional flags for the Fortran compiler.

Gflags

Additional markers for the SCCS GET program.

LDFlags

Additional flags for calling the compiler of Linker ('ld').

Lflags

Additional markers for Lex.

Pflags

Additional flags for the Pascal compiler.

Rflags

Additional flags for processing the RatFor program.

YFLAGS

Additional marks for YACC. YACC.

10.4 implicit rule chain

Sometimes a file that requires multiple implicit rules that need to be used. For example, from the file 'n.y' generate file 'n.o', first run the implicit rule YACC, followed by running the rule CC. Such an implicit rule sequence is called an implicit rule chain.

If file 'n.c' exists or in the makefile file, you don't need any specific search: make first discovery to build 'n.c' by C compiler, which can generate this OBJ file, then consider generating 'N.c 'When you run Yacc, you will use the rule of YACC. This will eventually update 'n.c' and 'n.o'.

Even in the case where the file 'n.c' does not exist or not mentioned in the makefile file, Make can imagine the file 'n.y' and 'n.o' missing connections! In this case, 'n.c' is called an intermediate file. Once Make decides to use the intermediate file, it will enter the intermediate file into the database, as if the intermediate file is mentioned in the Makefile file; create an intermediate file according to the description of the implicit rule.

The intermediate files are used to reconstruct their rules as their own rules, but there are two different ways of processing compared to other files.

The first different processing method is if the intermediate file does not exist different: the usual file b If there is no existence, make think that a target relies on file B, which always creates file B, then update the target according to file B; but files b If an intermediate file, Make is likely to do other jobs regardless of it, that is, the file B is not created, nor does it update the final goal. The ultimate goal is updated only when the dependency of the file B is more than the final target 'new' or there is other reasons.

The second difference is that Make After the update target creates file B, if the file B is no longer needed, make will delete it. So a intermediate file does not exist after Make runs before running. Make Prints a 'RM -F' command when you report to you, indicating that the file is deleted.

Typically, any target and dependencies mentioned in the makefile file are not an intermediate file. However, you can specify some files as an intermediate file, which is: The file that is to be specified as an intermediate file as a special goal. Intermediate's dependence. This approach can take effect even if the document that is specifically mentioned in other methods. You can block automatic deletion of intermediate files by using file flags for secondary files. At this time, you will specify the intermediate file you need to be reserved as a special goal. Secondary's dependencies. For the secondary file, make will not create it because it does not exist, and it will not automatically delete it. Secondary file must also be an intermediate file.

You can list a target format (for example,% .o) that is implied as a special goal. Prism, which you can keep the file name that matches the format of the file name created by implicit rules. See Interrupt and Close Make.

A implicit rules chain contains at least two implicit rules. For example, from 'RCS / FOO.Y, V' Creating File 'foo', you need to run RCS, YACC, and CC, file foo.y and foo.c are intermediate files, and will be deleted after running.

No implicit rules can appear twice or more (including twice) in implicit rules chains. This means that Make will not simply think that the file foo.o 'creation file foo is not running Linker twice. This can also force Make to block an unlimited loop when searching for a hidden rule chain.

Some special implicit rules optimize the specific cases of implicit rule chain control. For example, creating files from file foo.c FOO can be compiled and configured with rule chain control, which uses foo.o as an intermediate file. However, there is a special rule for this situation, using a simple command CC can be compiled and connected at the same time. Because the optimization rules are in front of the rule table, the optimization rules are prioritized by optimizing the rules and one-step rule chain.

10.5 Define and redefine format rules

You can define implicit rules by writing format rules. This rule looks similar to normal rules, and the difference is that characters '%' (only one) is included in the objective rule. The goal is to match the format of the file name; characters '%' can match any non-empty strings, while other characters matches themselves. Relying on '%' indicates their names and target names.

Format '% .O:% .C' is to compile any 'STEM.C' file as 'STEM.O' file.

The '%' extension used in the format rules is done after all variables and function extensions, which are completed when the Makefile file is read. See using variables and conversion text functions.

10.5.1 Introduction to Format Rules

The format rules are rules that contain characters '%' (only one) in the target, which looks the same as normal rules. The goal is to match the format of the file name, the character '%' can match any non-empty strings, while other characters are only matched to them.

For example, '% .C' matches any file name ended with '.c'; 's.%. C' matches the name of 's.' Starting with '.c', this file name is at least 5 Character (because '%' matches at least one character). The sub-string of matching '%' is called STEM. Depending on the '%' to indicate the same STEM in their names. To use format rules, the file name must match the target's format, and the file that meets the dependency format must exist or can be created. The following rules:

% .O:% .c; command ...

Indicates that you want to create file 'n.o', use 'n.c' as its dependence, and file 'n.c' must exist or can be created.

In the format rule, depending on sometimes no '%'. This indicates that all files created by this format rule are the same dependence. This fixed-dependent format rule is very useful in some occasions.

The dependence of the format rule does not have to contain character '%', such a rule is a powerful conventional wildcard, which provides a creation method for any file that matches the target format rule. See Defining the default rules for the latest type. Format rules can have multiple targets, not normal rules, this rule cannot play multiple different rules with the same dependency and commands. If a format rule has multiple targets, Make knows that the rules are reliable for all goals, which are only performed when creating the target. When matching a target search format rule, the target format and rules must match the target of the target, so Make is just worried that there is a problem with the current command and dependence on the file. Note that the command of the file is executed, and all target timestamps will be updated.

The format rules are important in the Makefile file, as this is also considered their order. For multiple rules that can be used, use the first to appear rules. The rule you personally prepare is preferred than the built-in rules. Note that the rules that depend on the existence or mentioned are preferred to rely on the rules that need to be included in the implicit rules chain.

10.5.2 Examples of format rules

Here have some format rules examples that are actually predefined in Make, the first, compiled '.c' files generate '.o' file rules:

% .O:% .c

$ (CC) -C $ (CFLAGS) $ (CPPFLAGS) $ <-O $ @

Define a rule that compiles the 'x.c' file to generate the 'x.o' file, commands using auto variables '$ @' and '$ <' to replace any situation using the rule target file and source file. See Automatic variables.

The second built-in example:

% :: RCS /%, V

$ (CO) $ (COFLAGS) $

Define the rules of the file 'x' in the subdirectory 'RCS' to generate file 'x' based on the corresponding file 'x.v'. Because the target is '%', this rule can be applied to any file as long as the corresponding dependent file is present. The double-selling number indicates that the rule is the final rule, which means that it cannot be an intermediate file. Refer to the usual rules.

The following format rules have two goals:

%. Tab.c% .tab.h:% .y

Bison -d $

This tells the Make to execute the command 'bison -d x.y' will create 'x.tab.c' and 'x.h'. If the file foo relies on file 'parse.tab.o' and 'scan.o', the file 'scan.o' rely on file 'parse.tab.h', when 'Parse.y' changes, command 'bison - D PARSE.Y 'is executed once. 'Parse.tab.o' and 'Scan.o' are also updated. (Suppose the file 'parse.tab.o' is compiled by the file 'parse.tab.c', and the file 'scan.o' is generated by file 'scan.c', when connecting 'Parse.tab.o', 'Scan. O 'and other dependency file foo, the above rules can be implemented well.)

10.5.3 Automatic variable

Suppose you write a rule for compiling '.c' files generated '.o' file: How do you write command 'cc' so that it can operate the correct file name? You certainly can't write file names directly into the command because the file names that use implicit rules are not the same.

You should use another feature of Make, automatic variable. These variables generate new values ​​based on targets and dependencies at rules. For example, you can use the variable '$ @' instead of the target file name, the variable '$ <' replaces the dependent file name.

Here is the list of automatic variables:

$ @ @ @ @ @ @

Rule target file name. If the goal is a file member, the file name of the variable '$ @' file file. For format rules with multiple targets (see Format Rule Description), the variable '$ @' is the target file name that causes the rule command to run.

$%

When the goal is a member of the file, this variable is the target member name, see Using Make to update the file file. For example, if the target is' foo.a (bar.o) ',' $% 'value is' bar.o', '$ @' 'value is' foo.a'. If the target is not a file member, '$%' is a null value. $

The first dependency file name. If the target update command comes from an implicit rule, the value of the variable is the first dependency added to the implicit rule. See Using an implicit rule.

$?

All the dependent names of the target 'new' are separated between the names. For the dependence of the file member, you can only use the named member. See Using Make to update file files.

$ ^

All dependencies, the names are separated from spaces. For the dependence of the file member, you can only use the named member. See Using Make to update file files. For the same goal, a file can only be used as a dependence, regardless of how many times the file name of the file is dependent on the list. So, if you rely on the list, the same file name has multiple times, the value of the variable '$ ^' still contains only the file name once.

$

This variable is like '$ ^', but the dependence of more than one listed will be replicated according to the order in which they appear in the Makefile file. This main purpose is to use the connection command for places that make sense to repeat the library file name in a particular order.

$ *

And the STEM that implies the rules, see the format match. If a target is 'DIR / A.FOO.B', the target format rules are: 'a.%. B', STEM is 'DIR / FOO'. STEM is very useful when building a related file name. In the static format rule, STEM is part of the file name in the character '%' in the target format. In a specific rule without STEM; variable '$ *' cannot be set in this method. If the target name ends with a recommended suffix (see the previous suffix rule), the variable '$ *' is set to the target after the target is removed. For example, if the target name is 'foo.c', the variable '$ *' is set to 'foo' because '.c' is a suffix. GNU Make Handling such a strange thing is to compatibility with other versions of Make. In addition to implied rules and static format rules, you should try to avoid using variable '$ *'. In the specific rule, if the target name does not end at the end of the recommended suffix, the variable '$ *' is set to null value in this rule.

When you want to operate only those changes, variables '$?' Is also useful even in specific rules. For example, assume that a file file named 'lib' contains a copy of the OBJ file, then the following rules will only copy the OBJ file that changes to the archive file:

LIB: foo.o bar.o lose.o win.o

Ar R LIB $?

In the variable listed above, the value of four variables is a single file name. The value of the three variables is a list of file names. These seven variables have only the path name of the file or only the variants of the file name under the directory. The variable name of the variable is composed of a variable name to add alphabet 'D' or 'F'. These variants are in a half-waste in GNU Make because the same results can be obtained using functions T DIR and NOTDIR. Refer to the file name function. Note that 'F' variants omit all end slashes in the DIR function here are the list of these variants:

`$ (@ D) '

The path part in the target file name is removed from the end slash. If the value of the variable `$ @ 'is` dir / foo.o', the value of variant `$ (@ d) 'is` Dir'. If the value of the variable `$ @ 'does not include a slash, the value of the variant is`'.

`$ (@ F) '

The true file name section of the target file name. If the value of the variable `$ @ 'is` dir / foo.o', the value of the variant `$ (@ f) 'is` foo.o'. `$ (@ F) 'Is equivalent to` $ (notdir $ @)'. `$ (* D) '

`$ (* F) '

The path name and file name in STEM; in this example, their values ​​are: `Dir 'and` foo'.

`$ (% D) '

`$ (% F) '

The path name and file name in the file member name; this is only meaningful for file member objectives in the form of 'archive' form, and is useful when the member contains the path name. See the file member target.

`$ (

`$ (

The path name and file name in the first dependency name.

`$ (^ D) '

`$ (^ F) '

The path name and file name list in all dependencies.

`$ (? D) '

`$ (? F) '

All the path names and file names in the dependent name of the target 'new'.

Note that when we discuss automatic variables, we used special format practices; we wrote "The value of '$ <'", not "the variable <"; and we write ordinary variables, such as variables Objects, and CFLAGS. We think this convention seems to be more natural in this case. This doesn't make anything else, the variable '$ <' variable name is the "CFLAGS) 'actual variable name CFLAGS. You can also use '$ (<)' instead '$ <'.

10.5.4 Format matching

The objective format is composed of a germacy between the prefix, suffix, and the wildcards thereof, and any of them can be null. The format matches a file name only if the file name is started with the prefix, the suffix ends, and the two do not overlap, it matches. The text between the prefix and the suffix becomes a path (STEM). When the format '% .O' matches the file name 'test.o', the path (STEM) is 'Test'. Depending on the format rule replaces the character% to the file name. For the above example, if a dependent is '% .c', it can be expanded to 'Test.c'.

When the target format does not include a slash (actually not this), the path name in the file name is first removed, then compared to the prefixes and suffixes in the format. After comparison, the path name ends with the slash will be added to the previously dependent on the dependencies depending on the format rule. The path name is only ignored when looking for implicit rules, and the path name is not ignored when the application is applied. For example, 'E% T' and file name 'src / eat' match, STEM (path) is 'SRC / A'. When the dependency is converted into a file name, the pathname in the STEM will be added to the remainder of the STEM (diameter). The file name 'src / car' matched using STEM 'SRC / A' and Dependent Format Rule 'C% R'.

10.55 million rules

The target of a format rule only contains '%', which can match any file name, we call these rules to be a rule. They are very useful, but Make uses a lot of time consumption, because Make must consider such rules for each file listed as a target and as a dependency.

Suppose the Makefile file refers to the file foo.c. In order to create this goal, make will consider creating by connecting an OBJ file 'foo.c.o', or created from the file foo.cc by using a step C compiler, or compiles the connection PASCAL program foo.cp creation And other possibilities, etc. We know that the possibility of make consideration is ridiculous because foo.c is a C language source program, not an executable program. If Make considers these possibilities, it will eventually reject them because these files such as foo.c.o and foo.c. However, these possibilities are too much, so that the running speed of MAKE is extremely slow.

In order to speed up the speed, we set a limit for Make considering matching the usual rules. There are two different types of applicable restrictions. When you define a multimetric rule each time you define a rule, you must select a rule that you define in these two types.

One option is that the usual rule is the final rule, that is, uses a double-selling definition when defined. When a rule is the final rule, only if its dependence is present, even if it can be created by the implicit rule. In other words, there is no further chain in the final rules.

For example, from the RCS and SCCS files built-in implicit rules are the final rules, then if the file 'foo.c, v' does not exist, make will never try to "foo.c, v, v, v, v" .o 'or' rcs / sccs / s.foo.c, v 'is created. RCS and SCCS files are generally the final source file, which cannot be recreated from any other file, so Make can record timestamp, but do not look for the way of rebuilding them.

If you don't marry the multimetric rule flag as the final rule, then it is the right non-final rule. A non-final multi-purpose rule cannot be used to specify files for special types of data. If there is a target matching of other rules (non-universal rules), the file name is the file name specified for special types of data.

For example, the file name 'foo.c' and format rules `% .c:% .y '(this rule runs YACC). Whether it is actually used (if you happen to exist file 'foo.y', the rule will run), and the fact that the target matches the fact that any non-final million rules will be used on the file foo.c. In this way, MAKE is considered to create executable 'foo.c' from the file 'foo.c.o', 'foo.c.c', 'foo.p', etc..

Built-in special pseudo format rules are used to identify some specific file names, and cannot use non-final multi-purpose rules when handling these file names. These pseudo-format rules do not depend and command, which are ignored when they are used for other purposes. For example, built-in implicit rules:

% .p:

There is a PASCAL source program such as 'foo.p' to match a specific target format, thereby preventing waste of time to look for 'foo.p.o' or 'foo.p.c'.

In the suffix rule, the pseudo formulation rules are created for each valid suffix in the suffix list, such as '% .p'. See the next time suffix rules.

10.5.6 Delete implicit rules

By defining a new rule with the same objectives and dependence but different commands, you can overload built-in implicit rules (or retrieve the rules you defined your own). Once a new rule is defined, the built-in rules are replaced. The new rules are determined by the location of the rules in the sequence table of the implicit rules.

You can delete built-in implicit rules by defining a new rule with the same objectives and dependencies but without commands. For example, the following definition rules will delete an implicit rule of the run assembly compiler:

% .O:% .s

10.6 Defining the default rules of the latest type

You can define the default rules of the latest type by writing unsteady of the final multi-purpose format rules. Refer to the usual rules. This is basically the same as other rules, in particular, it can match any target. Therefore, such rules can be used for all targets and dependencies without their own commands, as well as the goals and dependencies that can be applied without other implicit rules. For example, when testing Makefile, you may not care if you have real data, just concerned if they exist. So you can do this:

% ::

Touch $ @

This causes all required source files (as dependent) to be automatically created.

You can define the target without the rules and destination commands without specific specified commands. To complete the above tasks, you need to write rules for special goals. DEFAULT. Such rules can be used in all specific rules without the dependence as a target and cannot use implicit rules. Naturally, if you do not write a definition, there is no special target. DEFAULT rules.

If you use special goals. DEFAULT without any rules and commands:

.DEFAULT:

Then before the target. DEFAULT defined command is cleared. Such make behavior and you never define the target. DEFAULT.

If you don't need a goal to get a command from the multi-purpose rules and destination. DEFAULT, you don't want to execute any commands for this target, you can use empty commands when defined. See Using empty commands.

You can use the latest type rules to overload a part of another Makefile file. See Rebuild Other Makefile files.

10.7 Outdated suffix rules

Suffix rules are an excessive approach to define implicit rules. Suffix rules are abandoned because the format rules are more common and concise. They are supported in GNU Make to be compatible with early Makefile files. They are divided into single-binding and double suffix rules.

Double suffix rules are defined by a pair of suffixes: the target suffix and the source file suffix. It can match any file names with the target suffix. The corresponding implicit reliance is obtained by replacing the target suffix by the file name in the file name. One goal and source file suffix are '.o' and '.c' double suffix rules equivalent to format rules `% .O:% .c '.

Single suffix rules are defined by a single suffix, which is the suffix of the source file. It matches any file name, and its corresponding dependence is obtained by adding a file name to the source file suffix. Source file suffix is ​​'.c' single suffix rules equivalent to format rules '%:% .c'.

After comparing the rules target and the defined known suffix list, the chart is identified. This rule is considered a single suffix rule when Make see a target suffix. This rule is considered a two-suffix rule when Make is a rule that contains two known suffixes.

For example, '. O' and '.c' are known suffixes in the default list. So, if you define a rule, its goal is '.c.o', make Make think is a two-suffix rule, the source file suffix is ​​'.c', the target suffix is ​​'.o'. Here is a rule that uses an outdated method definition to compile C language programs:

.c.o:

$ (CC) -C $ (CFLAGS) $ (cppflags) -o $ @ $ <

Suffix rules can not have any dependencies that belong to them. If they rely, they will not be used as a suffix rule, but to handle normal files in a ridiculous manner. For example, rules:

.c.o: foo.h

$ (CC) -C $ (CFLAGS) $ (cppflags) -o $ @ $ <

Tell the file from dependent foo.h to generate file names '.c.o', is not like format rules:

% .O:% .c foo.h

$ (CC) -C $ (CFLAGS) $ (cppflags) -o $ @ $ <

Tell the method from '.c' file to generate '.o' file '.c': Create all '.o' files Use this format rule, and use the dependent file 'foo.h'.

There is no meaning of suffix rules without commands. They do not have the format rules that do not ordered to remove the previous rules (see Deleting Implied Rules). They simply add suffixes or double suffixes in the database as a goal. Known suffixes are special target '.suffixes' simple dependency name. To add more dependence by writing rules for special goals '.suffixes', you can add your own known suffix. E.g:

. Suffixes: .hack .win

Add '.hack' and '.win' into the suffix list.

If you want to exclude the default known suffix instead of just add a suffix, you can write unregistered rules for special goals '.quffixes'. In this way, the dependence of special target '.suffixes' can be completely excluded. Then you can write another rule to add the suffix you want to add. E.g,

.Suffixes: # Delete the default suffix

.Suffixes: .c .o .h # Define your own suffix list

The flag '-r' or '--no-builtin-rules' can also empty the default suffix list.

Variables Suffixes define the default suffix list before make reads any Makefile file. You can change the suffix list with special target '.suffixes', but this cannot change the value of the variable Suffixes.

10.8 Implied Rule Search Algorithm

Here is the process of making Make as a target 'T' search for implicit rules. This process is used for any doller rules that do not have commands, which are used for the goals of ordinary rules that do not contain commands, as well as the dependence on any other rule target. This process can also be used to rendepending the rules of recursive recursions from implicit rules.

No suffix rules are not mentioned in this algorithm, as suffix rules transform to format rules when the Makefile file is read.

For the file member objective of 'Archive (Member)', the following algorithm repeats twice, the first time the entire target name 't', if the rule is found for the first time, the second use '(MEMBER) 'As the target' t '.

1. The path portion is separated in 't', referred to as 'd', and the remaining portion is called 'n'. For example, if 't' is 'src / foo.o', 'd' is 'SRC /'; 'N' is 'foo.o'.

2. Establish all target names to match the list of format rules of 'T' and 'N'. If the target format contains a slash, match 't', otherwise, match 'n'.

3. If there is a rule in the list that is not a multimetric rule, remove all non-final million rules from the list.

4. The rules that will not be commands are also removed from the list.

5. Format rules in each list:

1. Look for STEM's', which is the 'T' or 'N' part of the most in the target format.

2. Use STEM's' to calculate the redeemed name. If the target format does not include a slash, add 'd' the front of each dependency.

3. Test all dependencies exist or can be created. (If any file is mentioned as a target or dependencies in makefile, we say that it should exist.) This rule can be used if all dependencies or can be created, or without dependence.

6. If it is not found to use the rules that can be used, further test. Rules in each list:

1. If the rule is the final rule, ignore it and continue the next rule.

2. Calculate the name as the above.

3. Test all dependencies exist or can be created.

4. For non-existent dependencies, recursively invoking the lookup in accordance with the algorithm can be created with an implicit rule.

5. Apply this rule if all dependencies or can be created with an implicit rule.

7. If there is no implicit rule, if you have the target '.default' rule, you apply this rule. In this case, the command '.default' command is given to 't'. Once you find the rules that can be applied, use STEM's' replacement% for each match (whether 't' or 'n') is used, and the resulting file name is stored until the command update target file 't' is executed. After these commands are executed, put each stored file name into the database, and the flag has been updated, the timestamp and the target file 't'.

If the command of the format rule is performed, the auto variable will be set to the corresponding goals and dependencies (see Auto Variables).

11 Update file files using Make

The file file is a file containing subfiles. These subfolds have their own file names, which generally call them members; archive files and program ARs are mentioned, their main use is the routine library for connection.

11.1 Archive Member Goals

Independent file members can use as target or dependencies in Make. Follow the way below, you can specify a member called 'MEMBER' in the file file 'archive':

Archive (MEMBER)

This structure is only used in the target and dependencies, and it must not be applied in the command! Most programs are not supported in commands, and they cannot be directly operated by file members. Only programs Ar and those designed to operate file files can do this. Therefore, the command of the legal update file must use Ar. For example, the following rules indicate that a member 'Hack.o' is created in the file 'foolib' in the file 'Foolib':

FOOLIB (HACK.O): Hack.o

Ar Cr Foolib Hack.o

In fact, almost all file member objectives are updated in this way, and there is an implicit rule to specifically update the file member target. Note: If the file file does not exist directly, the 'C' flag of the program Ar is required.

In the same file, you can specify several members and you can write all members named together in parentheses. E.g:

FOOLIB (Hack.o Kludge.o)

Equivalent to:

FOOLIB (Hack.o) Foolib (Kludge.o)

You can also use the shell type wildcard in the archive member reference. See Using wildcards in the file name. For example, 'fooLib (*. O)' extends to all members of '.o' ending in file 'foolib'. Perhaps equivalent to: 'Foolib (Hack.o) Foolib (Kludge.O)'.

11.2 Implicit rules for file member objectives

The target 'a (m)' represents a member named 'm' in the file file 'a'.

Make Search for this target hidden rule, it is a special feature of it: Make considers that the implies of match '(m)' also matches 'A (m)'.

This feature leads to a special rule, its goal is '(%)'. This rule updates the target 'A (m)' by copying the file 'm' to the file. For example, it updates the file member target 'foo.a (bar.o) by copying file' bar.o 'to file' foo.a '.

If the rules and other rules make up the chain, the features are very powerful. 'Make "foo.a (bar.o)"' (Note Double quotation is to protect the parentheses can be interpreted by Shell) Even if there is no Makefile file exists only file 'bar.c', you can ensure that the following command is executed:

Cc-C bar.c -o bar.o

Ar r foo.a bar.o

Rm -f bar.o

Here Make assumes that the file 'bar.o' is an intermediate file. See implied rule chains.

Such implied rules are written in automatic variable '$%', referred to automatic variable.

The file member name cannot contain the path name, but the path name is useful in the Makefile file. If you write a file member rule 'foo.a (dir / file.o), make will automatically use the following command update: Ar r foo.a dir / file.o

Its result is that the copy file 'dir / file.o' into the file called 'file.a'. Automatic variable% D and% f are used when completing such tasks.

11.2.1 Update the symbol index table

The file file used as the library typically contains a special member named '__. Symdef' special member, member '__. Symdef' contains an index table for an external symbol name defined by all other members. After you update other members, you must update members '__. Symdef', so that the member '__. Symdef' can be appropriate to summarize other members. To complete the member '__. Symdef' update needs to run the RANLIB program:

Ranlib ArchiveFile

Normally, you should put this command in the rules of the file file, and members of all file files are dependent on this rule. E.g:

Libfoo.a: libfoo.a (x.o) libfoo.a (y.o) ...

Ranlib Libfoo.a

The result of the above program is to update the file member 'X.O', 'Y.O', wait, and then update the symbol index table member '__. Symdef' by running the program RANLIB. Updating the rules are not listed here, in most cases, you can omit them, copy the file to the file using the implicit rules, and details the previous content.

This is not necessary when using the GNU AR program because it automatically updates the member '__. Symdef'.

11.3 Danger of using files

At the same time, in parallel execution (-J switch, see parallel execution) and file should be very careful. If multiple commands are operated at the same time, they don't know each other, it is possible to destroy files. The future MAKE version may provide a mechanism for this issue to serialize all the commands of all operations. But now, you must avoid this issue when writing your own makefile file, or otherwise, or not using the option -j.

11.4 Suffix rules for file files

To process file files, you can write a special type of suffix rule. See the outdated suffix rules for all suffixations. Archive suffix rules have been discarded in GNU Make because format rules for archives are more common (see the implicit rules of file member targets), but they are still retained.

Write a suffix rule for the file, you can simply write a suffix rule for the target suffix '.a'. For example, there is an excess suffix rule for updating the archive library from a C language source file:

.c.a:

$ (Cc) $ (cflags) $ (cppflags) -c $ <-O $ *. O

$ (Ar) R $ @ $ *. O

$ (Rm) $ *. O

This is exactly the same as the following format rules:

(% .o):% .C

$ (Cc) $ (cflags) $ (cppflags) -c $ <-O $ *. O

$ (Ar) R $ @ $ *. O

$ (Rm) $ *. O

In fact, this is just Make to see a suffix rule that is '.a' as a suffix, it works. Any double suffix rule '.x.a' is converted to a format rule, the target format of the format rule is '(% .o)', dependent format is '% .x' ..

Because you might want to use '.a' as a suffix of a file type, Make also converts file suffix rules in normal ways as the format rule, see Outth suffix rules. Such a double suffix rule '.x.a' generates two format rules: '(%. O):% .x' and '% .a:% .x'.

12 gnu make features

Here is a summary of the characteristics of GNU Make, used to compare other versions of MAKE. We are based on the characteristics of Make in 4.2 BSD. If you want to write a portable Makefile file, you don't use the characteristics of the Make listed here, do not use the contents listed in the incompatibility and loss of features.

Many features also exist in Make in System V.

Variable VPath and its special meaning. See searching on depends in the catalog. This feature exists in the Make in System V, but there is no factual prove. 4.3 BSD Make also contains this feature (it is said to imitate the characteristics of variable VPATFH in SYSTEM V). Contains other Makefile files. See containing other makefile files. Allows the use of an instruction to contain multiple files to be extended. Through the environment, the variables can be read and communicated, see environment variables. Options can be passed when recursive by variable makeflags. See And Submake Communication Options. The automatic variable is set to a member name in the file reference. See Automatic variables. Automatic variable $ @, $ *, $ <, $%, and $? Has variants such as $ (@ f) and $ (@d). We conceptualize this and use it significantly to automatic variable $ ^. See Automatic variables. Variable references. See the variable reference foundation. Command line option '-b' and '-m', acceptance and ignore. These options actually work in System V Make. Even if you specify option '-n', '- q' or '-t', you can use the MAKE command by the variable make. See recurrencing Make. Support suffix '.a' in the suffix rule. See the suffix rules for archival files. This feature is almost unused in GNU Make, as the rule chain is more common (see implied rule chains) allowing a format rule to be used to install members in the file (see implied rules for file member objectives). In the order of the bank, the new line is still reserved, when the command prints, the formats they appear are basically the same in the makefile file, and the difference is to remove the initialization blank.

The following features are absorbed by a variety of different versions of Make, but which versions are absorbed and is not very clear.

Use '%' in the format rules. There are several different versions of Make use this feature. We can't confirm who invented it, but it develops very quickly. See Definition and Redefining Format Rules. Rules chains and implicit intermediate files. This feature is first implemented by Stu Feldman in its Make version and is used in the AT & T Edition Edition UNIX research. The Andrew Hume of the AT & T Bell Lab was applied in its MK program (hereinafter referred to as "transfer closure"). We don't know that from them, they get this feature or at the same time we have developed. See implied rule chains. The automatic variable contains all the dependencies of the current target. We don't know who did it. See Automatic variables. Automatic variable $ is a simple extension of variable $ ^. "what if" flag ('-w' in GNU Make) is invented in the MK in the MK. See instead of executing commands. The concept of parallel execution exists in many versions of Make, although System V or BSD is not implemented. See the execution command. Replacing the variable in the format is referenced from SunOS 4. See the variable reference foundation. In GNU Make, this feature is provided by the function PATSUBST before transform syntax and SunOS 4 compatibility. I don't know who is authoritative, because GNU Make uses function PatSubst before the SunOS 4 is released. There is a special significance in the ' ' character in front of the command line (see instead of execution command). This is defined by IEEE STANDARD 1003.2-1992 (POSIX.2). Use the ' = syntax for the variable added value from SunOS 4 Make. See the text for variable values. Syntax 'Archive (MEM1 MEM2 ...)' lists multiple members from SUNOS 4 Make in a single file file. See the file member target. The -include instruction includes the Makefile file, and no errors are generated for unsaved files. This feature with comes from SunOS 4 Make. (However, SunOS 4 Make specifies multiple Makefile files in a single directive.) This feature is the same as the Sinclude of SGI Make, and the remaining feature is invented by GNU MAKE:

Print version and copy rights information using '-V' or `--Version 'option. Summarize the Make options using the '-h' or '--help' option. Simple extension variable. See the two special features of the variable. When recursive calling Make, the command line variable is automatically passed through the variable make. See recurrencing Make. Use the command option '-C' or '--Directory' to change the path. See Options Overview. Define multi-line variables. See Defining Multi-Bank Variables. Use special goals. Phony declares that imaginary goals. The AT & T Bell Lab andrew Hume uses a different syntax to implement this feature in its MK program. This seems to be parallel discovery. See the imaginary target. Call the function to operate text. Refer to the function of converting text. The presence file is an old file using the '-o' or '--old-file' option. See avoiding recompiling files. Condition execution. This feature has been implemented in different versions of Make; it seems to be a natural extension of C and a similar macro language rather than revolutionary concepts. See the conditional statement in the Makefile file. Specifies the search path of the containing makefile file. See containing other makefile files. Use environment variables to specify additional makefile files. See Variable Makefiles. Remove the front guided rightener from the file name, therefore, '. / File' and 'file' refer to the same file. Use special search methods to search for forms such as '-lname' library dependencies. See the connection library search directory. Allow suffixes in the suffix rule to contain any characters (see Outdown suffix rules). In other versions of Make must start with '.', And cannot contain '/' characters. Put the value of the variable makwfiles that is currently available for the current Make level, see recursive call. Place any target given in the command line into the variable Makecmdgoals. See the specified parameters of the final goal. Specify a static format rule. See Static Format Rules. Provide selective vPath search. See searching on depends in the catalog. Provide a calculated variable reference. See the variable reference foundation. Update the makefile file. See Reconstruction Makefile files. SYSTEM V MAKE has very limited forms from this feature, which is used to check the SCCS file for MAKE. Various newly built implicit rules. See implied rules directory. Built-in variables `make_version 'gives the version of the make. 13 incompatibility and loss of characteristics

Other versions of Make programs also have some features that are not implemented in GNU Make. The POSIX.2 standard (IEEE Standard 1003.2-1992) does not require these characteristics.

'File ((entry)' The object of the form represents a member file for a file file. Select this member without using the file name, but through a definition of the OBJ file of the connection symbol ENTY. This feature is not absorbed by the GNU Make because the non-standard component will add internal knowledge of the file symbol table for MAKE. See Updating the Archive Symbol Index Table. In the suffix rule, the suffix ends in characters '~' has a special meaning in System V Make; they refer to the SCCS files that are not filed in the file name. For example, suffix rules '.c ~ .o' will extract file 'n.o' from the SCCS file named 's.c'. In order to completely override, this series of suffix rules is required, see the outdated suffix rules. In GNU Make, this series of suffix rules are in charge of two format rules that are done from the SCCS file, and they can combine with the general rules into rule chains, see implied rule chains. In System V Make, string '$$ @' has a strange meaning, in the dependence of multiple rules, represents special goals being processed. This is not defined in GNU Make because the string '$$' represents a usual character '$'. Use a static format rule to implement a part of this feature (see Static Format Rules). Rules in System V Make:

$ (Targets): $$ @. o lib.a can be replaced by static format rules in GNU Make:

$ (Targets):%:% .o lib.a

In System V and 4.3 BSD Make, search for files discovered by vPath (see Search for Search Directory), their file names are added to the command string. We believe that the use of automatic variables is simpler, so this feature is not introduced. In some UNIX Make, automatic variable $ * There is a surprising special feature in the dependence of rules: extension is the full name of the target. We can't understand how Unix Make is thinking about this in your heart, and it is completely different from the normal variable $ *. In some UNIX Make, the implicit rule search (see Using Implied Rules) is obviously made for all targets, not just those destinations without commands. this means:

Foo.O:

cc -c foo.c

In Unix Make, Intuitive Know 'Foo.o' relying on 'foo.c'. We think that this is easy to cause confusion. The properties dependent in Make have been defined (at least for GNU Make), doing such a unregulated moment.

GNU Make does not contain any compilation and implicit rules that process the EFL program. If we have heard who uses EFL, we will join them. In SVR4 MAKE, a suffix rule can be free without commands, and its processing method is the same as it contains empty commands (see Using Air Command). E.g:

.c.a:

The built-in suffix rule '.c.a' will be overloaded. We feel that the target is simpler for the target to simply add the rules that do not ordered. The above example and the same behavior in the GNU Make.

.c.a:;

Some versions of Make call shell using the '-e' flag, not the '-k' flag (see the test program compilation). Sign '-E' tells shell to exit once the program runs back non-zero status. We believe that it is more clear in accordance with each command line needs to be required to write directly.

14 Makefile File Formula

This chapter describes the practice of writing makefile files for GNU Make. Using Automake will help you write your Makefile files in accordance with these conventions.

14.1 General Formula for Makefile Files

Any makefile file should include this line:

Shell = / bin / sh

Avoid the trouble of the variable shell in the system inheritance. (This is never a problem in GNU Make.)

Different Make programs have different suffix lists and implicit rules, which may cause confusion or wrong behavior. Therefore, the best way is to set the lumen list, in which the suffix is ​​included in the specific Makefile file. E.g:

.SUFFXES:

. Suffixes: .c .c .o

The first line clears the suffix list, the second line defines the suffix that may be implicitted in this makefile.

Don't assume '.' Is the path executed by the command. When you need to run a program in your package, please confirm that if the program is part of the program to create a part of the source code is used in the source code. '$ (srcdir)'. Without these prefixes, only search for the current path.

The difference between build directory './' and source directory '$ (srcdir)' is important, because users can build a separate in 'configure'. table of Contents. The following rules:

FOO.1: foo.man sedscript

Sed -e sedscript foo.man> foo.1

If the created directory is not the source code directory, it will fail because the file 'foo.man' and 'sedscript' are in the source code directory. When using GNU Make, relying on variable 'vPath' search source files can work well in the case of a single slave attribute file, because the automatic variable '$ <' contains the existence path of the source file. (Many versions of Make only set value variables '$ <' in implied rules.) For example, such a Makefile file target:

Foo.o: bar.c

$ (Cc) -i. -I $ (srcdir) $ (cflags) -c bar.c -o foo.o

Will be replaced with:

Foo.o: bar.c

$ (Cc) -i. -I $ (srcdir) $ (cflags) -c $ <-o $ @

This is to ensure the correct work of the variable 'vpath'. When the goal contains multiple dependencies, the use of the named '$ (srcdir)' is the easiest way to ensure that this rule works well. For example, the target 'foo.l' in the above example is preferably:

FOO.1: foo.man sedscript

Sed -E $ (srcdir) / Sedscript $ (srcdir) /FOO.MAN> $ @

GNU's classification typically contains files that are not a source file - for example, 'INFO' file, files output from AutoConf, Automake, Bison, or Flex, and the like. These files are in the source file directory, and they should also be in the source file directory, should not be under construction. Therefore, Makefile rules should update them in the source file directory.

However, if a file does not appear in the category, the Makefile file should not put them in the source file directory, because the source file directory should not be changed in any way according to the usual situation.

Attempting to build and install the target, at least (and their sub-objectives) can work correctly in parallel Make.

14.2 Makefile file tool

Writing the Makefile file command running in Shell SH without running in CSH, such as 'configure'), do not use any KSH or Bash special features.

The 'Configure' script and Makefile rules for creating and installing should not use any other tools directly outside the tools listed below:

CAT CMP CP Diff Echo Egrep Expr False Grep Install-Info

LN LS MKDIR MV PWD RM RMDir Sed Sleep Sort Test Touch True

The compression program Gzip can be used in the DIST rule.

Adhere to the common options used for these programs, for example, do not use 'mkdir -p', it may be more convenient, but most other systems do not support it.

Avoid creating a symbolic connection in makefile is very good, because some systems do not support this approach.

Makefile rules for creating and installing can use compilers and related programs, but they should be used via Make variables so that users can make alternatives. Here are some programs to prepare some of our ideas:

Ar Bison CC Flex Install LD LDCONFIG LEX

Make makeinfo ranlib texi2dvi yacc

Use the following MAKE variables to run these programs:

$ (AR) $ (BISON) $ (FLEX) $ (LD) $ (LDConfig) $ (Lex)

$ (MakeInfo $ (RANLIB) $ (Texi2DVI) $ (YACC)

With RANLIB or LDCONFIG, you should make sure if there are no programs to use in the system not to cause any side effects. Arrange to ignore the errors generated by these commands, and print information tells the user that the command does not mean there is a problem. (AutoConf'AC_Prog_ranlib 'macro can help you in this regard.) If you use symbolic connections, you should have a low-efficiency running for systems that do not support symbolic connections. Additional tools can also be used by MAKE variables:

Chgrp chmod chown mknod

It is in makefile (or in scripts), you know that it can work well in specific systems that contain these tools.

14.3 Specify the variable of the command

The Makefile file should provide variables for a specific command, option, and the like overloaded.

Special variables should be applied when you run most of the tools. If you want to use the program Bison, the default value named Bison's variable is set to: 'bison = bison', you can use it when you need to use the program Bison $ (Bison) reference.

File Manager tools such as LN, RM, MV, etc., unnecessary use of this way, because users cannot use other programs to replace them.

Each program variable should be provided with an option variable for providing an option to the program. Adding 'Flags' after the program name variable indicates an option variable that provides an option to the program - for example, BisonFlags. (Variables named CFLAGS Provide options to the CFLAGS, the variable named YFLAGS provides the YACC, the variable named LFLAGS is provided to the Lex, etc., it is this rule exception, but because they are standard so we keep them.) Any variable CPPFLAGS is used in any pre-processed compilation command, and the variable LDFLAGS is used in any connected compile command and the direct use of the program LD.

For options that the C compiler must use when compiling a specific file, it should not be included in the variable cflags because users want them to be freely specified variable cflags. To be independent of the variable CFLAGS arrangements to pass these necessary options to the C compiler, you can write these options to the definition of the compile command line or implicit rules, as in the following example:

Cflags = -g

ALL_CFLAGS = -i. $ (Cflags)

.c.o:

$ (Cc) -c $ (cppflags) $ (all_cflags) $

The variable CFLAGS includes option '-g' because it is not required for some compilation, you can think it is the default recommendation. If the packet creates the GCC as a compiler, the variable cflags includes option '-o', and it is default.

Place the variable cflags to the final of the compile command, in the back of the other variables including the compilation option, so the user can overload other variables using variable cflags.

Each time you call the C compiler to use the variable CFLAGS, whether it is compiled or connected.

All Makefile files define variable install, and the variable install is the basic command to install the file to the system.

Any Makefile file defines variable install_program and install_data, (their defaults are $ (INSTALL).) When the actual installer, the program or non-executable program is generally used as a command. Here is an example of using these variables:

$ (Install_Program) Foo $ (Bindir) / Foo

$ (Install_Data) Libfoo.a $ (libdir) /libfoo.a

You can set the variable Destdir to the target file name. Doing so allows the installer to create a snapshot that subsequently installs files in the actual target file system. Do not set the variable Destdir in your Makefile file, or include in the installation file. Change the above example with variable derSTDIR:

$ (Install_Program) Foo $ (DESTDIR) $ (BINDIR) / FOO $ (Install_Data) Libfoo.a $ (DESTDIR) $ (libdir) /libfoo.a

In the installation command, the file name is generally used instead of the path name as the second parameter. Separate commands are used for each installation file.

14.4 Installing the path variable

The installation directory is often named in variables, so it is also easy in non-standard local installation, and the standard names of these variables will be described below. The installation directory is based on the standard file system layout, the variation of the variable has been used in SVR4, 4.4BSD, Linux, Ultrix V4, and other modern operating systems.

The following two variables set the root directory of the installation file, all other installation directorys are one of them, without any files can be installed directly in these two roots.

`prefix '

The prefix is ​​a default value for constructing the following variables. Variable prefix default is '/ usr / local'. When building a complete GNU system, the default value of the variable prefix is ​​null, '/ usr' is symbolic connection '/'. (If you use AutoConf, you should write it as '@ prefix @'.) Use the value of the variable prefix that is different from the creation program to run 'make install', and does not recompile the program.

`EXEC_PREFIX '

The prefix is ​​a default value for constructing the following variables. Variables Exec_prefix default is $ (prefix). (If you use AutoConf, it should be written as `@ exec_prefix @ '.) Under normal circumstances. Variable $ (exec_prefix) is used to store directories containing machine-specific files, such as executables and routine libraries, and variable $ (prefix) stores other directories. Fun 'make install' when the variable EXEC_PREFIX is used differently from the creation program, and the program is not recompiled.

The executable is installed in the following directory:

`bindir '

This directory is used to install the executable that the user can run. Its normal value is '/ usr / local / bin', but it should be written as '$ (exec_prefix) / bin' when used. (If you use AutoConf, you should write it as '@ bindir @'.)

`sbindir '

This directory is used to install the executable executable executed from the Shell. It only has a role in the system administrator. Its normal value is '/ usr / local / sbin', but it should be written as '$ (exec_prefix) / sbin' when used. (If you use AutoConf, you should write it as '@ sbindir @'.)

`libexecdir '

This directory is used to install the executable of other programs calls. Its normal value is '/ usr / local / libexec', but it should be written as '$ (exec_prefix) / libexec' when used. (If you use AutoConf, you should write it as '@ libexecdir @'.)

Data files used in program execution can be divided into two categories:

The program can change normally and files that cannot be changed normally (although the user can edit some of the files). The architecture is independent of the file, which means that these files can be shared by all machines; system-related files, refer to files that can only be shared by the same type of machine, operating system; other files that can never be shared by two machines.

This can produce six different possibilities. We try to use the system-related documents, except for the OBJ file and library files. Data files that are not related to other systems are more concise, and they are not difficult.

So, there is a Makefile variable for specifying paths: `datadir '

This directory is used to install a read-only system-independent data file. Its normal value is '/ usr / local / share', but it should be written as '$ (prefix) / share' when using. (If you use AutoConf, you should write it as' @ datadir @ '.) As an exception, see the variable' $ (Infodir) 'and' $ (Includedir) described below.

`sysconfdir '

This directory is used to install read-only data files that belong to a single machine, which are: files for configuring the host. Mail service, network configuration file, '/ etc / passwd', and so on are all files here. All files in this directory are usually ASCII text files. Its normal value is '/ usr / local / etc', but it should be written as '$ (prefix) / etc' when using AutoConf, should write it as '@ sysconfdir @'.) Don't Install the executable here (they may belong to '$ (libexecdir)' or '$ (sbindir). Also don't install those files to be changed during use (these programs are used to change the system rejected configuration). They may belong to '$ (localstatedir).

`SharedStatedir '

The system-independent system-independent system for the installation program is running in this directory. Its normal value is '/ usr / local / com', but it should be written as '$ (prefix) / com' when used. (If you use AutoConf, you should write it as '@ sharedstatedir @'.)

`LocalStatedir '

This directory is used to change the data file to occur in the installer. But they belong to a specific machine. Users will never need to change file configuration package options in this directory; put these configuration information in separate files, these files will be placed in '$ (DATADIR)' or '$ (sysconfdir)', '$ (localStatedir ) 'The normal value is' / usr / local / var', but it should be written as' $ (prefix) / var 'when using. (If you use autoconf, you should write it as '@ localstatedir @'.)

`libdir '

This directory is used to store OBJ files and library OBJ code. Do not install executables here, they may belong to '$ (libexecdir). The value of the variable libdir is '/ usr / local / lib', but it should be written as '$ (exec_prefix) / lib' when used. (If you use AutoConf, you should write it as '@ libdir @'.)

`infodir '

The INFO file for installing the package in this directory. By default, its value is '/ usr / local / info', but it should be written as '$ (prefix) / info'. (If you use AutoConf, it should be written as '@ infodir @'. )

`lispdir '

This directory is used to install the Emacs Lisp file for the package. By default, its value is '/ usr / local / share / emacs / site-lisp', but it should be written as '$ (prefix) / share / emacs / site-lisp' when used. If you use AutoConf, you should write it as '@ lispdir @'. In order to ensure '@ lispdir @', you need to add the following lines to your 'configure.in' file: lispdir = '$ {datadir} / emacs / site-lisp'

AC_SUBST (Lispdir)

`incrudeir '

This directory is used to install the header files included in the C '# INCLUDE' pre-processing instruction in the user program. Its normal value is '/ usr / local / include', but it should be written as '$ (prefix) / include' when used. (If you use AutoConf, you should write it as '@ includedir @'.) In addition to the multi-GCC not in the directory '/ usr / local / include' search header file, this installation is only available for GCC. Sometimes this is not a problem, because some library files can only rely on GCC to work. But there are also some library files depending on other compilers, they install their header files to two places, one by variable INCLUDEDIR, and the other is specified by the variable OldInCludedir.

`oldincludedir '

This directory is used to install the header file of '#include', these header files for other C language compilers except GCC. Its normal value is '/ usr / include'. (If you use AutoConf, you should write it as '@ oldincludedir @'.) Makefile command variables OldincludDir's value is empty, if it is a null value, they are not attempting to use it, they also delete the second installed header file. A package replaces the existing header file in this directory unless the header is derived from the same package. For example, if your package foo provides a header file 'foo.h', it is installed in the directory specified by the variable OldInCludedIR is (1) There is no investment 'foo.h' or (2) from the software. The head files of the package foo.h 'have existed in this directory. To check whether the header file 'foo.h' comes from the package foo, place a MAGIC string into the file - as part of the command - then find the string using the regular rule (GREP).

UNIX style help file installation in the following directory:

`mandir '

Install the top floor of the package (if any) directory. Its normal value is '/ usr / local / man', but it should be written as '$ (prefix) / man' when used. (If you use AutoConf, you should write it as '@ mandir @'.)

`man1dir '

This directory is used to install the first floor help. Its normal value is '$ (MANDIR) / Man1'.

`man2dir '

This directory is used to install the first floor help. Its normal value is '$ (MANDIR) / Man2'.

`''

Do not use the main documentation of any GNU software as a help page. Use the manual should be written. The help page is just for people to run the GNU software on UNIX, which is an attached runner.

`manext '

The file name indicates the extension of the installed help page. It contains a certain cycle, followed by the appropriate number, normal '1'.

`man1ext 'file name indicates the extension of the first part of the installed help page.

`man2ext '

The file name represents the extension of the second part of the installed help page.

`''

Use these file names instead `Manext '. If the help page of the package needs to install multiple chapters of the manual.

Finally, you should set a variable:

`Srcdir '

This directory is used to install the original file to be compiled. The normal value of this variable is inserted by the shell script Configure. (If you use AutoConf, you should write it as 'srcdir = @ srcdir @'.)

E.g:

# Used to install the normal prefix of the path.

# Note: This path must exist when you start installation.

prefix = / usr / local

EXEC_PREFIX = $ (Prefix)

# Let's place the executable of the `gcc 'command call.

Bindir = $ (exec_prefix) / bin

# Let's place the catalog used by the compiler.

Libexecdir = $ (exec_prefix) / libexec

# Place the info file here.

Infodir = $ (Prefix) / Info

If your program is necessary to install a large number of files in the directory specified by the standard user, it is necessary to put the files of the program into the specified subdirectory. If you want to do this, you should write the installation rule to create these subdirectories.

Do not expect users to include these subdirectories in the variable values ​​listed above, allowing users to specify exact values ​​for different GNU packages for different GNU software packages, in order to make this practice, all packages It must be designed to work smart when users use.

14.5 User Standard Target

In all GNU programs, there are the following objectives in Makefile:

`all '

Compile the entire program. This should be the default goal. This goal does not have to rebuild document files. Info files should be included in each published file, the DVI file is only rebuilt under clear request. When the default, the Make rules compiles and connects to use option '-g', so program debugging is just symbolic. For users who don't mind missing help, if they want to separate the executables and help, peel off the executable.

`install '

Compile the program and copy the executable, library files, etc. to the file name that is reserved for actual use. If it is a simple test that is confirmed to be installed, the target should run the test program. Don't peel off the executable during installation, the devil is likely to care about those who use the Install-Strip target to peel off the executable. If this is feasible, the written install target rule should not change anything in the program built, just provide 'make all' everything can be done. This is to facilitate the user name and in other systems to install the construction program. If the directory to which the program is to be installed does not exist, this command should create all of these directories, including variable prefix and exec_prefix special specified directories and all necessary subdirectory. The method of completing this task is to use the target installdirs described below. Using '-' before all the commands of the Help page, use '-' to ignore the errors generated by these commands, which ensures smooth progress when installing the package on the system without a UNIX Help page. The method of installing the INFO file is to copy the INFO file into the variable '$ (in InfoDIR) using variable $ (install_data) (see the variable of the specified command), if the install-info program is running it. Install-Info is a program for editing Info'Dir 'files, which can add or update menus for the INFO file; it is part of the TexInfo package. Here is an example of installing an Info file:

$ (DESTDIR) $ (Infodir) /FOO.INFO: FOO.INFO $ (Post_Install)

# May be in '.' There is a new file in Srcdir.

-IF Test -f foo.info; then d = .; /

ELSE D = $ (srcdir); Fi; /

$ (Install_Data) $$ D / Foo.Info $ (DESTDIR) $ @; /

# Run it if the Install-Info program exists.

# Use 'if' instead of '-'

# This, we can notice the true error that runs install-info.

# We use '$ (shell) -c' because in some shell

# Incident unknown commands will not run failure.

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 put all the commands three classes: normal commands, pre-installation commands and post-installation commands. See the installation command classification.

`uninstall '

Delete all installed files - files with 'install' target copy. This rule should not change the catalog of compilation, just delete the directory of the installation file. The reverse installation command is divided into three classes like the installation command, see the installation command classification.

`install-strip '

Similar to the target install, but only the executable is peeled off at the time of installation. In many cases, the definition of this goal is very simple:

INSTALL-STRIP:

$ (MAKE) Install_Program = '$ (install_program) -s' /

INSTALL

Under normal circumstances, we do not recommend stripping the executable to install, only if you are confident that these programs do not generate problems. Stripping to install an actual executable executive while saving those executable files in this occasion of this occasion are obvious.

`clean

Delete files in all current directories, which are the files created by those 'creation program' normally. Don't delete files that record configurations, and you should also preserve those files that you can modify, and those files to be deleted under normal circumstances do not include these files because the release file is created with these files. If the '.dvi' file is not part of the file publishing file, use the target 'clean' to delete the '.dvi' file at the same time.

`distclean '

Delete files in all current directories, these files are normal, those created by the 'creation program' or 'Configuration Program'. If you don't decline the source program, 'Create program' does not create any other file, 'make distclean' will only leave the original file only in the file publish file.

`MostlyClean '

Similar to the target 'Clean', avoid deleting files that do not compile under normal circumstances. For example, target 'MOSTLYCLAN does not delete file' libgcc.a ', because it does not need to recompile in most cases.

`maintainer-clean '

Remove all files that can be reconstructed using this makefile file in almost current directory. The files deleted using this target include using the target Distclean, the deleted file plus the C language source file and the flag list, INFO file, and the like generated from Bison. We said that "almost all files" is that running command 'make maintainer-clean' does not delete script 'configure', even if script 'configure' can be created using the Makefile file. More specifically, run 'make maintainer-clean' does not delete all files involved in order to run script 'configure' and starting the program. This is a class of files running 'make maintainer-clean' deleting all uniquely unable to re-create files. The target 'maintainer-clean' is used by the contributing program of the package and cannot be used by ordinary users. You can rebuild files deleted by the target 'make maintainer-clean' using a special tool. Because these files are included in the published files, we don't care whether they are easy to reconstruct. If you find that you need to re-encapsulate all published files, you can't blame us. To help Make's users realize this, the target MAINTAINER-CLAN should start with the following two behaviors: @echo 'This command is only used for maintenance procedures;'

@echo 'It can be rebuilt using all the files it deleted. '

`Tags'

Update the logo table of the program.

`info '

Generate the necessary info files. The best way is to write like the rules below:

INFO: FOO.INFO

Foo.Info: foo.texi chap1.texi chap2.texi

$ (MakeInfo) $ (srcdir) / FOO.TEXI

You must set the variable Makefo in the Makefile file. It will run the MakeInfo program that is part of TexInfo in the release program. Under normal circumstances, a GNU publisher is created together, which means that the INFO file exists in the directory of the source file. When the user builds a package, Make does not update the INFO file because they have been updated to the latest.

`DVI '

Create a DVI file for updating the TexInfo document. E.g:

DVI: foo.dvi

Foo.dvi: foo.texi chap1.texi chap2.texi

$ (TEXI2DVI) $ (srcdir) / FOO.TEXI

You must define variable texi2dvi in ​​the makefile file. It will run the program Texi2DVI, which is part of the released TexInfo. Either write only files, or allow the gnu make to provide commands, both of them must be selected.

`dist '

Create a TAR file for the program. Creating a tar file can start in subdirectory name as sub-directory names, which can be the package name for publishing. In addition, these file names may also contain version numbers, for example, the subdirectory of the Published GCC 1.40 version of the sub-file unpack is 'GCC-1.40'. The most convenient way is to create a suitable sub-directory name, such as using IN or CP as a subdirectory, install the appropriate file below, then unpack the tar file into these subdirectories. Use GZIP to compress these TAR files, for example, the actual GCC 1.40 version of the release file called 'GCC-1.40.TAR.GZ'. The target disc will obviously rely on all published files that are not a source file, so you should make sure that these files in the release have been updated. See Creating a publishing file in GNU standard coding.

`check '

Execute self-inspection. Users should create programs before running, but do not have to be installed; you should write a self-test program, execute when the program has established but not installed. The following objectives are recommended to use habits, which are useful for various programs:

INSTALLCHECK

Execute self-inspection. Users should establish and install these programs before running tests. You don't have the hypothesis '$ (bindir)' in the search path.

INSTALLDIRS

Adding a named 'InstallDirs' target is useful for creating a directory to be installed and their parent catalogs is very useful. Script 'mkinstallDirs' is designed for this handle, you can find it in the TexInfo package, you can use the rules like this:

# Make sure all installation directories (such as $ (bindir))

#Nectime actually, if you don't create them.

InstallDIRS: MKinstallDirs

$ (srcdir) / MKinstallDIRS $ (BINDIR) $ (DATADIR) /

$ (libdir) $ (infodir) /

$ (MANDIR)

This rule does not change the catalog created when compiling, which only creates the installation directory.

14.6 Installing Command Category

Write installed targets, you must divide all commands into three categories: normal command, before installation command, post-installation command.

Under normal circumstances, the command moves the file to the appropriate place and sets them. They don't change any files, just extract them completely from the package.

The pre-installation command and post-installation command may change some files, such as the database file after editing the configuration file.

The pre-installation command is executed before the normal command, and the command will be executed after the normal command is executed.

The most common use after installation is to run the Install-Info program. This work cannot be done by the normal command because it changed a file (INFO directory), which is not all installed from the package separately. It is a post-installed command because it needs to be executed after the normal command is installed in the INFO file in the package.

Many programs do not need to install the command, but we offer this feature to use it when needed.

To divide the commands of the installation rule into three classes, you should insert the Category Lines in the middle of the command. The classification line specifies the category of the commands described below.

The classification line contains a Tab, a special MAKE variable reference, and a random comment on the row end. You can use three variables, each variable corresponds to a category; the variable name is specified. The classification line cannot appear in a normal execution file because these MAKE variables are defined by the normal definition (you should not be defined in the Makefile file).

There are three classification lines here, and the following comments explain its meaning:

$ (Pre_install) # The following is the pre-installation command

$ (Post_install) # The following is the post-installation command

$ (NORMAL_INSTALL) # 以下 below is normal command

If you don't use the classification line at the installation rule, all commands before the first classification line appear are normal commands. If you do not use any classification line, all commands are normal commands.

This is a counter-installation classification line

$ (Pre_uninstall) # 以下 below is the negative command command

$ (Post_uninstall) # 以下 below is the negative post

$ (NORMAL_UNINSTALL) # below is normal command

Typical usage of the pre-installation command is to delete all content from the info directory.

If the target install or UNINSTAL has a subroutine that relies on the installer, you should use the classification to start each dependent command, and then use the classification line to launch the main target command. Regardless of which relies on actual implementation, this approach ensures that each command is placed in the correct category.

Before installing command and post-installation commands, except for the following commands: 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 Sort TEE

Test Touch True Uname Xargs Yes

The reason for distinguishing between commands in this way is to create a binary package. Typical binary packages include all executable files, other files that must be installed, and its own installation files - so binary packages do not need to run any normal commands. However, the installation binary package needs to perform the pre-installation command and post-installation command.

The program for building a binary package is working by extracting the pre-installation command and post-installation command. Here is a method of extracting the pre-installation command:

Make -n install -o all /

Pre_install = pre-install /

Post_INSTALL = Post-Install /

NORMAL_INSTALL = NORMAL-INSTALL /

| Gawk -f pre-install.awk

Here the file 'pre-install.awk' may include:

$ 0 ~ / ^ / t [/ t] * (Normal_Install | Post_INSTALL) [/ T] * $ / {on = 0}

ON {Print $ 0}

$ 0 ~ / ^ / t [/ t] * pre_install [/ t] * $ / {= 1}

The result file of the previous command is executed like a part of the shell script that is installed in the installation binary package.

15 Quick reference

This is a summary of the orientation of the instruction, text operation function, and GNU Make understandable. For other summary, please refer to the special built-in target name, implied rule directory, and option.

Here is the gnu make is a summary of other instructions:

Define variable

Endef

Define multi-line recursive call extension variables. See the command to define the fixed order.

IFDef Variable

IFNDEF Variable

IFEQ (A, B)

IFEQ "a" "b"

IFEQ 'A' 'B'

IFNEQ (A, B)

IFNEQ "a" "b"

IFNEQ 'A' 'B'

Else

ENDIF

The condition extension in the Makefile file is reviews the conditional statement in the Makefile file.

Include file

-include file

Sinclude file

Contains other makefile files, see Contains Other Makefile files.

OVERRIDE VARIABLE = VALUE

OVERRIDE VARIABLE: = Value

OVERRIDE VARIABLE = Value

OVERRIDE VARIABLE? = VALUE

Override Define Variable

Endef

Define variables, overloaded for previous definitions, and overloading variables defined in the command line. See the Override instruction.

Export

Tell Make defaults all variables to the child process, see the variables with the subkey communication.

Export variable

Export variable = value

Export variable: = value

Export variable = Value

EXPORT VARIABLE? = VALUE

UNEXPORT VARIABLE

Tell MAKE to output a special variable to the sub-process. Participation with the messenger and subkey communication.

vPath Pattern Path

Develop a path to match the file in the '%' format. See the VPATH directive.

vPath Pattern

Remove all search paths previously specified for 'Pattern'.

vPath

Remove all search paths specified by the VPATH instruction.

Here is the summary of the operation text function, see the text conversion function:

$ (Subst from, To, Text)

In 'TO' in 'to' instead 'from', refer to the string replacement and analysis function.

$ (PatSubst Pattern, Replacement, Text)

Inside 'Replacement' instead of match the 'Pattern' word, see the string replacement and analysis functions.

$ (Strip String)

Transfer extra spaces from the string. See string replacement and analysis functions.

$ (Findstring Find, Text)

Determine the location of 'find' in 'Text'. See string replacement and analysis functions.

$ (Filter Pattern ..., Text)

Select the word match 'Pattern' in 'Text'. See string replacement and analysis functions.

$ (Filter-Out Pattern ..., Text)

Select the word that does not match 'Pattern' in 'Text'. See string replacement and analysis functions.

$ (Sort List)

Sort 'List' in alphabetical sequence and delete duplicate words. See string replacement and analysis functions.

$ (Dir Names ...)

Extract the path name from the file name. Refer to the file name function.

$ (Notdir Names ...)

The path portion is extracted from the file name. Refer to the file name function.

$ (SUFFIX NAMES ...)

The non-path portion is extracted from the file name. Refer to the file name function.

$ (BaseName Names ...)

Extract the basic file name from the file name. Refer to the file name function.

$ (Addsuffix SUFFIX, NAMES ...)

Add a suffix to each word in 'Names'. Refer to the file name function.

$ (AddPrefix Prefix, Names ...)

Add a prefix to each word in 'Names'. Refer to the file name function.

$ (Join List1, List2)

Connect two parallel words list. Refer to the file name function.

$ (Word N, Text)

Extract the nth word from 'Text'. Refer to the file name function.

$ (Words text)

Calculate the number of characters in 'text'. Refer to the file name function.

$ (WordList S, E, Text)

Returns the word between s to e in 'Text'. Refer to the file name function.

$ (Firstword Names ...)

The first word in 'Names ...'. Refer to the file name function.

$ (Wildcard Pattern ...)

Look for file names that match the shell file name format. See the Wildcard function.

$ (Error Text ...)

When the function is executed, the Make generates a fatal error that creates information is 'Text'. See Controlling the function of Make.

$ (WARNING TEX ...)

When the function is executed, the make generates a warning for 'Text'. See Controlling the function of Make.

$ (Shell Command)

Execute the shell command and return it. Refer to the function shell.

$ (Origin Variable)

Returns the definition information of the MAKE variable 'variable'. Refer to the function Origin.

$ (Foreach Var, Words, Text)

Put the words in the latter list in the list of words in the list list, put the result in the text. See the function foreach.

$ (Call Var, Param, ...)

Use $ (1), $ (2) ... to calculate the variable var, variable $ (1), $ (2) ... instead of parameter param first, second ... Refer to the function call.

Here is a summary of automatic variables, and complete descriptions are reviews automatic variables.

$ @ @ @ @ @ @

Target file name.

$%

When the goal is a member of the file, it indicates the target member name.

$

The first dependency name.

$?

All the names of the target 'new' are separated from spaces. For the dependence of the file, you can only use a named member. See Using Make to update file files.

$ ^

$

All dependencies, the names are separated from spaces. For the dependence of the file, you can only use a named member. See Using Make to update file files. Variable $ ^ omitted repeated dependence, and the variable $ is reserved according to the original order,

$ *

And the Stem (path) that matches the rule. See the format match.

$ (@D)

$ (@ F)

Variable $ @. The path part and the file name section.

$ (* D)

$ (* F)

The path part and the file name section of the variable $ *.

$ (% D)

$ (% F)

The path part and file name part of the variable.

$ (

$ (

Variable $

$ (^ D)

$ (^ F)

The path part and file name part of the variable $ ^.

$ ( D)

$ ( F)

Variable $ The path part and the file name section of the file.

$ (? D)

$ (? F)

The path part and file name part of the variable $?.

The following is GNU Make uses variables:

Makefiles

Makefiles file to be read each time you call Make. See Variable Makefiles.

VPath

The path to the file search that cannot be found in the current directory. See VPATH: All dependent search paths.

Shell

The system default command interpreted program name, usually `/ bin / sh '. You can set the value variable shell in the Makefile file to change the shell used by the running program. See the execution command.

Makeshell

The change amount is only used for the command interpretation name used by MS-DOS, make, which is prioritized by the value of the variable shell. See the execution command.

Make

Calling Make name. Use this variable in the command line to have special meaning. Refer to the Make Make Make.

MakeElevel

The number of layers (sub-makes) recursted. See the variables with the subkey communication.

Makeflags

Provide markers to make. You can use this variable setting flag in the environment or makefile file. See the variables with the subkey communication. This variable cannot be used directly in the command line, which should not be referenced in the shell in the shell, but always allows recursive call to the Make to pass to the subkey.

Makecmdgoals

This goal is to provide Make in the command line. Setting this variable There is no impact on the behavior of Make. Refer to the special goal parameters.

Curdir

Set the path name of the current work directory, see Cutting Make.

SUFFIXES

A list of suffixes before reading any Makefile file.

.Libpatterns

Define the library name of the Make search and search for the search. See the connection library search directory.

16 MAKE

Here you can see by Make produces most common error lists, as well as their meaning and correcting them.

Sometimes the error generated by Make is not fatal, such as the prefixed prefix in front of the command script, and the error generated in the case of the command line is almost not a fatal error. Use strings *** to make a fatal error.

The error message is used in front of the prefix. The prefix is ​​the result of generating an error or the error file name exists in the Makefile file and the line number and line number containing the error.

In the following error list, a normal prefix is ​​omitted:

`[foo] error nn '

`[foo] Signal Description '

These errors are not true Make errors. They means that the Make call is returned to a non-zero status value, error code (ERROR NN), this case Make is interpreted as a failure, or quit from normal mode (some type signals), see the command error. If there is no additional *** in the information, the sub-process failed, but this rule in the makefile file has a special prefix, so Make ignores the error. `missing separator. stop. '

`Missing Separator (Did You Mean Tab INSTEAD OF 8 spaces?). Stop. '

This means that Make encounters the content that cannot be understood when reading the command line. GNU make Checks a variety of separators (:, =, character tab, etc.) to help determine what type of errors in the command line. This means that Make can't find a legitimate separator. The most probable cause of this information is that you (perhaps your editor, most of the MS-Windows editor) In order to use spaces instead of characters Tab. In this case, MAKE will generate an error message using the second form described above. Keep in mind that any command line begins with character Tab, and eight spaces are not counted. See the syntax of the rule.

`Commands Commence First Target. Stop. '

`Missing rule before commands. stop. '

This means that in the Makefile, it seems to start with the command line: starting with Tab characters, but not a legal command line (for example, a variable assignment). Any command line must be linked to a certain goal. Generating a second error message is a line of first non-empty characters as a semicolon. The explanation of MAKE is that you miss the "target: prerequisite" section in the rule, see the syntax of the rule.

`No rule to make target` xxx '.'

`No rule to make target` xxx ', needed by `yyy'. '

This means that Make decides to create a goal, but you cannot find any instructions for creating this target in the Makefile file, including specific rules and implicit rules. If you want to create this goal, you need to write a rule for the change. Other reasons for this problem may be a Makefile file is a draft (such as file name) or destroy the source file tree (a file cannot be rebuilt according to planning, only due to a dependence).

`No targets specified and no makefile found. Stop. '

`No targets.. '

The former means that you do not provide the target to create the target to create, Make can't read any Makefile file. The latter means that some Makefile files are found, but they do not include default targets and command lines. GNU Make can do in this situation. See Specifying the parameters of the Makefile file.

`Makefile` xxx 'was not found.'

`Include makefile` xxx 'was not found.'

Specify a Makefile file (former) or the Makefile file (the latter) that is included in the command line.

`Warning: Overriding Commands for Target` xxx ''

`Warning: ignoring old commands for target` xxx ''

GNU Make allows commands that can only be used once in a rule (except for double colon rules). If you specify a command for a goal, this command is already defined, this warning will be generated; the second message indicates that the command will overwrite the settings of the previous command. See the goal with multiple rules.

`Circular XXX <- YYY Dependency Dropped. '

This means that Make detects a loop with each other: Discover the dependence on YYY depending on the dependence of YYY dependence on YYY.

`Recursive Variable` xxx 'References itself (eventually).

This means that you define a normal (recursive call) Make variable XXX, which will reference it when it extends. This is not allowed regardless of a simple extension variable (: =) or additional definition ( =), this is not allowed, see the use variable.

`Unterminated variable reference. Stop. '

This means that you forget to write the right brackets when you call the variable reference or function.

`insufficient arguments to function` xxx '. stop.'

This means that you are calling a function to provide you with a number of parameters. See the text conversion function for a detailed description of the function parameters.

`Missing Target Pattern. Stop. '

`Multiple Target Patterns. stop. '

`Target Pattern Contains No` '. Stop.'

These error messages are caused by the static format rules of the deformed. The first article means that there is no rule in the target part of the rules, which means that there are several rules in the target part, and the third article means that there is no format%. See the static format rule syntax.

`Warning: -jn forced in submake: disable job jobserver mode. '

This warning and the lower warning is an error that contains parallel processing in the system that can communicate with the sub-Make (see with the sub-Make communication option). This warning message is if recursive calls an MAKE process, but also uses the '-JN' option (here is greater than 1). This situation is likely to happen, for example, if you set the environment variable Make is 'Make -J2'. In this case, subkey cannot communicate with other MAKE procedures, but also simply pretend that it is made of two tasks.

`Warning: JobServer Unavailable: using -j1. add` 'to parent make rule.'

In order to ensure communication between the MAKE process, the parent layer MAKE will pass the information to the subkey. This can result in problems because the child process may not be an actual MAKE, while the parent process only believes that the sub-process is a MAKE to pass all information to the child process. The parent process is to determine these (see variable Make's working mode) using normal algorithms. If the Makefile file builds such a parent, it doesn't know if the child process is Make, then the child process will reject the information that is useless. In this case, the sub-process will generate this warning message and then processed in the order in which it built.

17 complex Makfile file example

This is a Makefile file for the GNU TAR program; this is a medium complex Makefile file. Because 'all' is the first goal, it is the default target. This makefile file is a interesting place to 'TestPad.h' is a source file created by the TestPad program, and the program is compiled by 'TestPad.c'.

If you type 'make' or `make all ', Make creates a process' RMT', and the INFO file named 'tar.info', which is named the 'Tar.info'.

If you type 'make install', Make not only creates 'Tar', 'RMT', and 'Tar.info' and installs them.

If you type 'make clean', make deletes all '.o' files, and 'Tar', 'RMT', 'TestPad', 'TestPad.h', and 'Core' files.

If you type 'make distclean', Make not only deletes all files deleted, but also includes file 'tags', 'Makefile', and 'config.status' files. (Although it is not obvious, this makefile (and 'config.status') is generated by the user with the configure program, which is provided by the published tar file, but not explained here.)

If you type 'make realclean', make deletes all files deleted by 'make distclean' and include the info file generated by 'tar.texinfo'.

In addition, target Shar and distth have created the core of the release file.

# Automatically generate from makefile.in

# Unix makefile for GNU TAR programs

# Copyright (c) 1991 Free Software Foundation, Inc.

# This program is free software; in the case of the GNU terms

# You can re-release it or change it

# 普通 public license ...

...

...

Shell = / bin / sh

#### Start system configuration section ####

Srcdir =.

# If you use GCC, you should run

# And it creates a fixed script program and

# Use the -traditional option to run the GCC in the middle of the GCC.

# Diuni IOCTL calls cannot be compiled correctly on some systems

CC = GCC -O

Yacc = bison -y

INSTALL = / usr / local / bin / install -c

InstallData = / usr / local / bin / install -c-m 644

# You should add content to DEFS:

# -Dstdc_headers If you have a standard C header file and

# Library file.

# -Dposix If you have the header file of POSIX.1 and

# Library file.

# -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 Control Functions

# 和 文件 文件, sys / sysmacros.h, # fcntl.h, getcwd, no valloc,

# And ndir.h (unless

# You use -ddream).

# -DNO_MEMORY_H If USG or STDC_HEADERS but not

# Including Memory.h.

# -Ddream If USG and you use Dirent.h

# Instead ndir.h.

# -Dsigtype = int if your signal controller

# Return int, non-void.

# -Dno_mtio If you miss sys / mtio.h

# (Magtape IOCTLS).

# -Dno_remote If you don't have a remote shell

# Or rexec.

# -Duse_rexec uses REXEC for remote tape

# 操作 操作 代

# Branch RSH or REMSH.

# -Dvprintf_missing If you miss the function vprintf

# (But there is _doprnt).

# -Ddoprnt_missing If you miss the function_doprnt.

# 同样 定 需要

# -Dvprintf_missing.

# -Dftime_missing If you miss the system call ftime

# -Dstrstr_missing If you miss the function strstr.

# -Dvalloc_missing If you miss the function Valloc.

# -Dmkdir_missing If you miss system call MKDIR and

# Rmdir.

# -Drename_missing If you miss the system call rename.

# -Dftruncate_missing If you lack the system call ftruncate.

#

# -Dv7 in UNIX version 7 (no

# For a long time test).

# -Demul_open3 If you miss 3-parameter versions

# Open, and want to call through your system

# Simulation it.

# -Dno_open3 If you miss 3-parameter version of Open

# And to disable TAR -K options

# Instead simulation open.

# -Dxenix if you have sys / inode.h

# And need it to include 94

DEFS = -dsigtype = int -ddirent -dstrstr_missing /

-Dvprintf_missing -dbsd42

# Set to Rtapelib.o, unless it is empty

# You define no_remote,

Rtapelib = rtapelib.o

Libs =

DEF_AR_FILE = / dev / rmt8

DEFBLOCKING = 20cdebug = -g

CFLAGS = $ (CDEBUG) -i. -I $ (srcdir) $ (DEFS) /

-DDEF_AR_FILE = / "$ (Def_ar_file) /" /

-Ddefblocking = $ (Defblocking)

LDFLAGS = -g

prefix = / usr / local

# Each installer prefix.

#. Normal empty or `g '.

Binprefix =

# Install the path to TAR

Bindir = $ (prefix) / bin

# Install the path to the INFO file.

Infodir = $ (Prefix) / Info

#### System configuration end section ####

Src1 = tar.c create.c extract.c buffer.c /

GetOldopt.c update.c gnu.c mangle.c

SRC2 = Version.c List.c names.c Diffarch.c /

Port.c wildmat.c getopt.c

SRC3 = getopt1.c regex.c getdate.y

SRCS = $ (SRC1) $ (src2) $ (src3)

Obj1 = tar.o crete.o extract.o buffer.o /

Getoldopt.o update.o gnu.o mangle.o

Obj2 = Version.o List.o names.o diffarch.o /

Port.o wildmat.o getopt.o

Obj3 = getopt1.o regex.o getdate.o $ (rtapelib)

Objs = $ (OBJ1) $ (OBJ2) $ (OBJ3)

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 rtrapelib.c alloca.c /

MSD_DIR.H msd_dir.c tcexparg.c /

Level-0 Level-1 Backup-Specs TestPad.c

All: Tar RMT tar.info

TAR: $ (OBJS)

$ (CC) $ (LDFLAGS) -O $ @ $ (oJS) $ (libs)

RMT: RMT.C

$ (CC) $ (CFLAGS) $ (LDFLAGS) -O $ @ RMT.c

Tar.info: tar.texinfo

Makeinfo tar.texinfo

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 transformations / reducing conflicts.

TestPad.h: TestPad

./testpad

Testpad: TestPad.o

$ (Cc) -o $ @ TestPad.o

Tags: $ (srcs)

ETAGS $ (SRCS)

Clean:

RM -F * .o TAR RMT TestPad TestPad.h Core

Distclean: Clean

Rm -f tags makefile config.status

Realclean: distclean

Rm -f tar.info *

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

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 $$; /

SED 'S / $$ / ^ m /' $$ X /

> TMP.DIR / $$ X; DONE

CD tmp.dir; zoo am ../tar.zoo *

-RM-RF TMP.DIR

footnote

(1)

GNU Make compiled for MS-DOS and MS-Windows and the prefix is ​​the same as the root of the DJGPP tree system.

(2)

On MS-DOS, the value of the current working directory is Global, so changing it will affect the subsequent command lines in these systems.

(3)

TEXI2DVI uses Tex to real formatting work. Tex is not published with TexInfo.

This document uses version 1.54 TEXI2HTML translator to be generated on July 19, 2000.

All rights reserved for this document are not allowed for any business behavior.

Name translation comparison table

Archive file

Archive Member Targets File Members

ARGUMENTS OF FUNCTIONS function parameters

Automatic variables auto variable

Backslash (/) backslash

Basename basic file name

Binary packages binary bag

Compatibility compatibility

Data Base database

Default Directries Default Directory

Default Goal Default Final Goal

Defining Variables Verbatim defines multi-line variables

Directive Directive Dummy Pattern Rule Pseudo Formulation Rule

echoing of commands command back

Editor editor

Empty commands empty command

EMPTY TARGETS empty target

Environment Environment

Explicit Rule Specific Rule

FILE Name Functions File Name Function

File Name Suffix file name suffix

Flags logo

Features of the Flavors of Variables variable

Functions function

Goal ultimate goal

Implicit rule implicit rules

INCOMPATIBILITIES does not compatibility

Intermediate file in Intermediate Files

Match-anything rule multimetric rules

Options option

Parallel Execution Parallel Execution

Pattern Rule Format Rule

Phony targets imaginary goals

Prefix prefix

Prerequisite

Recompilation recompile

Rule rules

Shell command shell command

Static Pattern Rule Static Format Rule

STEM path

SUB-MAKE MAKE

Subdirectories subdirectory

Suffix suffix suffix rule suffix rule

Switch switch

Target target

Value value

Variable variable

Wildcard wildcard

Word word

转载请注明原文地址:https://www.9cbs.com/read-39095.html

New Post(0)