Makefile implied rules

implied Rules
————

When we use makefile, there are some things we will use very often, and the use of very high frequency, for example, we compile the source program C/s + + for intermediate target files (Unix is [. o] File, under Windows is [. obj] file). This chapter deals with some of the "hidden", previously agreed upon makefile rules that we do not need to write again.

The "implied rule" is also a convention in which make will run in a manner that is "customary", fearing that no such rule is written in our makefile. For example, if you compile the [. c] File into the [. O] File, you don't have to write it, and make automatically deduces the rule and generates the [. o] File we need.

"Implied rules" use some of our system variables, and we can change the values of these system variables to customize the runtime parameters of the implied rules. such as the system variable "CFLAGS" can control compile-time compiler parameters.

We can also write down our own implicit rules by means of "pattern rules". There are a number of limitations to defining implied rules with the suffix rule. The use of "pattern rules" is more intelligent and clear, but "suffix rules" can be used to guarantee our makefile compatibility.
We understand the "hidden rules" that can make them better for us and will let us know something that is "conventional," rather than making us run makefile with something that we find baffling. Of course, anything is contradictory, water can carry a boat, but also overturn it, so, sometimes "hidden rules" will give us a little trouble. Only by understanding it can we use it better.

I. Use of implicit rules

If you want to use implicit rules to generate the goals you want, all you need to do is not write the rules for this goal. So, make will try to automatically derive the rules and commands that produce this goal, and if make can automatically deduce the rules and commands that generate the target, then this behavior is the automatic derivation of the implied rules. The implicit rule, of course, is something that make is agreed on in advance. For example, we have one of the following makefile:

foo:foo.o bar.o
cc –o foo foo.o bar.o $ (CFLAGS) $ (ldflags)

We can note that this makefile does not write down the rules and commands for how to generate the two goals of FOO.O and BAR.O. Because the "implied rules" feature of make automatically automatically infers the dependent targets and build commands for these two targets.

Make will look for available rules in its own "hidden rules" library, and if found, it will be used. If you can't find it, you'll get an error. In the example above, the implicit rule of make invocation is to place the dependent file [. c] of the target of [. O] and use the C's compile command "cc–c$ (CFLAGS) [. c]" to generate the [. O] Target. In other words, we have absolutely no need 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 "convention" good thing, make and we agreed to use the C compiler "CC" to generate the [. O] File rules, this is the implied rule.

Of course, if we write our own rules for the [. O] File, then make does not automatically deduce and invoke the implied rules, which are faithfully executed according to the rules we have written.

Also, in the "Hidden Rules library" of make, each implied rule has its order in the library, and the more forward it is, the more often it is used, so this will cause us to have some time even if we specify the target dependency, and make does not control. As in the following rule (no command):

foo.o:foo.p

Depending on the file "FOO.P" (the Pascal program's source file) may become meaningless. If the "foo.c" file exists under the directory, then our implied rules will take effect, and the foo.o file will be generated by the compiler of "FOO.C" Call C. Because, in the implied rules, Pascal's rules appear after the C rule, so make finds the rule that generates FOO.O C and no longer looks for the next rule. If you do not want any implied rules to be deduced, then you should not write only "dependent rules" without writing commands.

Ii. List of implied rules

Here we'll cover all the implicit rules of pre-Setup (that is, make built-in), and if we don't explicitly write the rules, then make will look for the rules and commands that are needed in these rules. Of course, we can also use make's parameter "-R" or "–no-builtin-rules" option to cancel all pre-set implied rules.

Of course, even if we specify the "-r" parameter, some implied rules will take effect, since there are many implied rules that are defined using the "suffix rule", so long as there is a "suffix list" in the implied rule (and a system is defined on the target.) suffixes), then the implied rules will take effect. The default list of suffixes is:. Out,. A,. LN,. O,. C,. CC,. C,. P,. F,. F,. R,. Y,. L,. S,. S,.mod,. Sym,. def,. h,. info,. DVI,. Tex,. Texinfo,. Texi,. TXINFO,.W,. Ch. Web,. SH,. ELC,. El. We will tell you the details in detail later.

Let's take a look at the usual hidden rules.

1. Compile the implicit rules of C program.
The target dependent target of "<N>.O" is automatically deduced as "<N>.C" and its generated command is "$ (CC) –c $ (cppflags) $ (CFLAGS)"

2. Compile the implicit rules of C + + program.
The target of "<N>.O" will be automatically deduced as "<n>.cc" or "<n>". C "and its build command is" $ (CXX) –c $ (cppflags) $ (CFLAGS) ". (". CC" is recommended as the suffix of the C + + source file instead of ". C ")

3. Compile the implied rules of Pascal program.
The target dependent target of "<N>.O" is automatically deduced as "<N>.P" and its generated command is "$ (PC) –c $ (pflags)".

4, compile the Fortran/ratfor program of the implicit rules.
The target of "<N>.O" is automatically deduced as "<N>.R" or "<n>". F "or" <N>.F ", and its generated commands are:
". F" "$ (FC) –c $ (fflags)"
" . F " " $ (FC) –c $ (fflags) $ (cppflags) "
". F" "$ (FC) –c $ (fflags) $ (rflags)"

5, pre-processing Fortran/ratfor program implicit rules.
The target of "<N>.F" is automatically deduced as "<N>.R" or "<n>". F ". This rule simply converts ratfor or has a pre-processed FORTRAN program to a standard FORTRAN program. The commands it uses are:
" . F " " $ (FC) –F $ (cppflags) $ (fflags) "
". R" "$ (FC) –F $ (fflags) $ (rflags)"

6, compile the Modula-2 program of the implicit rules.
The target dependent target for "<n>.sym" is automatically deduced as "<n>.def" and its generated command is: "$ (M2C) $ (m2flags) $ (defflags)". The target target of "<n.o>" is automatically deduced as "<n>.mod", and its generated command is: "$ (M2C) $ (m2flags) $ (modflags)".

7, compilation and compilation of the implicit rules of preprocessing.
The target target of "<N>.O" is automatically deduced as "<n>.s", using the compiled product "as" by default, and its generated command is "$ (AS) $ (asflags)". The target of "<n>.s" is automatically deduced as "<N>". S ", the C pre-compiler" CPP "is used by default, and its build command is:" $ (AS) $ (asflags) ".

8. Link the implicit rules of the object file.
The "<n>" target relies on "<N>.O" to run the linker generation (typically "LD") by running the C compiler, whose generated command is: "$ (CC) $ (ldflags) <N>.O $ (loadlibes) $ ( Ldlibs) ". This rule is valid for projects with only one source file, and also for multiple object files (generated by different source files). For example, the following rules:

x:y.o Z.O

And when both "x.c", "y.c", and "z.c" are present, the implied rule executes the following command:

cc-c x.c-o x.o
cc-c y.c-oy.o
cc-c z.c-oz.o
cc X.O y.oz.o-o x
rm-fx.o
rm-fy.o
rm-fz.o

If you don't have a source file (such as x.c in the previous example) associated with your target name (as in the example above), then you'd better write your own build rule, or the implied rule will report an error.

9, YACCC program when the implied rules.
The dependent file for "<n>.c" is automatically deduced as "N.Y" (the YACC generated file) and its generated command is: "$ (YACC) $ (YFALGS)". ("Yacc" is a parser, for details please see the relevant information)

10, Lex C program when the implied rules.
The dependent file for "<n>.c" is automatically deduced as "N.L" (the lex-generated file) and its generated command is: "$ (Lex) $ (LFALGS)". (For details on "Lex", please refer to the relevant information)

11, Lex ratfor Program when the implicit rules.
The dependent file for "<N>.R" is automatically deduced as "N.L" (the lex-generated file) and its generated command is: "$ (Lex) $ (LFALGS)".

12. Create an implicit rule for the lint library from a C program, a YACC file, or a lex file.
The dependent file for "<n>.ln" (LINT generated file) is automatically deduced as "N.C" and its generated command is: "$ (LINT) $ (LINTFALGS) $ (cppflags)-i". The same rules apply to "<n>.y" and "<N>.L".

Iii. variables used by implied rules

In the commands in the implied rules, some of the pre-set variables are basically used. You can change the values of these variables in your makefile, either by passing them on the command line of make, or by setting them in your environment variables, however, if you set these specific variables, they will work on the implied rules. Of course, you can also use Make's "-R" or "–no–builtin-variables" parameters to cancel the effect of the variables you define on the implied rules.

For example, the first implied rule--the command to compile an implied rule for a C program is "$ (CC) –c $ (CFLAGS) $ (cppflags)". Make the default compile command is "CC", if you redefine the variable "$ (cc)" to "GCC", the variable "$ (CFLAGS)" is redefined as "-G", then the implied rules of the command will be "Gcc–c-g $ (cppflags)" In the appearance of the execution.

We can divide the variables used in the implied rules into two kinds: one is command-related, such as "CC", and the other is the close of the parameter phase, such as "CFLAGS". Here are the variables that are used in all implied rules:

1, about the variables of the command.

Ar
function Library Packager. The default command is "AR".
As
Assembly language Compiler program. The default command is "as".
Cc
C language Compiler program. The default command is "CC".
CXX
C + + language compiler program. The default command is "g++".
CO
Extend the file program from the RCS file. The default command is "CO".
Cpp
C program's preprocessor (output is standard output device). The default command is "$ (CC) –E".
Fc
Fortran and Ratfor compilers and pre-processing programs. The default command is "F77".
GET
The program that extends the file from the SCCs file. The default command is "get".
LEX
Lex Method Parser Program (for C or ratfor). The default command is "Lex".
Pc
Pascal language Compiler program. The default command is "PC".
Yacc
YACC Grammar Analyzer (for C programs). The default command is "YACC".
Yaccr
YACC Grammar Analyzer (for ratfor programs). The default command is "Yacc–r".
Makeinfo
Convert texinfo source file (. texi) to info file program. The default command is "Makeinfo".
TEX
A program that creates a Texdvi file from a Tex source file. The default command is "Tex".
Texi2dvi
Create an Army Tex DVI file from the Texinfo source file program. The default command is "Texi2dvi".
WEAVE
Convert the Web to Tex program. The default command is "weave".
Cweave
Convert the C WEB to Tex program. The default command is "Cweave".
Tangle
Convert the Web to Pascal language program. The default command is "Tangle".
Ctangle
Convert c Web to C. The default command is "Ctangle".
Rm
The delete file command. The default command is "Rm–f".

2. Variables for command parameters

The following variables are all parameters related to the command above. If the default value is not specified, the default value is null.

Arflags
parameters of the function Library Packager ar command. The default value is "rv".
Asflags
assembly language compiler parameters. (when obviously called ". S" or ". S "file).
CFLAGS
C language compiler parameters.
Cxxflags
C + + language compiler parameters.
Coflags
RCS command parameters.
Cppflags
C preprocessor parameters. (The C and Fortran compilers are also used).
Fflags
Fortran language compiler parameters.
GFLAGS
SCCS "Get" program parameters.
Ldflags
linker parameters. (eg: "LD")
Lflags
Lex Grammar parser parameter.
Pflags
Pascal Language compiler parameter.
Rflags
The Fortran compiler parameter for the ratfor program.
Yflags
YACC Grammar Analyzer parameters.

Iv. chain of implied rules

Sometimes, a goal may be a series of implicit rules to the effect. For example, a [. O] File generation may be preceded by the [. Y] File First YACC [. c] and then generated by the C compiler. We call this series of implicit rules "chain of implied rules".

In the example above, if the file [. c] exists, then the implicit rule of C's compiler is called directly, if there is no [. c] File, but there is a [. y] File, then the implied rule of YACC is called, the [. c] File is generated, and then the implicit rule of C compilation is eventually generated [. O] ] file to reach the target.

We call this [. c] File (or target) the intermediate target. In any case, make will try to automatically deduce all the methods of generating the target, regardless of the number of intermediate goals, it will persist in all the implied rules and the rules you write all together to analyze and strive to achieve the goal, so, sometimes it may make you feel strange, how my goal will be generated? Why is my makefile crazy?

By default, for intermediate targets, it differs from the general target in two places: the first difference is that the intermediate rule is raised unless the intermediate target does not exist. The second difference is that, as long as the goal is successful, the resulting intermediate target file is deleted as "Rm-f" when the final target is produced.

Typically, a file that is designated as a target or dependent by makefile cannot be used as an intermediary. However, you can clearly state that a file or target is an intermediary target, and you can use pseudo-target ". Intermediate "to enforce the declaration. (such as:. INTERMEDIATE:MID)

You can also prevent make from automatically deleting intermediate targets, and to do this you can use pseudo targets. " Secondary "to enforce the declaration (for example:. SECONDARY:SEC). You can also put your goals in a pattern way to specify (eg:%.O) into pseudo-targets ". Precious "To save the intermediate file generated by the implied rule.

In the chain of implied rules, it is forbidden to show the same target two or more times, or more than two times, which prevents infinite recursion when make is automatically deduced.

Make optimizes some special implicit rules without generating intermediate files. For example, from the file "foo.c" to generate the target program "Foo", according to the truth, make will compile to generate intermediate file "FOO.O", and then link to "foo", but in practice, this action can be a "CC" command to complete (cc–o foo FOO.C), then the optimized rule will not generate intermediate files.

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

Makefile implied rules