不得不說一句，從開始，到現在，我不得不忍受著無法使用make MAKEFILE的折磨。而如果從開始到現在，所有的例子你都親自敲過諸如如下的命令：

gcc -Wall attr.c value.c view.c control.c model.c -o attr 

你或許會對C語言編程喪失信心。你甚至可能會出現一個代碼編譯的錯誤。當你敲入

gcc -Wall attr.c value.c view.c model.c -o attr 

鏈接會有問題。這些手工的小失誤，帶來的都是麻煩事。還有更麻煩的。如果我們有100個C文件整合起來的工程。不算多，真的。如果改動一個文件，也按照上面的方式及執行，就會很慢。特別是debug的時候，思路往往在你上次廁所后就容易斷掉。嘗試幾種測試方法，迅速觀測結果，對于某些類型的測試是需要的。而debug也經常需要反復的修改和編譯鏈接。

一種好的做法，是我們先編譯，把對象文件保存，當出現某個具體文件修改后，可以只對這個文件進行編譯，而其他文件沒必要處理，然后由此對此次以及上次生成的沒有改變對應源碼的對象文件一起鏈接。編譯相對鏈接，是個比較慢的工作。由此在你只改動control.c前后你可以如下操作。

沒改動control.c前，我們可以

gcc -Wall -c attr.c value.c view.c control.c model.c 

以上由于有了-c所以是多所有的C文件進行編譯，生成同名的，后綴為.o的對象文件。

gcc attr.o value.o view.o control.o model.o -o attr 

這是將所有的對象文件作為資源，鏈接生成一個attr的執行文件。

僅改動了control.c，那么我們可以

gcc -Wall -c control.c  
 
gcc attr.o value.o view.o control.o model.o -o attr  

但這樣也帶來個問題。很多情況下，經常出現你實際改動的文件，并沒有被編譯，而原先的.o文件也存在。上述工作都不會報錯，而且你的改動并沒有被執行程序所體現。通常的情況，你會徹底崩潰，為什么左改右改，就是沒變化。

這里提到一個新的參考文獻 6. <gun make 中文手冊> 徐海兵 譯。 我不認識他，哈。不過難得我推薦一本中文書籍。理由如下：

1、這書即便有人認為翻譯的爛，但多少對你學習make足以，沒覺得有什么翻譯不足導致影響原理，概念理解的地方。

2、make 更是個工具。主要是拿來用的。除非整天折騰makefile的人，相信我，通常你每3個月，才組織設計一次makefile，那么原理和概念的東西，還是會有失憶性遺漏，快速用起來這是關鍵。這和C標準資料還不一樣。后者。原理理解的一些偏差，可能導致代碼涉及的很大改動。

推薦gun make 中文手冊 。但不會如同其他參考文獻一樣，給出章節出處，做詳細闡述，是希望你該養成，自己通讀資料的習慣，而不是別人告訴你，具體哪頁，哪行的保姆時學習。 因此，我不會給出任何參考文獻 6的引用，當然絕對不是對徐海兵的冒犯及不信任。

鬼話：如果你說你會寫C程序，而不會用make，拜托，千萬別出去拿C的招牌說事了。丟人，而且丟大了。

這里先說說make的精髓。我認為有以下幾個方面。

1、文件敏感性。也即，當make工作，會對文件是否修改很敏感。于是，你可以丟給他一堆文件，當這些文件被更新時，它是可以根據規則，進行有選擇的處理。

2、依賴，這種依賴，你可以理解成因果關系。甚至可以理解成觸發事件的響應。這可比一般的腳本要爽太多。

3、規則。這是編程序的一個境界。突出強調規則，如同數學突出強調邏輯關系，而不是強調具體數值一樣。

4、腳本化。靈活的組織邏輯，而不是呆板的一行行的解釋執行規則。

鬼話：為什么說make是這么好的東西。如果你認為某個應用程序或者linux的創始人算大牛，確實是大牛，那么make可以說是一堆歷史上的大牛，在經歷過痛苦后，努力創造出來的東西。任何贊美之詞，如果你用在其他應用軟件或工具上，make都值得同等對待。C語言，除了自身在代碼性能，底層開發上可以超越其他高級語言外，原生的make操作，也足以讓一個C程序員，藐視其他夸夸其談某個IDE多么人性化的程序員，因為大多數你看到的IDE，后臺都藏著make，make不單單為C語言服務，無非C程序員當然也包括C++程序員經常直接面向make。不是我在激起語言和程序員的類別之爭。make 的設計，思想，對比現在很多什么架構，框架，要高明的多。雖然你看它是非常簡單和樸素的。相信我，make的熟練使用后，你一定會有對C語言設計脫胎換骨的感覺，無論你在那個操作系統下。當然make這不是本書的重點，具體的學習，需要系統的看對應的資料，包括上面推薦的那本，此處僅介紹如何簡單的應用，以降低我們現有C語言設計中的開發負擔。

先說說make的操作。通常就是個簡單的

make 

命令。make程序，會自動查找配置文件。也是傳說中的makefile，這算慣例，或潛規則?；蛘吣憧梢?/p>

make -f filename 

filename 是一個任意文件。

但不是潛規則要求的文件名。這樣做通常用于臨時性的make使用，正式情況，不需要如此折騰。潛規則有個好處，你被潛規則了，其他人也會被潛規則。這樣降低你和其他人的交流成本。

由此，另一個做法是將你的計劃，寫在名為 GNUmakefile ,makefile ,Makefile這幾種文件名中任意一個。恩。make的潛規則文件名也有幾種寫法。但潛規則中的潛規則是，我們都用Makefile。如果老師考你 make的潛規則，都可以識別哪幾個文件名，他們的依次順序時，你可以毫不猶豫的向他豎中指。他如果問哪學的，你可以說是野鬼教的，因為他沒有說是那個版 本的make。不過豎歸豎，為了防止意外，你還是要知道，GNU make是按照GNUmakefile ,makefile ,Makefile依次進行查找的，同時盡可能的確保你的目錄下只有Makefile一個文件。

需要特別說明的是，GNUmakefile人如其名，只有GNU make可以識別，make也有不同的版本和來源和C的編譯器一樣，只不過linux上用GNU make的還是比較多。但仍然建議使用 Makefile這個文件名。

有了潛規則，你就不需要如此寫

$make Makefile 

直接 make會查找。那么我們先做第一個例子。你將下面的內容，保存為Makefile這個文件在./attr這個目錄下

what:  
 
gcc -Wall -c ./attr.c ./control.c ./view.c ./value.c ./model.c  
 
gcc ./attr.o ./control.o ./view.o ./value.o ./model.o -o attr  
 
heihei:  
 
rm *.o  

注意兩個書寫問題

1、what需要頂頭寫，表示一個操作的開始，用此來直接區分不同操作的描述范圍

2、gcc等實際操作的內容前面需要空一個tab。

鬼話：“操作”只是我的口頭語，官方的說法叫“規則的目標”，我只是希望新手理解實際就是一個操作，而且操作里面可以有很多命令 依次組成依次執行，而且make一次只會對一個操作進行操作，除非其他操作和這個操作有依賴關系。但操作通常都是有操作的結果（輸出的文件），所以叫規則 的目標

鬼話：“頂頭寫”除了描述“規則的目標”外，還有很多其他頂頭寫的事情，因此，不單單要頂頭寫，你還需要加上個‘：’,這樣，make就可以知道，頂頭寫，同時存在一個‘：’則是一個操作的開始，也就是“規則的目標”。

鬼話：關于"what",我實在想不出什么名詞，能說明“規則的目標”有什么特殊的命名方式。用what是希望大家理解，規則的目標的名字，并沒有什么特殊約束，你愛怎么寫怎么寫，但存在一些潛規則和make的規矩會讓你吃苦頭，只是我在邊上 “what,寫這個例子時，我確實在what,heihei"。比如通常,heihei應該用 clean來實現。同時，你執行如下命令

make  
 
make what  
 
make clean  

你會發現，make沒有后面的參數時，執行了what。不是因為what的單詞字幕更少。而是因為what是第一個規則。因此，通常你需要將最常用的，當然 未 必是build操作，放在第一個。這樣可以簡化你的操作。直接make就可以。但這個最常用的，與你和你的開發小組第一直覺希望make做什么有關系。通常程 序員之間會說“這樣這樣后，make一下”而不會解釋make what。

你問“make what?"

同事說：“對就是make what!"

"make what what 啊？”

“就是make what 啊，你what 什么 what ??？”

這說明兩個問題，第一，make的第一個規則，盡可能是你們小組的共識常用工作，第二，命名很重要。你和你的同伙"what"來“what"去，最多相互 懷疑智商問題。但如果你起名叫“love",然后和你的女同事說，記得make love一下。當心她告你性騷擾。

現在你已經發現make 針對Makefile有第一個好處了。就是批處理化。算是腳本的一種功能體現吧。不過你反復的執行

make what 

系統會機械呆板的毫無保留的進行執行。如果我們只想執行那些被改變的呢？你可以嘗試如下方式：

what: ./control.c  
 
gcc -Wall -c ./attr.c ./control.c ./view.c ./value.c ./model.c  
 
gcc ./attr.o ./control.o ./view.o ./value.o ./model.o -o attr  

保存，我們再執行兩邊make?；蛘適ake what。

現在回到haha上。繼續make haha ,兩邊，恩，你會發現和前面一樣。沒錯。我們再換一下

./control.o:./control.c  
 
gcc -Wall -c ./attr.c ./control.c ./view.c ./value.c ./model.c  
 
gcc ./attr.o ./control.o ./view.o ./value.o ./model.o -o attr  
 
clean:  
 
rm *.o  

我們再make，此時make會提示，./contorl.o是最新的了。沒有必要處理。這是因為make會根據目標,./control.o的依賴，./control.c來判斷，是否需要對目標進行重新處理。如果依賴沒有被更新過，那么目標對應的處理，就是下面的兩個gcc命令，則不會進行。這樣好處是顯而易見的。你對應的C文件沒有更新，何必處理呢？

你此時，將control.c的第一行，加次回車，意思是讓文件多個空白行。保存，再

make 

此時，gcc又被運行了。怎么樣？讓make幫你查找當前那些文件被改動了，很方便，很貼心吧。不過此時又有個問題，你嘗試將model.c同樣加上一個空白行，保存，再

make 

結果提示，已是最新文件。沒辦法，確實如此啊，你的依賴規則只提到了control.c，而你的目標是./control.o，無非目標下的執行，你做了很多.o的生成，和最終attr執行程序的鏈接。同樣的錯誤會發生在你修改control.h。make會查找依賴的文件的更新情況。但是不會啟動C的預編譯系統來判斷，其所#include的文件是否更新。

你可以嘗試

make  
 
make clean  
 
make  

此時，clean會刪除掉所有的.o文件，所以第二次make又再次運行。因此make除了看依賴是否改變，還會看目標是否存在。由此引發一個問題。你嘗試

make  
 
rm attr  
 
make  

怎么樣？第二次make不工作了。因為./control.o確實存在啊。即便./attr被刪除了。但和目標生成的依賴沒有關系。和目標也沒關系。雖然你的批處理的最終目標是./attr。但是make 的默認操作是看./control.o由此你需要注意，考慮一個現實，最終編譯鏈接，是做什么事情？通常我們將編譯鏈接的工作稱為build。區別于強制工作 rebuild，即便所有的文件沒有被更新，也將所有的文件進行重新操作。由此我們可以如下寫：

control.o:./control.c ./control.h  
 
gcc -Wall -c ./control.c  
 
./value.o:./value.c ./value.h  
 
gcc -Wall -c ./model.c  
 
./model.o:./model.c ./value.h  
 
gcc -Wall -c ./model.c  
 
./view.o:./view.c ./value.h  
 
gcc -Wall -c ./view.c  
 
./attr.o:./attr.c ./value.h  
 
gcc -Wall -c ./attr.c  
 
build:./control.o ./value.o ./model.o ./view.o ./attr.o  
 
gcc ./attr.o ./control.o ./view.o ./value.o ./model.o -o attr  
 
rebuild:  
 
clean  
 
build  
 
clean:  
 
rm *.o  

我們運行一下

make clean  
 
make  

哦，第一次單獨的make會出來一個

gcc -Wall -c ./control.c  
 
make build  

哦。有一堆 gcc -Wall，還有一個錯誤，提示，沒有value.o這個文件。導致無法鏈接。還是那句

鬼話：我盡可能教錯的，這樣你才知道，對的有什么價值。與其挨老師的板子說你不努力死記硬背，不如到我野鬼的坑里摔一摔，鍛煉個強健筋骨。

如果你再運行make rebuild

會提示，找不到clean

如果你再次運行

make build 

則仍然會繼續執行，不在乎是否.o存在，C文件是否被更新。

即便你更新 define_attr.h，對于model.o仍然無動于衷。你忘了在./model.o的依賴中增加這個文件了嘛。

上面這個情況說明了幾個問題：

1、make 仍然是針對第一個規則目標進行默認處理。

2、make build 依次檢測.o文件這些目標，并根據.o文件啟動對應的目標的執行。

3、你會發現，./value.o:的實際執行書寫不當，導致沒有去完成./value.o的生成，而是做了model.o的工作。

4、clean我確實寫了，為什么找不到？

5、很多依賴好煩人，難道我們需要根據C代碼一個個找頭文件？你忘了在./model.o的依賴中增加這個文件了嘛。

6、make build總在執行。正常，build看成了一個目標。而這個目標并不是文件，則make始終認為這個目標需要執行。

針對第一個問題，如果你反復debug時，需要盡可能的將所有的編譯，并鏈接，那么build是需要作為默認規則。因此我們需要把build調整到第一個位置。

第二第三個問題是，該死的規則依賴的書寫方式，還是麻煩和容易書寫出錯。我們可以使用通配符和自動化變量來設計一個通用處理方法。如下

%.o:%.c  
 
gcc -Wall -c $< $@  

%表示一個通配符。這只能正對 x.o ,而不會針對x.p.o等情況。

%.o:%.c 

表示，任意文件名，后綴為.c的，為依賴，對應的目標文件是同名的文件名，后綴為.o，我們使用同樣一個規則。

$< 表示規則的依賴，$@表示規則的目標。其實你更本不需要寫這個內容，make也隱藏了這個默認規則。無非默認的情況并沒有沒用-Wall

 

第四個問題是，為什么rebuild的操作找不到clean。很簡單,clean是個操作規則，你可以理解成一個函數調用另一個函數，而不是具體的執行語句，當然切記clean并不是個函數，因此你應當把clean作為一個依賴放到rebuild 之后，而不是作為操作。clean不是磁盤文件，此時make 在磁盤上尋找clean自然找不到。這還只是個故事，如果想讓故事增加點懸疑，你可以讓磁盤上真有個叫clean的文件。這種情況下，如果僅是個操作，而不是文件，那么你需要用.PHONY來說明一下。

第5個問題，我們可以借助gcc的一個工作， -MM，其目的是，對C文件進行分析，列出其依賴的頭文件是什么。你可以執行如下命令

gcc -M model.c  
 
gcc -MM model.c  

看一下 ,上述兩個參數的差異。為了省省屏幕，通常還是-MM吧，他可以忽略默認的頭文件位置，也即那些 <>內的頭文件。除非你需要檢查<>內的頭文件是否路徑引用正確。否則 -MM是首選。此時gcc給自動給你打印出依賴，只不過在屏幕上。你完全可以將其輸出在一個文件里。如下：

gcc -MM model.c > model.d 

我們可以在Makefile 里 增加

sinclude model.d 

這基本等同于C語言里的#include。將model.d的內容增加到當前Makefile中進行分析，執行。

第6個問題，一個簡單的方法如下，我們可以讓build的依賴是最終的執行文件。而最終的執行文件作為一個目標，其依賴各種.o如下

build: attr  
 
attr:./control.o ./value.o ./model.o ./view.o ./attr.o  

因此我們的Makefile可以如下設計

build:attr  
 
attr:%.o  
 
gcc ./attr.o ./control.o ./view.o ./value.o ./model.o -o attr  
 
rebuild:  
 
clean  
 
build  
 
clean:  
 
rm *.o *.d  
 
include view.d model.d value.d attr.d control.d  
 
%.o :%.c %d  
 
gcc -Wall -c $< -o $@  
 
.PHONY: rebuild clean build 

不過這樣還是麻煩，因為你需要手工把所有的.d文件進行生成才能使用,而且你會發現源代碼的文件名被使用了很多地方，無非是后綴有.d,有.o,雖然我們使用%.o做了個通配符的.o依賴，讓所有當前能找到.o都加入進來，但仍然是麻煩。一個簡單清爽的做法如下：

CFLAG := -Wall -c  
CC := gcc  
sources = model.c view.c attr.c control.c value.c  
build:attr  
%.o :%.c  
    $(CC) $(CFLAG) $< -o $@  
%.d: %.c  
    $(CC) -MM  $< > $@.$$$$; \  
    sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \  
    rm -f $@.$$$$  
sinclude $(sources:.c=.d)  
 
attr:$(sources:.c=.o)  
    gcc $^ -o $@  
      
clean:  
    -rm  %.o %.d  
rebuild:clean build  
          
.PHONY:rebuild clean build  

注意幾個問題

$< ,$@，$^詳細信息，你需要參考文獻 6，他們是自動化變量。

%，和*的差異，也需要仔細閱讀參考文獻 6 。

sinclude 可以引入一批文件。

rm之前多了個 -,意思是如果這是個錯誤執行，則忽略，而不是make中斷。你覺得沒用？那你將 -rm %.o刪除掉。然后嘗試執行以下命令

make clean  
 
make rebuild  

沒有.o文件，好事啊，難道就不能繼續build嗎？make對實際的執行命令，如果出錯就停止了。還是安心加上 -吧，如果有些執行不在乎其是否正常，rm是典型的例子。

%d:%c后面執行的是什么意思？你在參考文獻6中同樣可以找到。這里還引入了變量的概念。

鬼話：變量是個好東西，你可以和C語言中的#define近似理解。不過還是有些區別，在展開的時候。同時特別諸如CC，CFLAG這些變量，屬于隱含的變量。本身系統會有一定默認的含義，上面這樣的做法，是重新書寫定義，不要亂表示其他內容。多看看書是有好處的。

針對上面的內容，基本上你可以直接根據C文件的列表，也即你修改sources的后續內容進行自動化編譯了。包括依賴的自動生成。當然你完全可以如下操作，畢竟gcc -MM的內容，通常不重要，看這也眼花。

%.d: %.c  
 
@set -e; rm -f $@;\  
 
$(CC) -MM $(CFLAGS) $< > $@.$$$$;\  
 
sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@;\  
 
rm -f $@.$$$$ 

鬼話：上面這些內容該怎么解釋。我說了。多半你也忘，不如你自己查資料。與其google一下，不如找到shell的相關書籍尋找答案。我希望從告訴你什么資料，多少頁多少行，最初級階段開始，到我告訴你這本書，你自己找，到你自己去尋找一本書，找到相關內容，這么延伸的提升你自主查找資料的能力。別抱怨我懶，我勤快了，你就懶。我懶，你就有機會勤快了。

原文鏈接：http://www.oschina.net/question/249672_79322