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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、這書即便有人認(rèn)為翻譯的爛，但多少對你學(xué)習(xí)make足以，沒覺得有什么翻譯不足導(dǎo)致影響原理，概念理解的地方。

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

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

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

這里先說說make的精髓。我認(rèn)為有以下幾個方面。

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

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

3、規(guī)則。這是編程序的一個境界。突出強調(diào)規(guī)則，如同數(shù)學(xué)突出強調(diào)邏輯關(guān)系，而不是強調(diào)具體數(shù)值一樣。

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

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

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

make 

命令。make程序，會自動查找配置文件。也是傳說中的makefile，這算慣例，或潛規(guī)則。或者你可以

make -f filename 

filename 是一個任意文件。

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

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

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

有了潛規(guī)則，你就不需要如此寫

$make Makefile 

直接 make會查找。那么我們先做第一個例子。你將下面的內(nèi)容，保存為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需要頂頭寫，表示一個操作的開始，用此來直接區(qū)分不同操作的描述范圍

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

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

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

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

make  
 
make what  
 
make clean  

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

你問“make what?"

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

"make what what ??？”

“就是make what 啊，你what 什么 what ?。?rdquo;

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

現(xiàn)在你已經(jīng)發(fā)現(xiàn)make 針對Makefile有第一個好處了。就是批處理化。算是腳本的一種功能體現(xiàn)吧。不過你反復(fù)的執(zhí)行

make what 

系統(tǒng)會機(jī)械呆板的毫無保留的進(jìn)行執(zhí)行。如果我們只想執(zhí)行那些被改變的呢？你可以嘗試如下方式：

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  

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

現(xiàn)在回到haha上。繼續(xù)make haha ,兩邊，恩，你會發(fā)現(xiàn)和前面一樣。沒錯。我們再換一下

./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會根據(jù)目標(biāo),./control.o的依賴，./control.c來判斷，是否需要對目標(biāo)進(jìn)行重新處理。如果依賴沒有被更新過，那么目標(biāo)對應(yīng)的處理，就是下面的兩個gcc命令，則不會進(jìn)行。這樣好處是顯而易見的。你對應(yīng)的C文件沒有更新，何必處理呢？

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

make 

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

make 

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

你可以嘗試

make  
 
make clean  
 
make  

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

make  
 
rm attr  
 
make  

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

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這個文件。導(dǎo)致無法鏈接。還是那句

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

如果你再運行make rebuild

會提示，找不到clean

如果你再次運行

make build 

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

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

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

1、make 仍然是針對第一個規(guī)則目標(biāo)進(jìn)行默認(rèn)處理。

2、make build 依次檢測.o文件這些目標(biāo)，并根據(jù).o文件啟動對應(yīng)的目標(biāo)的執(zhí)行。

3、你會發(fā)現(xiàn)，./value.o:的實際執(zhí)行書寫不當(dāng)，導(dǎo)致沒有去完成./value.o的生成，而是做了model.o的工作。

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

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

6、make build總在執(zhí)行。正常，build看成了一個目標(biāo)。而這個目標(biāo)并不是文件，則make始終認(rèn)為這個目標(biāo)需要執(zhí)行。

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

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

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

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

%.o:%.c 

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

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

 

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

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

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

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

gcc -MM model.c > model.d 

我們可以在Makefile 里 增加

sinclude model.d 

這基本等同于C語言里的#include。將model.d的內(nèi)容增加到當(dāng)前Makefile中進(jìn)行分析，執(zhí)行。

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

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

因此我們的Makefile可以如下設(shè)計

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文件進(jìn)行生成才能使用,而且你會發(fā)現(xiàn)源代碼的文件名被使用了很多地方，無非是后綴有.d,有.o,雖然我們使用%.o做了個通配符的.o依賴，讓所有當(dāng)前能找到.o都加入進(jìn)來，但仍然是麻煩。一個簡單清爽的做法如下：

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  

注意幾個問題

$< ,$@，$^詳細(xì)信息，你需要參考文獻(xiàn) 6，他們是自動化變量。

%，和*的差異，也需要仔細(xì)閱讀參考文獻(xiàn) 6 。

sinclude 可以引入一批文件。

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

make clean  
 
make rebuild  

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

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

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

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

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

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

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