1151_ Makefile learning_ Static matching pattern rules in makefile

    All learning summary ： https://github.com/GreyZhang/g_makefile

    About this part, I wanted to look at the examples first , After consulting some materials, I think it is more appropriate to start from the document itself .

    First take a look at this section of the document , Several useful knowledge summaries can be sorted out from this document .1, First, pay attention to the basic syntax format of this usage and the specific functions of each part , This paper makes a summary of the function of this expression form ： Each target that matches the target pattern is extracted as part of the name , This part is called stem, take stem Replace with each dependency match to derive the dependency file .2, Each matching pattern usually contains only one %, If it is used to deal with target,% Can be used to match any part of a name , But not % The winning part should match 100% .3, Except for 1 The replacement rules summarized in , There is another possibility ： There is no in the dependency rule %, So all of target All the dependent files are the same . This expression is still legal .4, If you want to match in the matching pattern % character , You can add one \ Realization . If not \% Is parsed into % The symbol itself can be used as a match \\%. however , This is not to say \\ yes \ Escape usage of , If you want to use two \ Direct input \\ that will do .

    Let's take a few examples .

CC := gcc

objects = foo.o bar.o all.o

all: $(objects)

# These files compile via implicit rules

foo.o: foo.c

bar.o: bar.c

all.o: all.c

all.c:

    echo "int main() { return 0; }" > all.c

%.c:

    touch [email protected]

clean:

    rm -f *.c *.o all

    First , This is an expression pattern that I have probably seen before . The only difference is the use of wildcards , Use %.c To handle the default C Code target. This is the default , No document found for the time being , It has something to do with the conclusion of my test . In the next comparison example, we can make a better comparison .

CC := gcc

objects = foo.o bar.o all.o

all: $(objects)

# These files compile via implicit rules

# Syntax - targets ...: target-pattern: prereq-patterns ...

# In the case of the first target, foo.o, the target-pattern matches foo.o and sets the "stem" to be "foo".

# It then replaces the '%' in prereq-patterns with that stem

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

all.c:

    echo "int main() { return 0; }" > all.c

%.c:

    touch [email protected]

clean:

    rm -f *.c *.o all

    This is the one above Makefile Another way to express , Static matching pattern rules are used . I've written a very simple and crude Makefile In the generation tool of , This is a good improvement . If we can use this rule to deal with ,Makefile The simplicity of will increase a lot . However , Now that it has been automatically generated , Whether it is concise or not is not a special concern . The running effect of this example is the same as before , The effect is as follows ：

    Through this example , In fact, I can see a conclusion from my previous test . That's it , This method of fuzzy matching follows the previous one target There are different ways in the duplicate name test . Logically speaking ,%.c Can match all C file ,all.c It will also be added for the second processing . This should lead to a target Duplicate name of , If duplicate names are detected , A warning should appear as in the previous test . There are no warnings , Add a echo By comparing the output prompts, you can also find that there are all.c This part will ignore the right all.c To deal with . It looks like all.c The processing of has a higher priority and will cancel the subsequent expression of fuzzy matching .