化構(gòu)建實(shí)戰(zhàn)：從核心語(yǔ)法到工程實(shí)踐)
1. 從一段真實(shí)經(jīng)歷說(shuō)起為什么你需要make老手可能早就離不開make了但如果你是剛接觸Linux開發(fā)的新手或者一直用小項(xiàng)目、單文件代碼“裸編”過(guò)來(lái)的那我建議你認(rèn)真看完這篇文章。我當(dāng)年第一次接手一個(gè)稍微像樣一點(diǎn)的C項(xiàng)目幾十個(gè)源文件需要在終端里一條一條敲gcc命令頭文件改一個(gè)就要重新編譯一堆文件編譯選項(xiàng)還特別長(zhǎng)偶爾敲錯(cuò)一個(gè)參數(shù)就得從頭排查。那段時(shí)間每次“編一下跑一下”都像在玩掃雷整個(gè)人都很痛苦。后來(lái)某位同事讓我看了他項(xiàng)目里的Makefile我才反應(yīng)過(guò)來(lái)這東西就是在幫你把編譯、打包、清理這些重復(fù)勞動(dòng)全部自動(dòng)化。簡(jiǎn)單說(shuō)make是一個(gè)自動(dòng)化構(gòu)建工具而Makefile是給make讀的“構(gòu)建劇本”里面寫清楚目標(biāo)文件怎么生成、依賴哪些源文件、用什么命令生成。有了它你在終端里只需要敲一個(gè) make剩下的編譯、鏈接、輸出可執(zhí)行文件全部自動(dòng)完成。就算改了十幾個(gè)文件make也能精準(zhǔn)識(shí)別哪些需要重編哪些不用動(dòng)比全量重編快得多。這篇文章我不會(huì)跟你念man手冊(cè)。我只講兩件事一是Makefile的底層邏輯和核心語(yǔ)法到底怎么用二是我在實(shí)際項(xiàng)目里踩過(guò)的坑、驗(yàn)證過(guò)的寫法。按這套思路走不管你之后是做嵌入式、Linux服務(wù)端、還是搞開源項(xiàng)目都能很快寫出能用的Makefile并且知道每行在干什么。2. Makefile三要素目標(biāo)、依賴、命令之間的關(guān)系2.1 先把三要素掰開揉碎所有Makefile不管寫得多花哨本質(zhì)都是若干個(gè)“規(guī)則”。一條規(guī)則長(zhǎng)這樣target: prerequisites command三部分分別是目標(biāo)target你要生成的東西可以是一個(gè)可執(zhí)行文件、一個(gè).o文件也可以是一個(gè)動(dòng)作名比如clean。依賴prerequisites生成目標(biāo)之前必須具備的文件或其他目標(biāo)。多個(gè)依賴之間用空格分隔。命令command真正干活的shell命令通常就是編譯、鏈接、拷貝這些。命令前面必須是一個(gè)Tab縮進(jìn)不是四個(gè)空格不是兩個(gè)空格是Tab。這個(gè)坑我后面單獨(dú)說(shuō)因?yàn)閹缀跛行率侄荚谶@里翻車。舉一個(gè)最直觀的例子hello: hello.o gcc -o hello hello.o hello.o: hello.c gcc -c hello.c -o hello.o第一條規(guī)則說(shuō)要生成hello就得先有hello.o然后執(zhí)行g(shù)cc把hello.o鏈接成可執(zhí)行文件hello。第二條規(guī)則說(shuō)要生成hello.o得有hello.c然后執(zhí)行g(shù)cc把hello.c編譯成hello.o。你在終端敲make的時(shí)候make會(huì)先讀Makefile找到第一個(gè)目標(biāo)hello然后檢查它的依賴hello.o。如果hello.o不存在make就會(huì)去找hello.o對(duì)應(yīng)的規(guī)則先編譯出hello.o再回來(lái)鏈接出hello。整個(gè)過(guò)程是自動(dòng)遞歸的很像一個(gè)“依賴樹”。這是理解make工作的關(guān)鍵它不是一個(gè)簡(jiǎn)單的從左到右執(zhí)行腳本的工具而是以目標(biāo)為導(dǎo)向先算依賴關(guān)系再?zèng)Q定執(zhí)行哪些命令。2.2 make真正厲害的地方增量編譯不用make的時(shí)候手動(dòng)編譯最煩的就是每次都要把全部文件重新編一遍。大型項(xiàng)目幾十個(gè)文件還好幾百個(gè)文件的時(shí)候一次全量編譯可能要幾分鐘甚至十幾分鐘而你只是改了一行代碼。make天生就是為了解決這個(gè)問(wèn)題——它通過(guò)比較目標(biāo)文件和依賴文件的時(shí)間戳來(lái)決定是否重新生成目標(biāo)。舉個(gè)具體的流程你改了一個(gè)源文件那個(gè)文件對(duì)應(yīng)的.o目標(biāo)文件的時(shí)間戳就會(huì)比源文件舊make發(fā)現(xiàn)“哦這個(gè)目標(biāo)過(guò)期了”于是只重新編譯這個(gè)源文件。其他沒改動(dòng)的文件目標(biāo)比依賴新make直接跳過(guò)。最后再重新鏈接一次。這就是增量編譯幾百個(gè)文件的項(xiàng)目修改單個(gè)文件后的構(gòu)建可能只需要幾秒鐘實(shí)際效果很驚人。2.3 命令行里的空格與Tab問(wèn)題說(shuō)實(shí)話這是我在各種技術(shù)社區(qū)里看到最多、最經(jīng)典的報(bào)錯(cuò)現(xiàn)場(chǎng)Makefile:3: *** missing separator. Stop.這個(gè)錯(cuò)誤幾乎都是命令前面用了空格而不是Tab。為什么make只認(rèn)Tab這是歷史設(shè)計(jì)問(wèn)題但你必須接受它。很多編輯器會(huì)在配置里默認(rèn)把Tab轉(zhuǎn)換成空格這就會(huì)讓你的Makefile“看起來(lái)對(duì)齊了但實(shí)際沒法跑”。我目前的習(xí)慣是用Vim寫Makefile的時(shí)候在.vimrc里強(qiáng)行關(guān)閉expandtab并且設(shè)置自動(dòng)縮進(jìn)寬度為8用VS Code就把editor.insertSpaces設(shè)為false保證編輯的文件里插入的是真正的Tab字符。如果實(shí)在判斷不清可以在Vim里輸入set listTab字符會(huì)顯示為^I空格是普通的小點(diǎn)一眼就能分辨。2.4 偽目標(biāo)清理操作的隱藏陷阱你可能已經(jīng)注意到我前面提到的clean目標(biāo)并不是一個(gè)真實(shí)文件名。它只是一個(gè)動(dòng)作標(biāo)簽。如果你真的在目錄里放了一個(gè)叫clean的文件再執(zhí)行make clean的時(shí)候make會(huì)發(fā)現(xiàn)clean這個(gè)“目標(biāo)”已經(jīng)存在了而且沒有依賴時(shí)間戳永遠(yuǎn)比依賴新于是它直接告訴你“clean是最新的”不會(huì)執(zhí)行rm命令。解決這個(gè)問(wèn)題的標(biāo)準(zhǔn)寫法就是..PHONY: clean clean: rm -f *.o hello.PHONY的完整形式是.PHONY: clean嗎其實(shí)標(biāo)準(zhǔn)寫法是clean:本身就是規(guī)則目標(biāo)而.PHONY: clean這行是聲明格式就是clean:后面跟你的規(guī)則。這行聲明告訴makeclean不能當(dāng)作文件名來(lái)看待它的作用是“命令標(biāo)簽”每次都要執(zhí)行就算同名文件已經(jīng)存在也一樣執(zhí)行。不僅clean像all、install、test這種動(dòng)作型目標(biāo)都建議聲明為.PHONY防止和同名文件沖突。3. 變量和自動(dòng)化變量讓Makefile從“寫死”變“通用”3.1 用變量管好你自己的編譯參數(shù)剛開始寫Makefile的時(shí)候你可能會(huì)把編譯命令一行行寫死比如每個(gè).o規(guī)則都是gcc -Wall -g -c xxx.c -o xxx.o。三個(gè)文件還行十幾個(gè)文件的時(shí)候你光改一個(gè)編譯選項(xiàng)比如加一個(gè)-stdc99就得改十幾行而且很容易漏。變量的引入就是為了解決這種重復(fù)勞動(dòng)。Makefile里的變量定義和引用很有特點(diǎn)CC gcc CFLAGS -Wall -g -O2 -stdc99 LDFLAGS -lm hello: hello.o utils.o $(CC) $(LDFLAGS) -o hello hello.o utils.o hello.o: hello.c $(CC) $(CFLAGS) -c hello.c -o hello.o utils.o: utils.c $(CC) $(CFLAGS) -c utils.c -o utils.o變量用定義用$(變量名)引用。這樣修改編譯器或者編譯選項(xiàng)的時(shí)候只需要改開頭那幾行后面的規(guī)則全部自動(dòng)生效。把變量定義集中到Makefile頂部幾乎可以算是一種行業(yè)習(xí)慣你去看那些開源項(xiàng)目基本鋪滿了一堆變量定義。變量賦值還有幾種寫法我用過(guò)一次就比較有印象遞歸展開式賦值變量的值是“最后時(shí)刻”的展開結(jié)果。比如A $(B) B hello這時(shí)$(A)展開之后是hello因?yàn)橹钡秸嬲褂玫臅r(shí)候才去解析B的值。:直接展開式賦值立刻把右邊的值計(jì)算好存下來(lái)。如果你想避免循環(huán)引用和二次解析帶來(lái)的意外用:更穩(wěn)。?如果變量之前沒有賦值就給它賦這個(gè)值常用于讓用戶可以通過(guò)命令行覆蓋默認(rèn)參數(shù)。追加內(nèi)容適合分步添加編譯選項(xiàng)。我自己寫Makefile的時(shí)候一旦涉及多個(gè)相互引用的變量都會(huì)傾向用:因?yàn)檫@樣變量的解析是確定的不會(huì)因?yàn)橘x值順序不同而出現(xiàn)詭異的展開結(jié)果。你可以把理解成“活引用”:是“快照”大多數(shù)場(chǎng)景下快照更可控。3.2 自動(dòng)化變量自動(dòng)化變量的實(shí)操價(jià)值手動(dòng)在每條規(guī)則里把目標(biāo)名和依賴名都寫一遍依然是重復(fù)勞動(dòng)。make提供了一套自動(dòng)化變量專用來(lái)在規(guī)則命令中表示目標(biāo)、依賴等信息最常用的有三個(gè)$表示當(dāng)前規(guī)則的目標(biāo)文件名。$^表示當(dāng)前規(guī)則的所有依賴文件名會(huì)自動(dòng)去重。$表示當(dāng)前規(guī)則的第一個(gè)依賴文件名。拿前面的例子重寫立刻會(huì)清爽很多hello: hello.o utils.o $(CC) $(LDFLAGS) -o $ $^ hello.o: hello.c $(CC) $(CFLAGS) -c $ -o $ utils.o: utils.c $(CC) $(CFLAGS) -c $ -o $第一條規(guī)則里$會(huì)被替換成hello$^變成hello.o utils.o。第二條規(guī)則里$是hello.c$是hello.o。這樣不管以后新增多少源文件規(guī)則主體幾乎不用改。還有兩個(gè)不那么常用但偶爾能救命的$?比當(dāng)前目標(biāo)更新的依賴文件列表常用于部署場(chǎng)景比如只在某些源文件變化后重新執(zhí)行歸檔命令。$*模式匹配中匹配到的那部分文件名后面講模式規(guī)則時(shí)會(huì)用到。3.3 通配符和模式規(guī)則批量處理源文件沒有模式規(guī)則之前每個(gè).c文件都要對(duì)應(yīng)一條獨(dú)立的編譯規(guī)則項(xiàng)目里幾十個(gè)源文件就得復(fù)制幾十條看著就累。make支持模式規(guī)則用%做通配符可以把一類文件的構(gòu)建規(guī)則濃縮成一條。%.o: %.c $(CC) $(CFLAGS) -c $ -o $這行規(guī)則的含義是任何.o文件只要有一個(gè)同名的.c文件作為依賴就用后面這條命令編譯。加上之前講的目標(biāo)規(guī)則整個(gè)Makefile可以濃縮成CC gcc CFLAGS -Wall -g -O2 LDFLAGS -lm OBJS hello.o utils.o hello: $(OBJS) $(CC) $(LDFLAGS) -o $ $^ %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: rm -f $(OBJS) hello .PHONY: clean這個(gè)Makefile已經(jīng)接近我平時(shí)使用的實(shí)際形態(tài)了。新增一個(gè)源文件的時(shí)候我只需要在OBJS變量里加一個(gè)對(duì)應(yīng)的.o文件名其他都不用動(dòng)。這才是自動(dòng)化構(gòu)建工具該有的效率。但是手動(dòng)維護(hù)OBJS這個(gè)列表還是有一點(diǎn)讓人不放心——如果忘了把新文件加進(jìn)去make不會(huì)自動(dòng)感知新出現(xiàn)的.c文件。更好的辦法是用函數(shù)自動(dòng)收集目錄下所有源文件。4. 函數(shù)和include讓Makefile自己學(xué)會(huì)找文件4.1 wildcard和patsubst兩個(gè)高頻函數(shù)make內(nèi)置了不少函數(shù)寫法看起來(lái)像變量引用但帶個(gè)符號(hào)。我平常用得最多的是這兩個(gè)SRCS $(wildcard *.c) OBJS $(patsubst %.c,%.o,$(SRCS))$(wildcard *.c)查找當(dāng)前目錄下所有.c文件返回一個(gè)以空格分隔的文件名列表。就算新拖進(jìn)來(lái)一個(gè)源文件SRCS也會(huì)自動(dòng)帶上它你完全不用手動(dòng)維護(hù)。$(patsubst %.c,%.o,$(SRCS))把SRCS里每個(gè).c后綴替換成.o后綴得到對(duì)應(yīng)的目標(biāo)文件列表。這樣整個(gè)Makefile就可以改成CC gcc CFLAGS -Wall -g -O2 LDFLAGS -lm SRCS $(wildcard *.c) OBJS $(patsubst %.c,%.o,$(SRCS)) TARGET app $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $ $^ %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: rm -f $(OBJS) $(TARGET) .PHONY: clean這個(gè)版本已經(jīng)具備“項(xiàng)目級(jí)”感覺了。你把任意一個(gè)只有.c文件的目錄交給它它都能自動(dòng)識(shí)別并構(gòu)建出可執(zhí)行文件app。但別太高興這套寫法有一個(gè)大問(wèn)題它完全沒有處理頭文件依賴。如果你修改了一個(gè)頭文件只有include這個(gè)頭文件的.c文件才會(huì)檢測(cè)到變化嗎不會(huì)。make只比較.c和.o的時(shí)間戳根本不知道頭文件參與其中。這就引出了Makefile里最隱蔽、也最容易引發(fā)線上問(wèn)題的topic之一。4.2 頭文件依賴大部分新手栽跟頭的地方舉個(gè)例子main.c里include了utils.h你改了utils.h里的一個(gè)宏定義期望main.o重新編譯。但make會(huì)發(fā)現(xiàn)main.c沒有變main.o和main.c的時(shí)間戳相比沒過(guò)期于是它直接不重新編譯main.o最后鏈接出來(lái)的程序還是老版本。這種“改了沒反應(yīng)”的問(wèn)題非常隱蔽查起來(lái)也費(fèi)勁。解決思路是讓.o的依賴?yán)锇黫nclude的所有頭文件。你可以手動(dòng)寫main.o: main.c utils.h但每個(gè)文件include哪些頭文件多了之后手動(dòng)維護(hù)完全不堪重負(fù)還不如讓編譯器幫你統(tǒng)計(jì)。GCC提供了-MM選項(xiàng)可以輸出源文件對(duì)應(yīng)的頭文件依賴列表gcc -MM main.c輸出大概是main.o: main.c utils.h common.h這正好是make能用的依賴規(guī)則。利用GCC的-M家族選項(xiàng)可以讓Makefile自動(dòng)生成并包含這些依賴信息。目前我見過(guò)、也實(shí)際使用的是下面這套方案SRCS $(wildcard *.c) OBJS $(patsubst %.c,%.o,$(SRCS)) DEPS $(patsubst %.o,%.d,$(OBJS)) %.o: %.c $(CC) $(CFLAGS) -MMD -MP -c $ -o $ -include $(DEPS)-MMD在編譯的同時(shí)生成一個(gè).d文件里面記錄當(dāng)前.c文件包含的頭文件依賴。-MP為每個(gè)頭文件生成一個(gè)空的偽目標(biāo)防止頭文件被刪除后make報(bào)錯(cuò)找不到規(guī)則。-include和include不同即使.d文件不存在比如第一次清理后也不會(huì)報(bào)錯(cuò)make會(huì)繼續(xù)執(zhí)行。每次編譯時(shí).d文件都會(huì)被刷新頭文件依賴自動(dòng)更新。你再也不用手動(dòng)維護(hù)頭文件列表了。這套方案從我第一次用到現(xiàn)在一直很穩(wěn)幾乎成了我的標(biāo)準(zhǔn)配置。4.3 小心make的天然“遞歸陷阱”自動(dòng)化收集源文件還有個(gè)邊角問(wèn)題如果項(xiàng)目里有子目錄源文件分布在多個(gè)目錄wildcard *.c只能搜到當(dāng)前目錄搜不到子目錄。你可以在每個(gè)子目錄里放一個(gè)子Makefile然后在根目錄Makefile里遞歸調(diào)用子make這是很多中型項(xiàng)目采用的方式。但遞歸make不是萬(wàn)靈藥跨目錄的依賴追蹤會(huì)變復(fù)雜。另一種做法是收集所有子目錄的源文件統(tǒng)一在當(dāng)前Makefile里編譯SRCS $(wildcard *.c) $(wildcard src/*.c) OBJS $(patsubst %.c,%.o,$(SRCS))這種情況下編譯生成的.o仍然放在各自源文件所在的目錄里不會(huì)污染頂層目錄。如果項(xiàng)目繼續(xù)變大、目錄越來(lái)越多我建議你還是考慮構(gòu)建系統(tǒng)比如cmake。但就算用cmake理解make和Makefile的思維模式依然是必不可少的底層能力因?yàn)閏make最終生成的可能是Makefile而且很多詭異的構(gòu)建問(wèn)題最終都要追到make那一層去查。5. 實(shí)操手記一個(gè)多文件項(xiàng)目的構(gòu)建拆解5.1 從零搭一個(gè)“有點(diǎn)真實(shí)感”的小項(xiàng)目光講語(yǔ)法用處不大我拿一個(gè)小項(xiàng)目來(lái)完整走一遍。項(xiàng)目結(jié)構(gòu)是這樣project/ ├── Makefile ├── include/ │ └── utils.h └── src/ ├── main.c └── utils.c需求main.c里調(diào)用utils.c中的函數(shù)utils.h放在include目錄下編譯時(shí)要把include目錄加進(jìn)頭文件搜索路徑。頭文件在不同目錄編譯命令里就要加-I參數(shù)。Makefile可以這么寫CC gcc CFLAGS -Wall -g -O2 -Iinclude LDFLAGS -lm SRCS $(wildcard src/*.c) OBJS $(patsubst %.c,%.o,$(SRCS)) DEPS $(patsubst %.o,%.d,$(OBJS)) TARGET app $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $ $^ %.o: %.c $(CC) $(CFLAGS) -MMD -MP -c $ -o $ clean: rm -f $(OBJS) $(DEPS) $(TARGET) -include $(DEPS) .PHONY: clean注意自動(dòng)生成的.o和.d文件都在src目錄里沒有把主目錄弄亂。執(zhí)行make輸出大致是gcc -Wall -g -O2 -Iinclude -MMD -MP -c src/main.c -o src/main.o gcc -Wall -g -O2 -Iinclude -MMD -MP -c src/utils.c -o src/utils.o gcc -lm -o app src/main.o src/utils.o我親手驗(yàn)證過(guò)這個(gè)流程編譯、鏈接、生成可執(zhí)行文件一氣呵成。然后我故意改了include/utils.h里的一個(gè)結(jié)構(gòu)體定義再次執(zhí)行make它立刻重新編譯了main.o和utils.o這正是依賴自動(dòng)生成以后的效果。5.2 編譯流程中的關(guān)鍵一步鏈接順序有兩個(gè)源文件以上就會(huì)遇到鏈接順序問(wèn)題特別是用了靜態(tài)庫(kù)的時(shí)候。比如utils.o里用了數(shù)學(xué)庫(kù)函數(shù)鏈接命令要寫成-lm放在對(duì)象文件的后面。很多新手寫鏈接命令會(huì)把庫(kù)放在最前面結(jié)果鏈接器報(bào)undefined reference錯(cuò)誤。# 錯(cuò)誤示例 gcc -lm -o app main.o utils.o # 正確示例 gcc -o app main.o utils.o -lm鏈接器是按順序掃描輸入文件的它記住的是尚未解析的符號(hào)當(dāng)它掃到app的時(shí)候還沒有看到任何對(duì)象文件掃到utils.o里的未解析符號(hào)之后再遇到-lm才能找到對(duì)應(yīng)的實(shí)現(xiàn)。把-lm放前面等于提前把庫(kù)讀了后面遇到需要解析的符號(hào)已經(jīng)來(lái)不及了。這個(gè)經(jīng)驗(yàn)我在博客里反復(fù)提過(guò)因?yàn)檎娴暮苋菀妆缓雎浴?.3 一套清晰的目錄清理方案clean目標(biāo)要記得把自動(dòng)生成的.d也刪掉否則清理后重新構(gòu)建會(huì)誤用舊的依賴信息。我前面那份Makefile里已經(jīng)包含clean: rm -f $(OBJS) $(DEPS) $(TARGET)在規(guī)模大一點(diǎn)的項(xiàng)目里我還會(huì)加一個(gè)distclean目標(biāo)用來(lái)清掉比clean更徹底的構(gòu)建產(chǎn)物比如編譯緩存目錄和.config文件。這種命名習(xí)慣來(lái)自開源社區(qū)傳統(tǒng)看到distclean一般人都能猜到它的用途。如果你自己造一個(gè)remove_all這種名字也不是不行只是別人看你的Makefile會(huì)覺得有點(diǎn)微妙。6. 命令行使用技巧和常見問(wèn)題排查實(shí)錄6.1 常用命令行參數(shù)用得順手的幾個(gè)make的命令行參數(shù)本身就是一門小課我挑幾個(gè)平時(shí)最常用的說(shuō)一下make -n打印出會(huì)執(zhí)行的命令但不真正執(zhí)行。改完Makefile想檢查一下邏輯先跑一遍-n既安全又直觀。make -B強(qiáng)制重新生成所有目標(biāo)無(wú)視時(shí)間戳。有些時(shí)候你懷疑增量編譯狀態(tài)不對(duì)可以用它做一次干凈的驗(yàn)證。make -j4并行編譯4表示同時(shí)運(yùn)行4個(gè)編譯任務(wù)?，F(xiàn)在的機(jī)器動(dòng)不動(dòng)8核16核-j$(nproc)可以直接自動(dòng)填滿CPU大型項(xiàng)目編譯時(shí)間能縮短很多。make -C dir切換到指定目錄再執(zhí)行make。在頂層腳本里遞歸調(diào)用子項(xiàng)目時(shí)很有用。make V1這個(gè)參數(shù)不是make原生參數(shù)而是在Makefile里自己支持的。通過(guò)判斷V變量來(lái)決定打印詳細(xì)編譯命令還是簡(jiǎn)化的提示信息。很多開源項(xiàng)目都支持V1輸出完整命令調(diào)試編譯選項(xiàng)的時(shí)候非常有用。6.2 幾個(gè)高頻報(bào)錯(cuò)和排查思路做一個(gè)速查表都是我或者身邊同事實(shí)際碰到過(guò)的場(chǎng)景報(bào)錯(cuò)信息常見原因解決辦法missing separator命令前面用了空格而不是Tab把空格換成真正的Tab用編輯器關(guān)閉自動(dòng)轉(zhuǎn)空格No rule to make target xxx.o對(duì)應(yīng)的.c文件不存在或路徑不對(duì)檢查SRCS收集方式確認(rèn)文件有沒有在正確目錄下target xxx doesnt match the target pattern模式規(guī)則里的%匹配不到預(yù)期內(nèi)容檢查.o和.c是否同名檢查模式規(guī)則是否寫錯(cuò)undefined reference to function鏈接順序不對(duì)或沒有鏈接對(duì)應(yīng)的庫(kù)調(diào)整庫(kù)參數(shù)順序確認(rèn)庫(kù)路徑和庫(kù)名正確file changed as we read it編譯過(guò)程中源文件被改動(dòng)了多半是編輯器后臺(tái)自動(dòng)格式化保存時(shí)沖突重新make即可make: Nothing to be done目標(biāo)已是最新沒有需要重新生成的正常情況想強(qiáng)編用make -B6.3 調(diào)試技巧打印變量和拿Makefile當(dāng)Python寫遇到變量展開不符合預(yù)期的時(shí)候最快的辦法是在Makefile里加一行$(info SRCS $(SRCS)) $(info OBJS $(OBJS))執(zhí)行make的時(shí)候這兩行會(huì)直接把變量值打印出來(lái)方便你確認(rèn)文件收集是否正確。比你在腦子里推演快得多。如果只想在調(diào)試模式下輸出還可以配合ifeq判斷ifdef DEBUG $(info CFLAGS $(CFLAGS)) endif然后執(zhí)行make DEBUG1它就會(huì)額外打印編譯選項(xiàng)。6.4 處理文件名中的“特殊情況”如果說(shuō)還有哪個(gè)地方在實(shí)際開發(fā)中經(jīng)常弄出麻煩那就是文件名或路徑里的空格。Linux下文件系統(tǒng)是允許路徑帶空格的但Makefile對(duì)空格極其敏感。如果項(xiàng)目路徑里有空格patsubst和wildcard返回的列表會(huì)被空格拆開導(dǎo)致make把一個(gè)文件名當(dāng)成兩個(gè)文件處理。一個(gè)臨時(shí)方案是給變量里的路徑加上轉(zhuǎn)義但那個(gè)寫法又長(zhǎng)又丑。更好的方案是別讓項(xiàng)目路徑帶空格這是最省事的解法。Windows下帶入路徑到Linux環(huán)境時(shí)記得檢查一下目錄名。反正我現(xiàn)在的習(xí)慣是創(chuàng)建任何開發(fā)相關(guān)目錄都只用字母、數(shù)字、下劃線絕對(duì)不用空格和中文這是從多個(gè)構(gòu)建工具不只是make的承平年代里總結(jié)出來(lái)的血淚經(jīng)驗(yàn)。7. 從Makefile到更復(fù)雜的構(gòu)建系統(tǒng)7.1 讓Makefile支持多種構(gòu)建類型如果你發(fā)現(xiàn)項(xiàng)目開始區(qū)分debug版和release版可以這樣寫B(tài)UILD ? release ifeq ($(BUILD),debug) CFLAGS -Wall -g -O0 else CFLAGS -Wall -O2 endif執(zhí)行make BUILDdebug就是調(diào)試版不帶參數(shù)默認(rèn)是release版。這種設(shè)計(jì)模式移植到其他構(gòu)建系統(tǒng)也很常見。它讓Makefile變得像一個(gè)小型配置系統(tǒng)對(duì)中小項(xiàng)目來(lái)說(shuō)夠用且高效。7.2 自動(dòng)安裝目標(biāo)實(shí)際發(fā)版的時(shí)候我還會(huì)加一個(gè)install目標(biāo)把編譯好的可執(zhí)行文件拷貝到指定目錄PREFIX ? /usr/local install: $(TARGET) install -m 755 $(TARGET) $(PREFIX)/bin/?確保用戶可以通過(guò)make install PREFIX/opt/mytool覆蓋安裝路徑。同時(shí)install目標(biāo)依賴$(TARGET)所以它會(huì)先確保編譯完成再執(zhí)行安裝命令。這樣整個(gè)構(gòu)建、安裝流程就串起來(lái)了。7.3 什么時(shí)候該從make遷移到cmakeMakefile不是萬(wàn)能的。當(dāng)項(xiàng)目開始出現(xiàn)以下信號(hào)我會(huì)認(rèn)真考慮遷移到cmake需要生成并安裝動(dòng)態(tài)庫(kù)、靜態(tài)庫(kù)、可執(zhí)行文件多種產(chǎn)物需要跨平臺(tái)Windows、Linux、macOS構(gòu)建需要處理復(fù)雜的條件編譯、第三方依賴查找項(xiàng)目多人協(xié)作希望構(gòu)建系統(tǒng)自動(dòng)探測(cè)環(huán)境。cmake通過(guò)CMakeLists.txt描述構(gòu)建邏輯能生成對(duì)應(yīng)平臺(tái)的構(gòu)建腳本比如Linux下可以生成MakefileWindows下可以生成Visual Studio工程。但學(xué)cmake前我依然建議先吃透Makefile因?yàn)閙ake的規(guī)則、依賴、變量和編譯參數(shù)這些底層概念在cmake里全都換了個(gè)形式出現(xiàn)底子不牢的話cmake里的target、interface這些抽象會(huì)讓你更迷失。8. 一些實(shí)實(shí)在在的經(jīng)驗(yàn)和碎碎念寫到這里主體內(nèi)容基本講完了。最后分享幾個(gè)我個(gè)人在實(shí)際操作中的體會(huì)希望對(duì)你有幫助。第一Makefile不是背出來(lái)的是“用”出來(lái)的。你拿一個(gè)小項(xiàng)目反復(fù)改、反復(fù)跑很快就能把語(yǔ)法記牢。我一直覺得構(gòu)建工具的掌握程度應(yīng)該以“出了問(wèn)題能不能自己查”為標(biāo)準(zhǔn)而不是能默寫多少函數(shù)名。第二調(diào)試Makefile問(wèn)題的時(shí)候先分清是“語(yǔ)法錯(cuò)誤”還是“邏輯錯(cuò)誤”。語(yǔ)法錯(cuò)誤通常一眼能瞄出來(lái)比如缺Tab、少冒號(hào)邏輯錯(cuò)誤才真正燒腦比如改動(dòng)沒觸發(fā)重編、依賴漏了頭文件。這種時(shí)候用make -d可以輸出極詳細(xì)的調(diào)試信息配合$(info ...)打印變量多試幾次總能找到癥結(jié)。第三保持Makefile簡(jiǎn)單干凈。很多人為了炫技會(huì)把Makefile寫得像腳本語(yǔ)言用一堆嵌套函數(shù)和條件判斷。其實(shí)Makefile的可維護(hù)性跟代碼一樣重要。我見過(guò)一個(gè)幾千行的“新一代”Makefile最后沒人能改得動(dòng)。克制是第一原則。第四建議你用版本管理工具管理Makefile。它就像你的源代碼一樣被多個(gè)人修改和review出了問(wèn)題可以快速回退。最后再說(shuō)一個(gè)小技巧。如果你和我一樣經(jīng)常要在一個(gè)目錄里反復(fù)調(diào)試編譯可以把debug和release兩種配置都寫在同一個(gè)Makefile里然后用一個(gè)變量去切換。我第一次用這個(gè)模式的時(shí)候還不以為意但項(xiàng)目一旦大起來(lái)這種小小的“配置化”思路會(huì)幫你省掉非常多改參數(shù)的時(shí)間。構(gòu)建工具的本質(zhì)就是讓機(jī)器去做重復(fù)勞動(dòng)人只負(fù)責(zé)定義規(guī)則。make讓這件事變得足夠輕、足夠直接所以三十多年過(guò)去了它依然是Linux開發(fā)繞不開的基本功。希望能幫你在構(gòu)建這條路上少踩幾個(gè)坑。 Makefile自動(dòng)化構(gòu)建實(shí)戰(zhàn)：從核心語(yǔ)法到工程實(shí)踐
1. 從一段真實(shí)經(jīng)歷說(shuō)起為什么你需要make老手可能早就離不開make了但如果你是剛接觸Linux開發(fā)的新手或者一直用小項(xiàng)目、單文件代碼“裸編”過(guò)來(lái)的那我建議你認(rèn)真看完這篇文章。我當(dāng)年第一次接手一個(gè)稍微像樣一點(diǎn)的C項(xiàng)目幾十個(gè)源文件需要在終端里一條一條敲gcc命令頭文件改一個(gè)就要重新編譯一堆文件編譯選項(xiàng)還特別長(zhǎng)偶爾敲錯(cuò)一個(gè)參數(shù)就得從頭排查。那段時(shí)間每次“編一下跑一下”都像在玩掃雷整個(gè)人都很痛苦。后來(lái)某位同事讓我看了他項(xiàng)目里的Makefile我才反應(yīng)過(guò)來(lái)這東西就是在幫你把編譯、打包、清理這些重復(fù)勞動(dòng)全部自動(dòng)化。簡(jiǎn)單說(shuō)make是一個(gè)自動(dòng)化構(gòu)建工具而Makefile是給make讀的“構(gòu)建劇本”里面寫清楚目標(biāo)文件怎么生成、依賴哪些源文件、用什么命令生成。有了它你在終端里只需要敲一個(gè) make剩下的編譯、鏈接、輸出可執(zhí)行文件全部自動(dòng)完成。就算改了十幾個(gè)文件make也能精準(zhǔn)識(shí)別哪些需要重編哪些不用動(dòng)比全量重編快得多。這篇文章我不會(huì)跟你念man手冊(cè)。我只講兩件事一是Makefile的底層邏輯和核心語(yǔ)法到底怎么用二是我在實(shí)際項(xiàng)目里踩過(guò)的坑、驗(yàn)證過(guò)的寫法。按這套思路走不管你之后是做嵌入式、Linux服務(wù)端、還是搞開源項(xiàng)目都能很快寫出能用的Makefile并且知道每行在干什么。2. Makefile三要素目標(biāo)、依賴、命令之間的關(guān)系2.1 先把三要素掰開揉碎所有Makefile不管寫得多花哨本質(zhì)都是若干個(gè)“規(guī)則”。一條規(guī)則長(zhǎng)這樣target: prerequisites command三部分分別是目標(biāo)target你要生成的東西可以是一個(gè)可執(zhí)行文件、一個(gè).o文件也可以是一個(gè)動(dòng)作名比如clean。依賴prerequisites生成目標(biāo)之前必須具備的文件或其他目標(biāo)。多個(gè)依賴之間用空格分隔。命令command真正干活的shell命令通常就是編譯、鏈接、拷貝這些。命令前面必須是一個(gè)Tab縮進(jìn)不是四個(gè)空格不是兩個(gè)空格是Tab。這個(gè)坑我后面單獨(dú)說(shuō)因?yàn)閹缀跛行率侄荚谶@里翻車。舉一個(gè)最直觀的例子hello: hello.o gcc -o hello hello.o hello.o: hello.c gcc -c hello.c -o hello.o第一條規(guī)則說(shuō)要生成hello就得先有hello.o然后執(zhí)行g(shù)cc把hello.o鏈接成可執(zhí)行文件hello。第二條規(guī)則說(shuō)要生成hello.o得有hello.c然后執(zhí)行g(shù)cc把hello.c編譯成hello.o。你在終端敲make的時(shí)候make會(huì)先讀Makefile找到第一個(gè)目標(biāo)hello然后檢查它的依賴hello.o。如果hello.o不存在make就會(huì)去找hello.o對(duì)應(yīng)的規(guī)則先編譯出hello.o再回來(lái)鏈接出hello。整個(gè)過(guò)程是自動(dòng)遞歸的很像一個(gè)“依賴樹”。這是理解make工作的關(guān)鍵它不是一個(gè)簡(jiǎn)單的從左到右執(zhí)行腳本的工具而是以目標(biāo)為導(dǎo)向先算依賴關(guān)系再?zèng)Q定執(zhí)行哪些命令。2.2 make真正厲害的地方增量編譯不用make的時(shí)候手動(dòng)編譯最煩的就是每次都要把全部文件重新編一遍。大型項(xiàng)目幾十個(gè)文件還好幾百個(gè)文件的時(shí)候一次全量編譯可能要幾分鐘甚至十幾分鐘而你只是改了一行代碼。make天生就是為了解決這個(gè)問(wèn)題——它通過(guò)比較目標(biāo)文件和依賴文件的時(shí)間戳來(lái)決定是否重新生成目標(biāo)。舉個(gè)具體的流程你改了一個(gè)源文件那個(gè)文件對(duì)應(yīng)的.o目標(biāo)文件的時(shí)間戳就會(huì)比源文件舊make發(fā)現(xiàn)“哦這個(gè)目標(biāo)過(guò)期了”于是只重新編譯這個(gè)源文件。其他沒改動(dòng)的文件目標(biāo)比依賴新make直接跳過(guò)。最后再重新鏈接一次。這就是增量編譯幾百個(gè)文件的項(xiàng)目修改單個(gè)文件后的構(gòu)建可能只需要幾秒鐘實(shí)際效果很驚人。2.3 命令行里的空格與Tab問(wèn)題說(shuō)實(shí)話這是我在各種技術(shù)社區(qū)里看到最多、最經(jīng)典的報(bào)錯(cuò)現(xiàn)場(chǎng)Makefile:3: *** missing separator. Stop.這個(gè)錯(cuò)誤幾乎都是命令前面用了空格而不是Tab。為什么make只認(rèn)Tab這是歷史設(shè)計(jì)問(wèn)題但你必須接受它。很多編輯器會(huì)在配置里默認(rèn)把Tab轉(zhuǎn)換成空格這就會(huì)讓你的Makefile“看起來(lái)對(duì)齊了但實(shí)際沒法跑”。我目前的習(xí)慣是用Vim寫Makefile的時(shí)候在.vimrc里強(qiáng)行關(guān)閉expandtab并且設(shè)置自動(dòng)縮進(jìn)寬度為8用VS Code就把editor.insertSpaces設(shè)為false保證編輯的文件里插入的是真正的Tab字符。如果實(shí)在判斷不清可以在Vim里輸入set listTab字符會(huì)顯示為^I空格是普通的小點(diǎn)一眼就能分辨。2.4 偽目標(biāo)清理操作的隱藏陷阱你可能已經(jīng)注意到我前面提到的clean目標(biāo)并不是一個(gè)真實(shí)文件名。它只是一個(gè)動(dòng)作標(biāo)簽。如果你真的在目錄里放了一個(gè)叫clean的文件再執(zhí)行make clean的時(shí)候make會(huì)發(fā)現(xiàn)clean這個(gè)“目標(biāo)”已經(jīng)存在了而且沒有依賴時(shí)間戳永遠(yuǎn)比依賴新于是它直接告訴你“clean是最新的”不會(huì)執(zhí)行rm命令。解決這個(gè)問(wèn)題的標(biāo)準(zhǔn)寫法就是..PHONY: clean clean: rm -f *.o hello.PHONY的完整形式是.PHONY: clean嗎其實(shí)標(biāo)準(zhǔn)寫法是clean:本身就是規(guī)則目標(biāo)而.PHONY: clean這行是聲明格式就是clean:后面跟你的規(guī)則。這行聲明告訴makeclean不能當(dāng)作文件名來(lái)看待它的作用是“命令標(biāo)簽”每次都要執(zhí)行就算同名文件已經(jīng)存在也一樣執(zhí)行。不僅clean像all、install、test這種動(dòng)作型目標(biāo)都建議聲明為.PHONY防止和同名文件沖突。3. 變量和自動(dòng)化變量讓Makefile從“寫死”變“通用”3.1 用變量管好你自己的編譯參數(shù)剛開始寫Makefile的時(shí)候你可能會(huì)把編譯命令一行行寫死比如每個(gè).o規(guī)則都是gcc -Wall -g -c xxx.c -o xxx.o。三個(gè)文件還行十幾個(gè)文件的時(shí)候你光改一個(gè)編譯選項(xiàng)比如加一個(gè)-stdc99就得改十幾行而且很容易漏。變量的引入就是為了解決這種重復(fù)勞動(dòng)。Makefile里的變量定義和引用很有特點(diǎn)CC gcc CFLAGS -Wall -g -O2 -stdc99 LDFLAGS -lm hello: hello.o utils.o $(CC) $(LDFLAGS) -o hello hello.o utils.o hello.o: hello.c $(CC) $(CFLAGS) -c hello.c -o hello.o utils.o: utils.c $(CC) $(CFLAGS) -c utils.c -o utils.o變量用定義用$(變量名)引用。這樣修改編譯器或者編譯選項(xiàng)的時(shí)候只需要改開頭那幾行后面的規(guī)則全部自動(dòng)生效。把變量定義集中到Makefile頂部幾乎可以算是一種行業(yè)習(xí)慣你去看那些開源項(xiàng)目基本鋪滿了一堆變量定義。變量賦值還有幾種寫法我用過(guò)一次就比較有印象遞歸展開式賦值變量的值是“最后時(shí)刻”的展開結(jié)果。比如A $(B) B hello這時(shí)$(A)展開之后是hello因?yàn)橹钡秸嬲褂玫臅r(shí)候才去解析B的值。:直接展開式賦值立刻把右邊的值計(jì)算好存下來(lái)。如果你想避免循環(huán)引用和二次解析帶來(lái)的意外用:更穩(wěn)。?如果變量之前沒有賦值就給它賦這個(gè)值常用于讓用戶可以通過(guò)命令行覆蓋默認(rèn)參數(shù)。追加內(nèi)容適合分步添加編譯選項(xiàng)。我自己寫Makefile的時(shí)候一旦涉及多個(gè)相互引用的變量都會(huì)傾向用:因?yàn)檫@樣變量的解析是確定的不會(huì)因?yàn)橘x值順序不同而出現(xiàn)詭異的展開結(jié)果。你可以把理解成“活引用”:是“快照”大多數(shù)場(chǎng)景下快照更可控。3.2 自動(dòng)化變量自動(dòng)化變量的實(shí)操價(jià)值手動(dòng)在每條規(guī)則里把目標(biāo)名和依賴名都寫一遍依然是重復(fù)勞動(dòng)。make提供了一套自動(dòng)化變量專用來(lái)在規(guī)則命令中表示目標(biāo)、依賴等信息最常用的有三個(gè)$表示當(dāng)前規(guī)則的目標(biāo)文件名。$^表示當(dāng)前規(guī)則的所有依賴文件名會(huì)自動(dòng)去重。$表示當(dāng)前規(guī)則的第一個(gè)依賴文件名。拿前面的例子重寫立刻會(huì)清爽很多hello: hello.o utils.o $(CC) $(LDFLAGS) -o $ $^ hello.o: hello.c $(CC) $(CFLAGS) -c $ -o $ utils.o: utils.c $(CC) $(CFLAGS) -c $ -o $第一條規(guī)則里$會(huì)被替換成hello$^變成hello.o utils.o。第二條規(guī)則里$是hello.c$是hello.o。這樣不管以后新增多少源文件規(guī)則主體幾乎不用改。還有兩個(gè)不那么常用但偶爾能救命的$?比當(dāng)前目標(biāo)更新的依賴文件列表常用于部署場(chǎng)景比如只在某些源文件變化后重新執(zhí)行歸檔命令。$*模式匹配中匹配到的那部分文件名后面講模式規(guī)則時(shí)會(huì)用到。3.3 通配符和模式規(guī)則批量處理源文件沒有模式規(guī)則之前每個(gè).c文件都要對(duì)應(yīng)一條獨(dú)立的編譯規(guī)則項(xiàng)目里幾十個(gè)源文件就得復(fù)制幾十條看著就累。make支持模式規(guī)則用%做通配符可以把一類文件的構(gòu)建規(guī)則濃縮成一條。%.o: %.c $(CC) $(CFLAGS) -c $ -o $這行規(guī)則的含義是任何.o文件只要有一個(gè)同名的.c文件作為依賴就用后面這條命令編譯。加上之前講的目標(biāo)規(guī)則整個(gè)Makefile可以濃縮成CC gcc CFLAGS -Wall -g -O2 LDFLAGS -lm OBJS hello.o utils.o hello: $(OBJS) $(CC) $(LDFLAGS) -o $ $^ %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: rm -f $(OBJS) hello .PHONY: clean這個(gè)Makefile已經(jīng)接近我平時(shí)使用的實(shí)際形態(tài)了。新增一個(gè)源文件的時(shí)候我只需要在OBJS變量里加一個(gè)對(duì)應(yīng)的.o文件名其他都不用動(dòng)。這才是自動(dòng)化構(gòu)建工具該有的效率。但是手動(dòng)維護(hù)OBJS這個(gè)列表還是有一點(diǎn)讓人不放心——如果忘了把新文件加進(jìn)去make不會(huì)自動(dòng)感知新出現(xiàn)的.c文件。更好的辦法是用函數(shù)自動(dòng)收集目錄下所有源文件。4. 函數(shù)和include讓Makefile自己學(xué)會(huì)找文件4.1 wildcard和patsubst兩個(gè)高頻函數(shù)make內(nèi)置了不少函數(shù)寫法看起來(lái)像變量引用但帶個(gè)符號(hào)。我平常用得最多的是這兩個(gè)SRCS $(wildcard *.c) OBJS $(patsubst %.c,%.o,$(SRCS))$(wildcard *.c)查找當(dāng)前目錄下所有.c文件返回一個(gè)以空格分隔的文件名列表。就算新拖進(jìn)來(lái)一個(gè)源文件SRCS也會(huì)自動(dòng)帶上它你完全不用手動(dòng)維護(hù)。$(patsubst %.c,%.o,$(SRCS))把SRCS里每個(gè).c后綴替換成.o后綴得到對(duì)應(yīng)的目標(biāo)文件列表。這樣整個(gè)Makefile就可以改成CC gcc CFLAGS -Wall -g -O2 LDFLAGS -lm SRCS $(wildcard *.c) OBJS $(patsubst %.c,%.o,$(SRCS)) TARGET app $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $ $^ %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: rm -f $(OBJS) $(TARGET) .PHONY: clean這個(gè)版本已經(jīng)具備“項(xiàng)目級(jí)”感覺了。你把任意一個(gè)只有.c文件的目錄交給它它都能自動(dòng)識(shí)別并構(gòu)建出可執(zhí)行文件app。但別太高興這套寫法有一個(gè)大問(wèn)題它完全沒有處理頭文件依賴。如果你修改了一個(gè)頭文件只有include這個(gè)頭文件的.c文件才會(huì)檢測(cè)到變化嗎不會(huì)。make只比較.c和.o的時(shí)間戳根本不知道頭文件參與其中。這就引出了Makefile里最隱蔽、也最容易引發(fā)線上問(wèn)題的topic之一。4.2 頭文件依賴大部分新手栽跟頭的地方舉個(gè)例子main.c里include了utils.h你改了utils.h里的一個(gè)宏定義期望main.o重新編譯。但make會(huì)發(fā)現(xiàn)main.c沒有變main.o和main.c的時(shí)間戳相比沒過(guò)期于是它直接不重新編譯main.o最后鏈接出來(lái)的程序還是老版本。這種“改了沒反應(yīng)”的問(wèn)題非常隱蔽查起來(lái)也費(fèi)勁。解決思路是讓.o的依賴?yán)锇黫nclude的所有頭文件。你可以手動(dòng)寫main.o: main.c utils.h但每個(gè)文件include哪些頭文件多了之后手動(dòng)維護(hù)完全不堪重負(fù)還不如讓編譯器幫你統(tǒng)計(jì)。GCC提供了-MM選項(xiàng)可以輸出源文件對(duì)應(yīng)的頭文件依賴列表gcc -MM main.c輸出大概是main.o: main.c utils.h common.h這正好是make能用的依賴規(guī)則。利用GCC的-M家族選項(xiàng)可以讓Makefile自動(dòng)生成并包含這些依賴信息。目前我見過(guò)、也實(shí)際使用的是下面這套方案SRCS $(wildcard *.c) OBJS $(patsubst %.c,%.o,$(SRCS)) DEPS $(patsubst %.o,%.d,$(OBJS)) %.o: %.c $(CC) $(CFLAGS) -MMD -MP -c $ -o $ -include $(DEPS)-MMD在編譯的同時(shí)生成一個(gè).d文件里面記錄當(dāng)前.c文件包含的頭文件依賴。-MP為每個(gè)頭文件生成一個(gè)空的偽目標(biāo)防止頭文件被刪除后make報(bào)錯(cuò)找不到規(guī)則。-include和include不同即使.d文件不存在比如第一次清理后也不會(huì)報(bào)錯(cuò)make會(huì)繼續(xù)執(zhí)行。每次編譯時(shí).d文件都會(huì)被刷新頭文件依賴自動(dòng)更新。你再也不用手動(dòng)維護(hù)頭文件列表了。這套方案從我第一次用到現(xiàn)在一直很穩(wěn)幾乎成了我的標(biāo)準(zhǔn)配置。4.3 小心make的天然“遞歸陷阱”自動(dòng)化收集源文件還有個(gè)邊角問(wèn)題如果項(xiàng)目里有子目錄源文件分布在多個(gè)目錄wildcard *.c只能搜到當(dāng)前目錄搜不到子目錄。你可以在每個(gè)子目錄里放一個(gè)子Makefile然后在根目錄Makefile里遞歸調(diào)用子make這是很多中型項(xiàng)目采用的方式。但遞歸make不是萬(wàn)靈藥跨目錄的依賴追蹤會(huì)變復(fù)雜。另一種做法是收集所有子目錄的源文件統(tǒng)一在當(dāng)前Makefile里編譯SRCS $(wildcard *.c) $(wildcard src/*.c) OBJS $(patsubst %.c,%.o,$(SRCS))這種情況下編譯生成的.o仍然放在各自源文件所在的目錄里不會(huì)污染頂層目錄。如果項(xiàng)目繼續(xù)變大、目錄越來(lái)越多我建議你還是考慮構(gòu)建系統(tǒng)比如cmake。但就算用cmake理解make和Makefile的思維模式依然是必不可少的底層能力因?yàn)閏make最終生成的可能是Makefile而且很多詭異的構(gòu)建問(wèn)題最終都要追到make那一層去查。5. 實(shí)操手記一個(gè)多文件項(xiàng)目的構(gòu)建拆解5.1 從零搭一個(gè)“有點(diǎn)真實(shí)感”的小項(xiàng)目光講語(yǔ)法用處不大我拿一個(gè)小項(xiàng)目來(lái)完整走一遍。項(xiàng)目結(jié)構(gòu)是這樣project/ ├── Makefile ├── include/ │ └── utils.h └── src/ ├── main.c └── utils.c需求main.c里調(diào)用utils.c中的函數(shù)utils.h放在include目錄下編譯時(shí)要把include目錄加進(jìn)頭文件搜索路徑。頭文件在不同目錄編譯命令里就要加-I參數(shù)。Makefile可以這么寫CC gcc CFLAGS -Wall -g -O2 -Iinclude LDFLAGS -lm SRCS $(wildcard src/*.c) OBJS $(patsubst %.c,%.o,$(SRCS)) DEPS $(patsubst %.o,%.d,$(OBJS)) TARGET app $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $ $^ %.o: %.c $(CC) $(CFLAGS) -MMD -MP -c $ -o $ clean: rm -f $(OBJS) $(DEPS) $(TARGET) -include $(DEPS) .PHONY: clean注意自動(dòng)生成的.o和.d文件都在src目錄里沒有把主目錄弄亂。執(zhí)行make輸出大致是gcc -Wall -g -O2 -Iinclude -MMD -MP -c src/main.c -o src/main.o gcc -Wall -g -O2 -Iinclude -MMD -MP -c src/utils.c -o src/utils.o gcc -lm -o app src/main.o src/utils.o我親手驗(yàn)證過(guò)這個(gè)流程編譯、鏈接、生成可執(zhí)行文件一氣呵成。然后我故意改了include/utils.h里的一個(gè)結(jié)構(gòu)體定義再次執(zhí)行make它立刻重新編譯了main.o和utils.o這正是依賴自動(dòng)生成以后的效果。5.2 編譯流程中的關(guān)鍵一步鏈接順序有兩個(gè)源文件以上就會(huì)遇到鏈接順序問(wèn)題特別是用了靜態(tài)庫(kù)的時(shí)候。比如utils.o里用了數(shù)學(xué)庫(kù)函數(shù)鏈接命令要寫成-lm放在對(duì)象文件的后面。很多新手寫鏈接命令會(huì)把庫(kù)放在最前面結(jié)果鏈接器報(bào)undefined reference錯(cuò)誤。# 錯(cuò)誤示例 gcc -lm -o app main.o utils.o # 正確示例 gcc -o app main.o utils.o -lm鏈接器是按順序掃描輸入文件的它記住的是尚未解析的符號(hào)當(dāng)它掃到app的時(shí)候還沒有看到任何對(duì)象文件掃到utils.o里的未解析符號(hào)之后再遇到-lm才能找到對(duì)應(yīng)的實(shí)現(xiàn)。把-lm放前面等于提前把庫(kù)讀了后面遇到需要解析的符號(hào)已經(jīng)來(lái)不及了。這個(gè)經(jīng)驗(yàn)我在博客里反復(fù)提過(guò)因?yàn)檎娴暮苋菀妆缓雎浴?.3 一套清晰的目錄清理方案clean目標(biāo)要記得把自動(dòng)生成的.d也刪掉否則清理后重新構(gòu)建會(huì)誤用舊的依賴信息。我前面那份Makefile里已經(jīng)包含clean: rm -f $(OBJS) $(DEPS) $(TARGET)在規(guī)模大一點(diǎn)的項(xiàng)目里我還會(huì)加一個(gè)distclean目標(biāo)用來(lái)清掉比clean更徹底的構(gòu)建產(chǎn)物比如編譯緩存目錄和.config文件。這種命名習(xí)慣來(lái)自開源社區(qū)傳統(tǒng)看到distclean一般人都能猜到它的用途。如果你自己造一個(gè)remove_all這種名字也不是不行只是別人看你的Makefile會(huì)覺得有點(diǎn)微妙。6. 命令行使用技巧和常見問(wèn)題排查實(shí)錄6.1 常用命令行參數(shù)用得順手的幾個(gè)make的命令行參數(shù)本身就是一門小課我挑幾個(gè)平時(shí)最常用的說(shuō)一下make -n打印出會(huì)執(zhí)行的命令但不真正執(zhí)行。改完Makefile想檢查一下邏輯先跑一遍-n既安全又直觀。make -B強(qiáng)制重新生成所有目標(biāo)無(wú)視時(shí)間戳。有些時(shí)候你懷疑增量編譯狀態(tài)不對(duì)可以用它做一次干凈的驗(yàn)證。make -j4并行編譯4表示同時(shí)運(yùn)行4個(gè)編譯任務(wù)?，F(xiàn)在的機(jī)器動(dòng)不動(dòng)8核16核-j$(nproc)可以直接自動(dòng)填滿CPU大型項(xiàng)目編譯時(shí)間能縮短很多。make -C dir切換到指定目錄再執(zhí)行make。在頂層腳本里遞歸調(diào)用子項(xiàng)目時(shí)很有用。make V1這個(gè)參數(shù)不是make原生參數(shù)而是在Makefile里自己支持的。通過(guò)判斷V變量來(lái)決定打印詳細(xì)編譯命令還是簡(jiǎn)化的提示信息。很多開源項(xiàng)目都支持V1輸出完整命令調(diào)試編譯選項(xiàng)的時(shí)候非常有用。6.2 幾個(gè)高頻報(bào)錯(cuò)和排查思路做一個(gè)速查表都是我或者身邊同事實(shí)際碰到過(guò)的場(chǎng)景報(bào)錯(cuò)信息常見原因解決辦法missing separator命令前面用了空格而不是Tab把空格換成真正的Tab用編輯器關(guān)閉自動(dòng)轉(zhuǎn)空格No rule to make target xxx.o對(duì)應(yīng)的.c文件不存在或路徑不對(duì)檢查SRCS收集方式確認(rèn)文件有沒有在正確目錄下target xxx doesnt match the target pattern模式規(guī)則里的%匹配不到預(yù)期內(nèi)容檢查.o和.c是否同名檢查模式規(guī)則是否寫錯(cuò)undefined reference to function鏈接順序不對(duì)或沒有鏈接對(duì)應(yīng)的庫(kù)調(diào)整庫(kù)參數(shù)順序確認(rèn)庫(kù)路徑和庫(kù)名正確file changed as we read it編譯過(guò)程中源文件被改動(dòng)了多半是編輯器后臺(tái)自動(dòng)格式化保存時(shí)沖突重新make即可make: Nothing to be done目標(biāo)已是最新沒有需要重新生成的正常情況想強(qiáng)編用make -B6.3 調(diào)試技巧打印變量和拿Makefile當(dāng)Python寫遇到變量展開不符合預(yù)期的時(shí)候最快的辦法是在Makefile里加一行$(info SRCS $(SRCS)) $(info OBJS $(OBJS))執(zhí)行make的時(shí)候這兩行會(huì)直接把變量值打印出來(lái)方便你確認(rèn)文件收集是否正確。比你在腦子里推演快得多。如果只想在調(diào)試模式下輸出還可以配合ifeq判斷ifdef DEBUG $(info CFLAGS $(CFLAGS)) endif然后執(zhí)行make DEBUG1它就會(huì)額外打印編譯選項(xiàng)。6.4 處理文件名中的“特殊情況”如果說(shuō)還有哪個(gè)地方在實(shí)際開發(fā)中經(jīng)常弄出麻煩那就是文件名或路徑里的空格。Linux下文件系統(tǒng)是允許路徑帶空格的但Makefile對(duì)空格極其敏感。如果項(xiàng)目路徑里有空格patsubst和wildcard返回的列表會(huì)被空格拆開導(dǎo)致make把一個(gè)文件名當(dāng)成兩個(gè)文件處理。一個(gè)臨時(shí)方案是給變量里的路徑加上轉(zhuǎn)義但那個(gè)寫法又長(zhǎng)又丑。更好的方案是別讓項(xiàng)目路徑帶空格這是最省事的解法。Windows下帶入路徑到Linux環(huán)境時(shí)記得檢查一下目錄名。反正我現(xiàn)在的習(xí)慣是創(chuàng)建任何開發(fā)相關(guān)目錄都只用字母、數(shù)字、下劃線絕對(duì)不用空格和中文這是從多個(gè)構(gòu)建工具不只是make的承平年代里總結(jié)出來(lái)的血淚經(jīng)驗(yàn)。7. 從Makefile到更復(fù)雜的構(gòu)建系統(tǒng)7.1 讓Makefile支持多種構(gòu)建類型如果你發(fā)現(xiàn)項(xiàng)目開始區(qū)分debug版和release版可以這樣寫B(tài)UILD ? release ifeq ($(BUILD),debug) CFLAGS -Wall -g -O0 else CFLAGS -Wall -O2 endif執(zhí)行make BUILDdebug就是調(diào)試版不帶參數(shù)默認(rèn)是release版。這種設(shè)計(jì)模式移植到其他構(gòu)建系統(tǒng)也很常見。它讓Makefile變得像一個(gè)小型配置系統(tǒng)對(duì)中小項(xiàng)目來(lái)說(shuō)夠用且高效。7.2 自動(dòng)安裝目標(biāo)實(shí)際發(fā)版的時(shí)候我還會(huì)加一個(gè)install目標(biāo)把編譯好的可執(zhí)行文件拷貝到指定目錄PREFIX ? /usr/local install: $(TARGET) install -m 755 $(TARGET) $(PREFIX)/bin/?確保用戶可以通過(guò)make install PREFIX/opt/mytool覆蓋安裝路徑。同時(shí)install目標(biāo)依賴$(TARGET)所以它會(huì)先確保編譯完成再執(zhí)行安裝命令。這樣整個(gè)構(gòu)建、安裝流程就串起來(lái)了。7.3 什么時(shí)候該從make遷移到cmakeMakefile不是萬(wàn)能的。當(dāng)項(xiàng)目開始出現(xiàn)以下信號(hào)我會(huì)認(rèn)真考慮遷移到cmake需要生成并安裝動(dòng)態(tài)庫(kù)、靜態(tài)庫(kù)、可執(zhí)行文件多種產(chǎn)物需要跨平臺(tái)Windows、Linux、macOS構(gòu)建需要處理復(fù)雜的條件編譯、第三方依賴查找項(xiàng)目多人協(xié)作希望構(gòu)建系統(tǒng)自動(dòng)探測(cè)環(huán)境。cmake通過(guò)CMakeLists.txt描述構(gòu)建邏輯能生成對(duì)應(yīng)平臺(tái)的構(gòu)建腳本比如Linux下可以生成MakefileWindows下可以生成Visual Studio工程。但學(xué)cmake前我依然建議先吃透Makefile因?yàn)閙ake的規(guī)則、依賴、變量和編譯參數(shù)這些底層概念在cmake里全都換了個(gè)形式出現(xiàn)底子不牢的話cmake里的target、interface這些抽象會(huì)讓你更迷失。8. 一些實(shí)實(shí)在在的經(jīng)驗(yàn)和碎碎念寫到這里主體內(nèi)容基本講完了。最后分享幾個(gè)我個(gè)人在實(shí)際操作中的體會(huì)希望對(duì)你有幫助。第一Makefile不是背出來(lái)的是“用”出來(lái)的。你拿一個(gè)小項(xiàng)目反復(fù)改、反復(fù)跑很快就能把語(yǔ)法記牢。我一直覺得構(gòu)建工具的掌握程度應(yīng)該以“出了問(wèn)題能不能自己查”為標(biāo)準(zhǔn)而不是能默寫多少函數(shù)名。第二調(diào)試Makefile問(wèn)題的時(shí)候先分清是“語(yǔ)法錯(cuò)誤”還是“邏輯錯(cuò)誤”。語(yǔ)法錯(cuò)誤通常一眼能瞄出來(lái)比如缺Tab、少冒號(hào)邏輯錯(cuò)誤才真正燒腦比如改動(dòng)沒觸發(fā)重編、依賴漏了頭文件。這種時(shí)候用make -d可以輸出極詳細(xì)的調(diào)試信息配合$(info ...)打印變量多試幾次總能找到癥結(jié)。第三保持Makefile簡(jiǎn)單干凈。很多人為了炫技會(huì)把Makefile寫得像腳本語(yǔ)言用一堆嵌套函數(shù)和條件判斷。其實(shí)Makefile的可維護(hù)性跟代碼一樣重要。我見過(guò)一個(gè)幾千行的“新一代”Makefile最后沒人能改得動(dòng)。克制是第一原則。第四建議你用版本管理工具管理Makefile。它就像你的源代碼一樣被多個(gè)人修改和review出了問(wèn)題可以快速回退。最后再說(shuō)一個(gè)小技巧。如果你和我一樣經(jīng)常要在一個(gè)目錄里反復(fù)調(diào)試編譯可以把debug和release兩種配置都寫在同一個(gè)Makefile里然后用一個(gè)變量去切換。我第一次用這個(gè)模式的時(shí)候還不以為意但項(xiàng)目一旦大起來(lái)這種小小的“配置化”思路會(huì)幫你省掉非常多改參數(shù)的時(shí)間。構(gòu)建工具的本質(zhì)就是讓機(jī)器去做重復(fù)勞動(dòng)人只負(fù)責(zé)定義規(guī)則。make讓這件事變得足夠輕、足夠直接所以三十多年過(guò)去了它依然是Linux開發(fā)繞不開的基本功。希望能幫你在構(gòu)建這條路上少踩幾個(gè)坑。