From 9CBS - Document Center - Other Haoel [Original] Third, make How to work in the default mode, that is, we only enter the Make command. So, 1, make will find the name "makefile" or "makefile" in the current directory. 2, if you find it, it will find the first target file in the file. In the above example, he will find the "Edit" file and use this file as the final target file. 3, if the Edit file does not exist, or the file modification time behind the EDIT is better than the Edit file, then he will perform the commands defined later to generate the Edit file. 4, if the EDIT is dependent on the .o file, Make will find the dependence of the target as the .o file in the current file, if you find it, generate the .o file according to the rule. (This is a bit like a stack process) 5. Of course, your C file and H file exist, so Make will generate .o file, then use .o file life make the ultimate task, that is, the execution file Edit . This is the dependence of the entire make, and make a layer of relying on the document again until the first target file is finally compiled. In the process of finding, if an error occurs, if the last dependent file cannot be found, Make will exit directly and report the error, and the error of the defined command, or the compilation is unsuccessful. Make only the dependence of the document, that is, if I find the dependencies, the file behind the colon is still, then I am sorry, I will not work. Through the above analysis, we know that like Clean, it is not directly or indirectly associated with the first target file, then the commands that will be later defined will not be executed automatically, however, we can display to execute it as you want. That is, command - "make clean" to clear all target files to recompile. So in our programming, if this project has been compiled, when we modify one of the source files, such as file.c, then according to our dependence, our target file.o will be compiled (that is The commands defined later later), so File.o's files are also the latest, so file.o's file modification time is more new than Edit, so Edit will be resinted (see Edit target file for details) The command that is defined). And if we changed "command.h", then kdb.o, command.o and files.o will be recompiled, and Edit will be linked. IV. Makefile uses variables in the above example, let's take a look at the rules of Edit: 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 We can see the string of the [.o] file twice, if our project needs Join a new [.o] file, then we need to add (it should be three places, there is also a place in Clean).
Of course, our makefile is not complicated, so it is not tired in two places, but if Makefile is complicated, then we may have forgetting a place you need to join, but causing compilation to fail. So, for the easy maintenance of Makefile, we can use variables in Makefile. Makefile variables are also a string, understanding the macros in C language may be better. For example, we declare a variable called Objects, Objects, Objs, Objs, Obj, or Obj, anyway, no matter what, you can represent the OBJ file. We will define this at Makefile: Objects = main.o kbd.o command.o display.o / insert.o search.o files.o utils.o, we can easily in our makefile "$ (Objects)" is used to use this variable, so our improvement version makefile turns the following: 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 - 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) Then if there is a new .o file join, we only need to simply modify the Objects variable. With regard to the topic of variables, I will give you a way. 5. Let Make automatically derive the GNU's Make very powerful. It can automatically derive the files and the commands behind the document dependencies, so we don't have to write similar orders after each [.o] file, because we Make will automatically identify and derive commands themselves. As long as Make sees an [.o] file, it will automatically put the [.c] file in the dependencies, if Make finds a wh dayver.o, then wherever.c will be the dependency of whatver.o . And cc -c whatver.c will also be derived, so our makefile will never write so complicated. We are new Makefile and released.
Objects = main.o kbd.o command.o display.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 method is Make's "Confirgin Rules". In the above file content, ". Phony" means that Clean is a pseudo target file. With more detailed "hidden rules" and "pseudo target files", I will give you a way. Sixth, alternative Makefile is just our makers can automatically derive the order, then I see that the bunch of [.o] and [.h] is a bit uncomfortable, so much repetition [.h], can It is gathers, well, no problem, this is easy for Make, who told it to provide automatic derivation of commands and files? Let's take a look at the latest style makefile. Objects = main.o kbd.o command.o display.o / insert.o search.o files.o utils.o Edit: $ (Objects) CC -O Edit $ (Objects): Defs.h KBD .o command.o files.o: command.h display.o insert.o search.o files.o: buffer.h .phony: Clean: RM Edit $ (Objects) This style makes our makefile become Very simple, but our documentation is a bit messy. You can not have it both ways. I still see your preference. I don't like this style. First, the dependency of the document is unclear. Second, if there are more files, join a few new .o files, it will not be clear. Seven, the rules of the empty target document should write a rule that empty the target file (.o and execution file), which is not only easy to compile, but also to keep the file clean. This is a "cultivation" (huh, I still remember my "programming cultivation"). The general style is: Clean: RM Edit $ (Objects) is more robust to: .phony: Clean Clean: -rm Edit $ (Objects) said before, .phony means that Clean is a "pseudo-target". . The meaning of adding a small minus sign in front of the RM command is that maybe some files have problems, but do not manage, continue to do. Of course, the rules of Clean do not place the beginning of the file, otherwise, this will become the default target of Make, I believe who is not willing to do this.
