15. Implicit rules for Make
15.1. Command Override
Question 1: What happens when the commands of each target are split and written to different places?
When a target with the same name appears in the Makefile:
Dependency: All dependencies will be merged together and become the final dependency of the target
Command: When multiple commands of the same target appear, make will issue a warning, and all previously defined commands will be replaced by the final command.
Note:
When using include to include other files (makefile), you need to ensure that the target of the same name in the included file has only dependencies and no commands; otherwise, the commands of the target of the same name will be overwritten!
15.2. Implicit Rules
Some common and routine rule implementations are provided in Make. When the target rule is not provided, can make try to use the code below the implicit rule
to compile successfully? Why?
SRCS := $(wildcard *.c)
OBJS := $(SRCS:.c=.o)
app.out : $(OBJS)
$(CC) -o $@ $^
$(RM) $^
@echo "Target ==> $@"
%.o : %.c
@echo "my rule"
$(CC) -c -o $@ $^
According to our preliminary analysis, there are at least two problems in the above Makefile:
1. CC and RM variables are not defined and Direct use
2. No rules for generating .o files are defined (only linking without compiling)
results:
The reason why it works successfully is because of the implicit rules in make.
Make provides implicit rules for generating object files, and pre-defined variables are used to complete the compilation;
changing the part between predefined variables changes the behavior of implicit rules. When there are custom rules, implicit rules are no longer used.
16. Implicit rules for Make
16.1. Disadvantages of Implicit Rules
When the target's dependencies do not exist, make will try to find implicit rules one by one by dependency name, and deduce possible source files by dependency name.
This behavior seems to simplify the writing of makefiles, but it may cause unexpected problems.
Implicit rules Side effects:
Compilation behavior is difficult to control, and a large number of implicit rules may produce unexpected compilation behavior
Compilation inefficiency: make selects the final rule from implicit rules and custom rules
Example:
makefile:
app.out : main .o func.o
$(CC) -lstdc++ -o $@ $^
main.c:
#include <stdio.h>
extern void greeting();
int main()
{
greeting();
return 0;}
Since we do not define the greeting function, we guess that a link error will be reported at compile time, and the greeting symbol cannot be found.
Actual output:
We see that the func.p file is used directly to generate the func.o file, but since the pc software is not installed in my environment, an error is reported. The whole process was completely different from what we expected.
Implicit rule chain:
When the dependent object file does not exist, make will try to combine various implicit rules to create the target, resulting in unexpected compilation behavior!
Example: A target named No is required: Ny --> Nc --> No
We can directly use the make -p command to view all implicit rules,
16.2. Disabling of Implicit Rules
1. Partial disable: Customize the rules in the Makefile, such as defining a rule that only has targets and dependencies without commands, such as:
%.o : %.p
so that our custom rules can be used instead of implicit rules
2
.Disable make -r globally.
Obviously this is simple and practical, it is recommended to use
16.3. Suffix rules
The suffix rule is the old "pattern rule", which can be customized by the suffix description.
1. Double suffix rule: define a pair of file suffixes (depending on the file suffix and the target file suffix)
such as: .cpp <---> %. o : %.cpp
2. Single suffix rule: define a single file suffix (source file suffix)
such as: .c <---> % : %.c
Note:
Dependency is not allowed in suffix rules, suffix rules must have commands, Otherwise, meaningless
has been gradually replaced by pattern rules, it is recommended to use pattern rules directly