Write Makefile with me (12)

Implied rules ----

When we use makefile, there are some frequent uses, and use frequent frequencies. For example, we compile the C / C source program as an intermediate target file (UNIX is [.o] file, Windows is [. OBJ] file). This chapter tells some "implied" in makefile, earlier, no need to write the rules.

"Implied rules" is also a practice. Make will run according to this "convention" heart, even if there is no writing rules in our makefile. For example, compiling the [.c] file into the rule of [.o] file, you don't have to write it all, make it automatically derived this rule and generates the [.o] file we need.

The "Implied Rule" will use some of our system variables, we can change the value of these system variables to customize the parameters of the rules of the rules. If the system variable "cflags" can control compiler parameters when compiling.

We can also write down your implicit rules through the Mode Rules. There will be many restrictions with "Suffix Rules" to define implicit rules. Using Mode Rules will be more intelligent and clear, but the Suffix Rules can be used to ensure our makefile compatibility. We understand the "implicit rules", allowing us to better serve us, will let us know something "convention and customary", and not so that we feel inexplicable when we are running Makefile. Of course, anything is contradictory, water can be boat, can also come to the boat, so sometimes the "implied rules" will also cause non-small troubles. Only by knowing it, we can use it better.

First, use implied rules If you want to use an implicit rule to generate the goals you need, you need to do this is not to write the rules of this goal. So, make attempts to automatically derive the rules and commands that generate this goal. If Make can automatically derive the rules and commands of this goal, then this behavior is the automatic derivation of implicit rules. Of course, the implicit rules are some things that make prior approximately. For example, we have a Makefile below:

Foo: foo.o bar.o cc -o foo foo.o bar.o $ (cflags) $ (ldflags)

We can notice that this makefile has not written on how to generate rules and commands for both objects of foo.o and bar.o. Because Make's "Implied Rule" feature automatically automatically derives the dependence targets and generation commands of these two goals.

Make will find the rules that can be used in your own Implicit Rules library. If you find it, you will use it. If you can't find it, you will report it wrong. In the example above, the implied rule called for the Make call is to set the dependency file of [.o] to [.c], and use C Compile command "CC -C $ (cflags) [.c] "To generate the goal of [.o]. In other words, we don't have to write down the following two rules:

FOO.O: FOO.C CC -C foo.c $ (cflags) bar.o: bar.c cc -c bar.c $ (cflags)

Because this is already a "agreement", make and us set up the rules of the "CC" to generate the [.o] file with the CC ", which is implicit rules.

Of course, if we write your own rules for the [.o] file, Make will not automatically derive and call the implicit rules, which will be faithfully executed in accordance with our write.

Also, in the "implied rules library" of Make, each implied rule has its order in the library, the more often used, so this will cause us to show us even if we show The target dependence is specified, and MAKE will not be tubed. As of this rule (no command): foo.o: foo.p

Relying on the file "foo.p" (source file of the Pascal program) may become meaningless. If there is a "foo.c" file in the directory, then our implicit rules will take effect, and will generate a foo.o file through the compiler of C. Because, in the implicit rule, the rule of PASCAL appears after the rule of C, so Make finds the rules that can generate foo.o will no longer look for the next rule. If you really don't want any implicit rules to derive, then you don't just write the "dependency rules" without writing the command.

Second, the implicit rule list here We will tell all the implicit rules of all pre-set (which is Make built). If we don't know the rules, Make will find the required rules and commands in these rules. Of course, we can also use Make's parameters "-r" or "--no-builtin-rules" option to cancel all pre-set implicit rules.

Of course, even if we specify the "-r" parameter, some implicit rules will take effect, because there are many implicit rules that use the Suix Rules to define, so as long as there is implicit rules Suffix List (also defined in the target .Suffixes dependent target), the implicit rules will take effect. 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. For details, we will talk later.

Still let's take a look at the common implicit rules.

1. Compile the implied rules of the C program. The dependent target of " .o" is automatically derived to " .c", and its generation command is "$ (cc) -c $ (cppflags) $ (cflags)"

2, compile the implicit rules for C programs. The dependent target of " .o" is automatically derived as " .cc" or " .c", and its generation command is "$ (cxx) -c $ (cppflags) $ (Cflags). (It is recommended to use ".cc" as a suffix of C source files, not ".c")

3, compile the implicit rules for the PASCAL program. The dependent target of " .o" is automatically derived as " .p", and its generation command is "$ (pc) -c $ (pflags)".

4, compile the implicit rules for the Fortran / RatFor program. The dependent target of " .o" is automatically derived as " .r" or " .f" or " .f", and its generation command is: ".f" "$ (Fc) -c $ (fflags)" ".f" "$ (fc) -c $ (fflags) $ (cppflags)" ".f" $ (fc) -c $ (fflags) $ (RFlags) ) "

5, preprocess the implicit rules for the Fortran / RatFor program. The dependent target of " .f" is automatically derived to " .r" or " .f". This rule is just converting the Ratfor or has a pre-processed Fortran program to a standard Fortran program. The commands used are: ".f" "$ (fc) -f $ (cppflags) $ (fflags)" ".r" "$ (fc) -f $ (fflags) $ (rflags)" 6, compile MODULA The implicit rules of the program. The dependent target of " .sym" is automatically derived as " .def", and its generation command is: "$ (M2C) $ (m2flags) $ (deffflags)." The dependent target of "" is automatically derived as " .mod", and its generation command is: "$ (M2C) $ (M2FLAGS) $ (MODFLAGS)."

7, assembly and assembly pre-processing implicit rules. The dependent target of " .o" is automatically derived as " .s", the default use of the compilation "AS", and its generation command is: "$ (as) $ (asflags)". The dependent objective of " .s" will be automatically derived as " .s", the default uses C precompiled translator "CPP", and its generation command is: "$ (as) $ (asflags)" .

8, link the implicit rules for the Object file. "" target depends on " .o", running the linker generation by running the C's compiler (generally "LD"), which generates commands: "$ (cc) $ (ldflags) < n> .o $ (LOADLIBES) $ (LDLIBS). This rule is valid for only one source file project, but also valid for multiple Object files (generated by different source files). For example, the following rules:

x: y.o z.o

And "x.c", "y.c" and "z.c" exist, the implicit rule will execute the following command:

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

If there is no source file (such as X.c in the above example) and your target name (as X) in the above example, you'd better write your own generation rules, otherwise, implicit rules will report an error.

9. Implicit rules when YACC C procedures. " .c" dependent file is automatically derived as "n.y" (YACC generated file), and its generation command is: "$ (YACC) $ (YFALGS)". ("YACC" is a syntax analyzer, please check the relevant information about its details)

10. Implicit rules when Lex C procedures. " .c" dependent file is automatically derived to "N.L" (LEX generated file), which generates commands: "$ (lex) $ (lfalgs)". (For details on "lex", please check the relevant information)

11. Implicit rules when Lex RatFor programs. " .r" dependent file is automatically derived as "N.L" (LEX generated file), and its generation command is: "$ (lex) $ (lfalgs)". 12. Create an implicit rules for the LINT library from the C program, YACC file or LEX file. The dependencies of " .ln" (LINT generated file) are automatically derived to "N.c", which generates commands: "$ (LINTFALGS) $ (cppflags) -i". The same rule is also the same for " .y" and " .l". Third, the variables used by the implicit rules are basically used in the commands in the implicit rules, basically use some pre-set variables. You can change these variables in your makefile, or incorporate these values ​​in the command line of make, or set these values ​​in your environment variable, no matter how, just set these specific variables, Then it will work for implicit rules. Of course, you can also use Make's "-r" or "--no-builtin-variables" parameter to cancel the role of the variable you defined on the implicit rule.

For example, the first implicit rule-compiling the implied rule of the C program is "$ (cc) -c $ (cflags) $ (cppflags). Make default compile command is "CC", if you redefine the variable "$ (cc)" to "GCC", turn the variable "$ (cflags)" to "-g", then implicit rules The command will be executed in "GCC -C -G $ (cppflags).

We can divide the variables used in the implicit rules into two: one is a command, such as "CC"; one is the parameter phase, such as "cflags". Below is the variables used in all implicit rules:

1. The variables of the command.

AR function library package program. The default command is "ar". AS assembly language compiler. The default command is "AS". CC C language compiler. The default command is "CC". CXX C language compiler. The default command is "G ". CO expands the file program from the RCS file. The default command is "CO". The preprocessor of the CPP C program (output is a standard output device). The default command is "$ (cc) -e". FC FORTRAN and RATFOR compiler and pre-processes. The default command is "F77". GET extension files from the SCCS file. The default command is "get". Lex Lex method analyzer program (for C or Ratfor). The default command is "lex". PC Pascal language compiler. The default command is "PC". YACC YACC Grammar Analyzer (for C procedures). The default command is "YACC". Yaccr Yacc Grammar Analyzer (for the Ratfor program). The default command is "Yacc -R". MakeInfo converts the TexInfo source file (.TEXI) to the INFO file program. The default command is "makeinfo". Tex creates a program from the Tex DVI file from the TEX source file. The default command is "tex". Texi2DVI creates a program from the TexInfo source file to create an army TEX DVI file. The default command is "texi2dvi". Weave converts web to tex program. The default command is "weave". CWEAVE converts C Web to TEX program. The default command is "CWEAVE". Tangle converts the web to the Pascal language program. The default command is "tangle". Ctangle converts C Web to C. The default command is "ctangle". RM deletes the file command. The default command is "RM -F".

2. These variables below the command parameters are the parameters of the relevant order. If there is no default value, its default value is empty. Arflags Function Library Package Ar Command Parameters. The default is "RV". Asflags assembly language compiler parameters. (When ".s" or ".s" file is displayed clearly). CFLAGS C language compiler parameters. CXXFLAGS C language compiler parameters. COFLAGS RCS command parameters. CPPFLAGS C Preprocessor parameters. (C and Fortran compilers are also used). FFlags Fortran language compiler parameters. GFLAGS SCCS "Get" program parameters. LDFLAGS linker parameters. (Such as "LD") LFLAGS LEX Grammar Analyzer Parameters. Pflags Pascal language compiler parameters. The Fortran compiler parameter of the RFLAGS Ratfor program. YFLAGS YACC Grammar Analyzer Parameters. Fourth, the implicit rules chain sometimes, one goal may be rooted by a series of implicit rules. For example, an [.o] file generation may be first included with the [.y] file of YACC first [.c], then generate it again by the compiler of C. We call this series of implicit rules "implicit rules chain".

In the above example, if the file [.c] exists, then directly call the implied rules of the compiler, if there is no [.c] file, but there is a [.y] file, then YACC implicit rules Will be called, generate the [.c] file, then call the impact rules for C-compilation ultimately by [.c] to generate the [.o] file to achieve the goal.

We call this [.c] file (or target) called an intermediate goal. Anyway, Make will work hard to automatically derive all methods of generating the goals, regardless of the intermediate targets, they will take all implicit rules and the rules you write, and try to achieve goals, so sometimes May make you feel strange, how do my goal be generated? How is my makefile be crazy?

By default, there are two places in the intermediate target, it is different from the general goals: the first difference is that the intermediate rule is triggered unless the intermediate target does not exist. The second difference is that as long as the target is successful, then the resulting intermediate target file will be deleted in "RM -F" during the final goal.

Typically, a file that is specified by Makefile to target or dependent the target cannot be treated as an intermediary. However, you can clearly illustrate a file or a target is an intermediary target, you can use pseudo-target ". InterMediate" to force the declaration. (Such as: .intermediate: MID)

You can also prevent Make from automatically deleting intermediate targets. To do this, you can use pseudo-target ". Secondary" to force statements (such as: .secondary: sec). You can also specify your goals to specify (eg:%. O) into the target ".precious" dependent object to save the intermediate file generated by the implicit rule.

In the "Implied Rules Chain", it is forbidden to appear twice or more, so that in order to prevent unlimited recursive conditions when Make is automatically derived.

Make will optimize some special implicit rules without generating an intermediate file. For example, from the file "foo.c" to generate the target program "foo", according to the truth, make it compiles the generation of the intermediate file "foo.o", then links into "foo", but in actual conditions, this action can be by one The "cc" command is completed (cc -o foo foo.c), so optimized rules will not generate an intermediate file. <- Previous Next->

(All rights reserved, please indicate the author and the source when reproduced)