你的Makefile里是不是也有這種情節(jié)同一個編譯規(guī)則復制粘貼了十幾遍只改一下模塊名和文件路徑我承認我干過而且是在一個模擬項目的三十多個子模塊上干的每次新增模塊都要手動補規(guī)則、補依賴、補清理清單漏一條就讓你在深夜對著構建日志發(fā)呆。后來真正把GNU Makefile里的eval函數(shù)用起來才找到治本的辦法把規(guī)則寫成模板讓make自己在解析階段批量生成。eval的定位很樸素——它接收一段文本把這段文本當作makefile內容現(xiàn)場解析配合define、call、foreach就能實現(xiàn)自動生成規(guī)則。這篇文章把從最小例子到生產級坑點的完整路徑走一遍適合正在維護多模塊構建、已經受夠手寫重復規(guī)則的人。1. 從第30條重復規(guī)則說起eval到底幫我省了什么1.1 手工規(guī)則膨脹的典型現(xiàn)場我維護過一個模擬項目的構建腳本結構大概是這樣的十幾個子模塊每個模塊都要先編譯成目標文件再鏈接成可執(zhí)行程序還要有一堆按模塊區(qū)分的測試入口。手工寫下去Makefile長這樣build/alpha.o: src/alpha.c $(CC) $(CFLAGS) -c $ -o $ build/alpha.bin: build/alpha.o $(CC) $(LDFLAGS) $^ -o $ build/beta.o: src/beta.c $(CC) $(CFLAGS) -c $ -o $ build/beta.bin: build/beta.o $(CC) $(LDFLAGS) $^ -o $模塊一多文件就變成規(guī)則海洋。問題不在于多寫了幾行而在于每次改構建策略都要同步改幾十處某天我把CFLAGS統(tǒng)一加了一個-Werror就得保證所有編譯規(guī)則都改到某個新模塊忘記寫目錄依賴第一次構建必掛。最要命的是這類文件沒法review出結構大家只會逐行看有沒有拼錯。復制粘貼還有一個隱形成本它讓規(guī)則的一致性變成了一種人工約定。只要有一次只改了A模塊沒改B模塊后續(xù)的構建產物就開始悄悄不一致。我后來統(tǒng)計過手工維護階段這類漏改導致的構建問題占了一半以上。1.2 eval在make里的真正位置簡單說make在執(zhí)行recipe之前要先花一段時間把整個makefile讀進來解析變量、規(guī)則、依賴構建出一張依賴圖這個過程叫讀入階段。eval就是在讀入階段生效的——它把一段文本現(xiàn)場變成makefile文本再現(xiàn)場解析。你可以把它理解為在makefile內部裝了一個宏處理器。這跟函數(shù)式編程里的代碼生成代碼很像eval先把模板里的占位符換成真實值生成一段makefile片段然后這段片段和手寫的規(guī)則沒有任何區(qū)別會被make當成普通規(guī)則加入依賴圖。所以生成的規(guī)則和手寫的規(guī)則是平級的后續(xù)的依賴解析、并行構建、make -n試運行全都一視同仁。需要注意這是GNU Make的功能特性。BSD make、nmake這類工具要么沒有對應的eval要么語法完全不同。如果項目明確要求跨多種make工具移植用eval之前要想清楚或者評估能否接受僅支持GNU Make這個前提。1.3 什么項目值得上eval兩道判斷題我一般用兩個問題來判斷這些規(guī)則是不是同構的也就是除了名字、路徑、參數(shù)不同結構完全一樣。數(shù)量是不是大到手動維護會出錯一般來說超過五六個同構目標就開始值得了。如果目標少于五個而且每個規(guī)則差異都很大比如有的要調內置工具、有的要跑外部腳本、有的要特殊后處理那強行套eval反而把簡單問題復雜化。eval最適合的場景是大量同構目標 少量差異化參數(shù)這時候它才能把規(guī)則的重復度壓到最低讓新增模塊變成一行列表項。團隊對GNU Make的接受度也要考慮。如果整個構建體系里已經大量使用了$(call)、$(foreach)這類函數(shù)式語法那么引入eval幾乎沒有額外學習成本。如果團隊還停留在makefile就是寫規(guī)則的認知上那這篇文章后面的內容反而是最好的入門教材。2. 先跑通再理解define、call與make的兩遍解析2.1 最小可復現(xiàn)例子先從最簡單的例子跑通。下面這個makefile定義了一個模板生成兩個目標define greeting_rule say_$(1): echo hello, $$ endef $(eval $(call greeting_rule,one)) $(eval $(call greeting_rule,two))這里有個關鍵細節(jié)say_$(1):下面那行recipe縮進必須是真實的Tab字符不是空格。define/endef會把中間的內容原樣保存包括這個Tabeval解析時才能認出它是recipe。運行make say_one你應該看到hello, say_one這短短幾行里其實串起了四個概念define定義多行變量$(1)是模板參數(shù)占位符$(call ...)把參數(shù)傳入模板$(eval ...)把展開后的文本當作makefile內容解析。整條鏈路就是模板 - 替換 - 解析。我把這個例子拆開說是因為很多人一上來就寫復雜模板結果編譯報錯也不知道是語法問題還是轉義問題。先把最小鏈路跑通再往上加東西排查范圍會小很多。2.2 兩遍解析讀入期與執(zhí)行期理解eval必須理解make處理makefile的兩遍過程。第一遍是讀入期。make逐行讀取makefile解析變量賦值、規(guī)則定義、依賴關系最終形成一張完整的依賴圖。$(eval ...)調用就發(fā)生在這一遍它邊生成文本邊解析相當于在讀入過程中不斷往依賴圖里追加內容。第二遍是執(zhí)行期。make拿到依賴圖之后檢查哪些目標過期然后按依賴順序執(zhí)行recipe。注意recipe里的變量不是讀入期就展開的而是延遲到執(zhí)行期、每一條shell命令執(zhí)行前才展開。這就是recipe延遲展開機制。這兩遍分開的代價是eval的參數(shù)本身會被make先展開一次。寫$(eval $(call xxx))的時候make會先把$(call xxx)展開成一段makefile文本然后才去解析這段文本。所以模板里凡是想原樣留給執(zhí)行期的變量引用都必須多寫一個$。這直接引出下面這個最容易被繞暈的轉義問題。2.3 立即展開、延遲展開與那對$$我見過太多人在eval模板里被$$折磨。其實規(guī)則就一條eval參數(shù)展開時$()會立刻取值$$()經過展開后蛻變成$()原樣寫進解析結果為recipe留到執(zhí)行期再展開。在模板里寫eval展開后存入數(shù)據庫最終執(zhí)行效果$(CFLAGS)CFLAGS的當前值生成時快照后續(xù)改動不影響$$(CFLAGS)文本$(CFLAGS)執(zhí)行recipe時才取CFLAGS的值$$$執(zhí)行時自動變量目標名$空字符串讀入期沒有目標上下文直接丟掉最后一行的坑最典型$是自動變量只有執(zhí)行recipe時才有意義。在eval參數(shù)展開階段make根本不在任何規(guī)則上下文里$就是空串。所以模板里的自動變量必須寫成$$、$$、$$^。我的經驗法則是模板里所有希望最終在recipe里展開的東西一律寫成$$開頭寧可多轉義不要少轉義。3. 實戰(zhàn)從源文件列表批量生成編譯規(guī)則3.1 foreach call eval三連的完整骨架現(xiàn)在把前面幾塊拼起來做一個真正能用的編譯規(guī)則生成器。假設有三個模塊alpha、beta、gamma每個模塊有一個源文件APPS : alpha beta gamma define app_rule build/$(1).o: src/$(1).c | build_dir $$(CC) $$(CFLAGS) -c $$ -o $$ build/$(1).bin: build/$(1).o $$(CC) $$(LDFLAGS) $$^ -o $$ endef $(foreach app,$(APPS),$(eval $(call app_rule,$(app)))) build_dir: mkdir -p build .PHONY: build_dir$(foreach app,$(APPS),...)的語義是遍歷APPS列表每輪把當前值賦給變量app并展開循環(huán)體文本。展開體里調用了$(call app_rule,$(app))于是每個模塊名都會被代入模板生成兩到三行規(guī)則文本最后交給$(eval)解析。這么一來APPS列表成了唯一的事實來源。新增一個模塊只需要在列表里加一行編譯規(guī)則、鏈接規(guī)則、目錄依賴全部自動生成。我把這個模式叫作三連foreach負責遍歷call負責傳參eval負責落地。| build_dir是order-only前置依賴意思是構建前必須先執(zhí)行build_dir的recipe但它的時間戳變化不觸發(fā)本目標重編。目錄這種資源時間戳每構建一次都會變如果寫成普通依賴會導致所有目標每次都被判為過時那是純粹浪費。這個細節(jié)別忽略。3.2 把差異化參數(shù)收進模板每模塊一套編譯選項同構規(guī)則最常見的變體是編譯參數(shù)不一樣。比如alpha要開-O2和宏定義beta要開-g做調試。手工階段這類差異是靠復制粘貼不同CFLAGS行實現(xiàn)的用eval可以把參數(shù)做成每模塊一個變量模板里按目標名拼變量名APPS : alpha beta CFLAGS_alpha : -O2 -DALPHA CFLAGS_beta : -O0 -g -Wall define app_rule obj/$(1).o: src/$(1).c $$(CC) $$(CFLAGS_$(1)) -c $$ -o $$ endef $(foreach app,$(APPS),$(eval $(call app_rule,$(app))))注意$$(CFLAGS_$(1))的處理順序$(call)先把$(1)替換成模塊名比如alpha模板就變成$$(CFLAGS_alpha)eval參數(shù)展開時$$蛻變成$存進數(shù)據庫的是$(CFLAGS_alpha)等到執(zhí)行recipe時才真正去讀CFLAGS_alpha變量的值。所以這個模板既捕獲了每模塊不同參數(shù)的差異又保持了參數(shù)可以后定義的靈活性——CFLAGS_alpha放在foreach前還是后都不影響最終結果。這套寫法比每個模塊復制一行CFLAGS干凈得多。以后想看某模塊用了什么編譯選項直接看變量定義區(qū)想統(tǒng)一加選項改一處全局的也沒問題。3.3 順手生成目錄規(guī)則、clean入口與all收口eval還有一個經常被忽略的能力它生成的文本里可以包含普通的變量賦值語句。也就是說eval不僅能生成規(guī)則還能在生成的同一次解析中執(zhí)行TARGETS ...這類賦值。利用這一點我們可以讓模板自動收集自己生成的目標TARGETS : define app_rule bin/$(1): obj/$(1).o $$(CC) $$(LDFLAGS) $$ -o $$ obj/$(1).o: src/$(1).c $$(CC) $$(CFLAGS) -c $$ -o $$ TARGETS bin/$(1) endef $(foreach app,$(APPS),$(eval $(call app_rule,$(app)))) all: $(TARGETS)這里有一個極其關鍵的順序問題all: $(TARGETS)這一行必須放在foreach之后。原因在于make在解析all:規(guī)則時會立刻展開$(TARGETS)來得到依賴列表除非開了.SECONDEXPANSION。如果all寫在foreach前面那一刻TARGETS還是空的等于定義了all:沒有任何依賴。這跟變量要先用后算是兩回事純粹是解析順序導致的。很多初學者在這里卡住以為是eval沒生效其實是規(guī)則位置錯了。clean規(guī)則也可以順手補上。既然所有構建產物都集中在build、obj、bin幾個目錄里清理就很省事clean: rm -rf build obj bin整個構建腳本現(xiàn)在只剩三部分模塊清單、模板定義、foreach生成區(qū)。手工Makefile里那種上百行規(guī)則海洋徹底消失了。4. 讓生成的規(guī)則互相引用元數(shù)據收集與自動變量細節(jié)4.1 eval不僅能生成規(guī)則還能生成聲明和賦值如果你以為eval只能生成目標: 依賴這種規(guī)則行那就浪費了一半功力。eval生成的文本可以是任何makefile合法內容變量賦值、偽目標聲明、include指令甚至另一個$(eval)的調用文本。比如給每個模塊生成一個自檢入口define app_rule .PHONY: run_$(1) run_$(1): bin/$(1) ./bin/$(1) --self-check TARGETS bin/$(1) endef模板里.PHONY: run_$(1)這一行經過eval解析后會變成真實的偽目標聲明跟手寫的.PHONY效果一致。你也可以在模板里給某個變量做累加把生成規(guī)則和收集規(guī)則信息合在一次eval里完成。這就是元數(shù)據收集規(guī)則本身進了依賴圖規(guī)則的名字也進了變量供后續(xù)統(tǒng)一處理?；氐?.1開頭那句包括另一個eval的調用文本——技術上嵌套eval可用但我并不推薦。嵌套會讓轉義層數(shù)指數(shù)級上升排查問題時會極其痛苦。如果你發(fā)現(xiàn)自己需要在一個模板里再套一層eval先停下來想想是不是可以用兩個foreach、兩個模板分階段完成。4.2 自動變量轉義對照表與模式規(guī)則取舍前面提過自動變量在模板里的轉義問題這里給一份完整對照表方便你寫模板時直接查自動變量含義eval模板里的寫法$目標名$$$第一個前置依賴$$$^所有前置依賴去重$$^$?比目標新的前置依賴$$?$*模式規(guī)則中匹配的部分$$*$(D)目標所在目錄$$(D)$(F)目標文件名部分$$(F)$(D)第一個前置依賴的目錄$$(D)$(F)第一個前置依賴的文件名$$(F)這里要提醒一句eval不是萬能的也不是所有規(guī)則都該用eval生成。如果你的目標名有嚴格的字符串規(guī)律比如所有源文件都走obj/%.o: src/%.c直接寫一條模式規(guī)則就夠了一行解決根本不需要模板。eval真正不可替代的場景是目標之間是離散的每個目標還帶有獨立參數(shù)。比如按模塊生成不同名字的二進制、按配置生成不同后綴的打包產物這種同構但不滿足模式匹配的情況才是eval的主場。4.3 多模塊交叉依賴生成規(guī)則之間如何協(xié)調實際項目里模塊之間很少完全獨立常有A模塊鏈接時依賴B模塊生成的庫這種情況。eval生成規(guī)則會不會導致依賴順序出問題不會。讀入期結束時make已經把所有生成的規(guī)則都收進依賴圖了圖的解析發(fā)生在執(zhí)行期。所以在文件里bin模板寫在lib模板前面、還是lib模板寫在bin模板前面對依賴圖的最終形態(tài)沒有影響。舉例define lib_rule lib/$(1).a: obj/$(1).o $$(AR) rcs $$ $$^ endef define bin_rule bin/$(1): lib/libcore.a $$(CC) $$(LDFLAGS) $$^ -o $$ endef即使bin_rule的foreach寫在lib_rule前面make依然能正確解析出bin/demo依賴lib/libcore.a。真正需要注意的是命名紀律如果兩個不同模板生成了同一個目標名make會報target given more than once之類錯誤。我的習慣是所有生成目標都用$(1)做前綴或子目錄隔離從源頭杜絕目標名沖突。5. 我在真實構建里踩過的坑與調試腳手架5.1 規(guī)則靜默消失展開順序的典型錯誤eval最坑的地方在于出錯了不一定報錯而是靜默生成空規(guī)則。我踩過最典型的幾個模板里寫$(CFLAGS)但CFLAGS在foreach之后才定義eval展開時取到空值生成出來的recipe變成一條沒有編譯參數(shù)的命令編譯卻照樣成功只是產物不對。修法是模板里統(tǒng)一寫$$(CFLAGS)讓取值延遲到執(zhí)行期。all: $(TARGETS)寫在foreach之前依賴列表展開為空make只輸出Nothing to be done。這個前面說過位置決定生死。試圖在recipe里調用$(eval ...)想讓make在每次構建時動態(tài)生成新規(guī)則。這是認知錯誤recipe是執(zhí)行期跑的讀入期早已結束eval不會生效。如果你確實需要每次構建時重新生成規(guī)則正確做法是用$(file ...)把生成的makefile片段寫到磁盤再用include動態(tài)包含它。第二條的排查經驗是遇到目標沒生成或命令行為不對先懷疑展開順序再看轉義順序問題的特征是有據可循比如all放在前面轉義問題的特征是生成文本里多了空參數(shù)。5.2 空格縮進與missing separator這是eval用戶最容易在復制代碼時踩的雷make要求recipe行以Tab開頭這個要求對eval生成的文本同樣生效。如果你的編輯器默認把Tab轉成四個空格define塊里的recipe行就會變成空格縮進eval解析時報錯信息通常是missing separator——它不知道這一行該當成規(guī)則、變量還是recipe。更隱蔽的情況是模板里有recipe行用了空格縮進但前面恰好有一行規(guī)則定義make會把recipe行解析成游離的雜散文本有時不報錯只是那條命令永遠不執(zhí)行。這種不報錯的錯最費時間。我的建議是在編輯器里關掉Tab轉空格功能或者在define塊寫完后用sed -n l這種命令檢查一下Tab字符是否真的存在。5.3 $(shell)與$(warning)在eval里的特殊行為eval參數(shù)里如果出現(xiàn)$(shell ...)它會在每次make解析時真的執(zhí)行一次shell命令。這意味著有副作用的shell命令寫文件、改系統(tǒng)狀態(tài)放進eval里等于每次構建都重復觸發(fā)副作用而且可能因為并行、失敗重試等原因產生詭異行為。純查詢類命令讀版本號、獲取當前時間可以用但也要意識到它拖慢了讀入階段。比$(shell)更適合調試eval的是$(warning)和$(info)。這兩個函數(shù)在展開時打印消息、返回空字符串用法很直觀。在模板里插一行$(warning now generating rule for $(1))能在foreach循環(huán)時看到每次調用的參數(shù)如果放在call之前或之后還能觀察文本生成的位置。我在模板里調試時最喜歡的一句是define app_rule $(info [template] target$(1)) ... endef這樣每次$(call)展開模板都會打印一次當前模塊名一眼就能確認循環(huán)有沒有跑、參數(shù)傳對沒有。5.4 調試腳手架先info打印再eval再make -p最后給一套我屢試不爽的調試流程。第一步把eval臨時改成info只看生成的文本不解析# 調試時先只打印不解析 $(foreach app,$(APPS),$(info $(call app_rule,$(app)))) # 確認文本沒問題再換成 $(foreach app,$(APPS),$(eval $(call app_rule,$(app))))這一步能區(qū)分模板生成錯了和規(guī)則解析錯了。生成文本如果不對后面的eval報什么錯都先別管先把模板和轉義理順。第二步用make -pR導出make的完整數(shù)據庫。-p會把所有讀入的規(guī)則打印出來-R禁用內置規(guī)則減少噪音。在輸出里grep你的目標名比如make -pR | grep -A5 build/alpha就能看到eval生成的規(guī)則是否真的進了依賴圖依賴寫沒寫對、recipe是什么全都清清楚楚。第三步make -n做試運行只看生成的shell命令不執(zhí)行。這條很關鍵因為規(guī)則進沒進圖是一回事recipe展開成什么樣子是另一回事。make -n會讓你直觀地看到$$(CFLAGS)到底展開成了什么如果展開結果里有空參數(shù)或者$(殘留那基本可以斷定是轉義層數(shù)出了問題。還有一點心理準備eval相關的報錯信息經常指向makefile:0或者一個不存在的行號因為出錯的內容來自運行時生成的文本make無法回溯到模板的原始位置。所以功能越復雜的eval模板越要保住命名紀律和區(qū)域注釋否則半年后你自己也看不懂那段生成代碼。我現(xiàn)在的構建腳本里規(guī)則生成區(qū)占了將近一半新增模塊只需要在模塊清單里加一行剩下的事全部交給eval。如果讓我給一個最重要的習慣那就是模板文件名統(tǒng)一加前綴清晰標識foreach生成區(qū)集中放在文件底部并配上大段注釋說明這個區(qū)域只允許改模塊清單和模板不要在這里手寫規(guī)則——這樣團隊里其他人接手時才不會把eval生成的東西誤當成普通規(guī)則去改。