【正文】 代表的是哪個(gè)觸發(fā)規(guī)則被執(zhí)行的目標(biāo)文件名。 因此，一個(gè)模式規(guī)則的格式為： %.o : %.c 。只是在模式規(guī)則中，目標(biāo)名中需要包含有模式字符 “%” （一個(gè)），包含有模式字符 “%” 的目標(biāo)被用來 匹配一個(gè)文件 名， “%” 可以匹配任何非空字符串。所有剩余工作全部交給了 make去處理，它會自動尋找到相應(yīng)規(guī)則并執(zhí)行、最終完成目標(biāo)文件的重建。 ? 當(dāng)引用 “shell” 函數(shù)的變量定義使用直接展開式定義時(shí)可以保證函數(shù)的展開是在 make 讀入 Makefile 時(shí)完成。對于 用戶自己的函數(shù)需要通過 make 的 “call” 函數(shù)來間接調(diào)用 。就是說，即使我們通過其它方式（比如，定義它的值引用了 其它的變量）給它賦了一個(gè)空值， “ifdef” 也會返回真。參數(shù)值可能是通過引用變量或者函數(shù)得到的，因而在展開過程中可能造成參數(shù)值中包含空字符（空格等）。 ? “ 自動化變量 ” ，諸如 “$^” 等。因?yàn)檫@種風(fēng)格變量的使用方式和大多數(shù)編程語言中的變量使用方式基本上相同。第二、三、四、五行分別定義了一個(gè)變量，在進(jìn)行變量定義時(shí)對引用到的其它變量和函數(shù)展開。 \ done ?? ? 下邊我們來看一個(gè)復(fù)雜一點(diǎn)的例子。 2. 出現(xiàn)在 規(guī)則命令行中 shell 變量（一般為執(zhí)行命令過程中的臨時(shí)變量，它不屬于 Makefile 變量，而是一個(gè) shell 變量）引用使用 shell 的“$tmp” 格式 。這一點(diǎn)和 shell 中變量的引用方式不同。變量的引用方式是： “$ （ VARIABLE_NAME） ” 或者“${ VARIABLE_NAME }” 來引用一個(gè)變量的定義。 ? 變 量名是大小寫敏感的。. 通常，選項(xiàng) “ w” 會被自動打開。但是在新版本的 GNU make 中取消了這一默認(rèn)的行為。而當(dāng)沒有使用指示符 “export” 對任何變量進(jìn)行聲明的情況下，上層make 只將那些已經(jīng)初始化的環(huán) 境變量（在執(zhí)行 make 之前已經(jīng)存在的環(huán)境變量）和使用命令行指定的變量（如命令 “make CFLAGS += g” 或者“make – e CFLAGS +=g” ）傳遞給子 make 程序， ? 存在兩個(gè)特殊的變量 “SHELL” 和 “MAKEFLAGS” ，對于這兩個(gè)變量除非使用指示符 “unexport” 對它們進(jìn)行聲明，它們在整個(gè) make 的執(zhí)行過程中始終被自動的傳遞給所有的子 make。最后在鏈接生成終極目標(biāo)時(shí)由于某一個(gè) .o 文件的不完整，可能出現(xiàn)一堆令人難以理解的錯誤信息，或者產(chǎn)生了一個(gè)不 正確的終極目標(biāo)。其原因我們上一節(jié)已經(jīng)有所討論。如： foo : bar/lose cd bar。就是說其后的命令執(zhí)行的工作目錄不會是之前使用 “cd” 進(jìn)入的那個(gè)目錄。此規(guī)則所定義的命令將會被執(zhí)行，如果是多行命令，那么每一行命令將在一個(gè)獨(dú)立的子 shell 進(jìn)程中被執(zhí)行（就是說，每一行命 令的執(zhí)行是在一個(gè)獨(dú)立的 shell 進(jìn)城中完成）。如果在命令行之前沒有字符 “” ，那么， make 的輸出將是： echo編譯 XXX 模塊 ...... 編譯 XXX 模塊 ...... ? 另 外，如果使用 make 的命令行參數(shù) “ n” 或 “ justprint” ，那么make 執(zhí)行時(shí)只顯示所要執(zhí)行的命令，但不會真正的去執(zhí)行這些命令。 我們通過另外一個(gè)例子來看一下自動環(huán)變量 “$*” 在靜態(tài)模式規(guī)則中的使用方法： bigoutput littleoutput : %output : generate $* $ 當(dāng)執(zhí)行此規(guī)則的命令時(shí)，自動環(huán)變量 “$*” 被展開為 “ 莖 ” 。代表這個(gè)文件是所有目標(biāo)的依賴文件。而目標(biāo) “” 和 “” 就不符合此目標(biāo)模式。 首先，我們來看一下靜態(tài)模式規(guī)則的基本語法： TARGETS ...: TARGETPATTERN: PREREQPATTERNS ... COMMANDS 首 先在目標(biāo)模式和依賴模式中，一般需要包含模式字符 “%” 。 fi)) 而后面 subdirs: $(patsubset %, _dir_%, $(SUBDIRS)) $(patsubset %, _dir_%, $(SUBDIRS)): $(MAKE) C $(patsubset _dir_%, %, $) $(TGT) ） ? make 存在一個(gè)內(nèi)嵌隱含變量 “RM” ，它被定義為： “RM = rm – f” 。它的作用是限制同步目錄 “foo” 和 “ba z” 的 make 過程（在處理“foo” 目錄之前，需要等待 “baz” 目錄處理完成）。不幸的是，如果在執(zhí)行 make 時(shí)使用了“ k” 選項(xiàng)，此方式將失效。就是說，在對某一個(gè)目錄執(zhí)行 make 失敗以后，會繼續(xù)對其他的目錄進(jìn)行 make。對多個(gè)目錄進(jìn)行 make 的實(shí)現(xiàn)方式可以是：在一個(gè)規(guī)則的命令行中使用 shell 循環(huán)來完成。因此在一個(gè)目錄下 可以使用如下內(nèi)容的Makefile 來將工作目錄下的所有的 .c文件進(jìn)行編譯并最后連接成為一個(gè)可執(zhí)行文件： sample Makefile objects := $(patsubst %.c,%.o,$(wildcard *.c)) foo : $(objects) cc o foo $(objects) 使用偽目標(biāo)有兩點(diǎn)原因： 1. 避免在我們的 Makefile 中定義的只執(zhí)行命令的目標(biāo)（此目標(biāo)的目的為了執(zhí)行執(zhí)行一些列命令，而不需要創(chuàng)建這個(gè)目標(biāo)）和工作目錄下的實(shí)際文件出現(xiàn)名字沖突。如果不存在任何符合此模式的文件，函數(shù)會忽略模式字符并返回空。 在規(guī)則中，通配符會被自動展開。 比如變量定義中使用的通配符不會被統(tǒng)配處理（因此在變量定義中不能使用通配符，否則在某些情況下會出現(xiàn)非預(yù)期的結(jié)果，下一小節(jié)將會詳 細(xì)討論）?？墒褂玫耐ㄅ浞校?“*” 、“?” 和 “[?]” 。 ? 通常我們在 Makefile 中可使用 “ include” 來代替 “include” ，來忽略由于包含文件不存在或者無法創(chuàng)建時(shí)的錯誤提示（ “ ” 的意思是告訴make，忽略此操作的錯誤。其它版本的 make 已經(jīng)使用這種方式來處理。 通常指示符 “include” 用在以下場合： 1. 有多個(gè)不同的程序，由不同目錄下的幾個(gè)獨(dú)立的 Makefile 來描述其重建規(guī)則。 問題在于：同時(shí)把多個(gè)目標(biāo)文件的依賴放在同一個(gè)規(guī)則中進(jìn)行描述（一個(gè)規(guī)則中含有多個(gè)目標(biāo)文件），這樣導(dǎo)致 規(guī)則定義不明了，比較混亂。 ? 在這個(gè) Makefile 中， 根據(jù)依賴而不是目標(biāo)對規(guī)則進(jìn)行分組 (Wrong!)。 ? 書寫規(guī)則建議的方式是：單目標(biāo)，多依賴。這是因?yàn)?make 本身存在一個(gè)默認(rèn)的規(guī)則，能夠自動完成對 .c 文件的編譯并生成對應(yīng)的 .o 文件。此數(shù)據(jù)庫中記錄了所有各個(gè)文件之間的相互關(guān)系，以及它們的關(guān)系描述 (要是我能 看 到這個(gè)數(shù)據(jù)庫，就能使用程序 trace，你知道一個(gè)大型的 project的 makefile 有多復(fù)雜 ) ? 當(dāng)使用 make 工具進(jìn)行編譯時(shí)，工程中以下幾種文件在執(zhí)行 make 時(shí) 將會被編譯（重新編譯）： 1. 所有的源文件沒有被編譯過，則對各個(gè) C 源文件進(jìn)行編譯并進(jìn)行鏈接，生成最后的可執(zhí)行程序； 2. 每一個(gè)在上次執(zhí)行 make 之后修改過的 C 源代碼文件在本次執(zhí)行 make時(shí)將會被重新編譯； 3. 頭文件在上一次執(zhí)行 make 之后被修改。使用此共享庫的程序在運(yùn)行時(shí)，共享庫被動 態(tài)加載到內(nèi)存并和主程序在內(nèi)存中進(jìn)行連接。 ? 這個(gè)手冊翻譯整理 : 徐海兵 , 先表示一些尊敬 . “ 本人在工作之余，花了 18 個(gè)多月時(shí)間完成對 “info make” 的翻譯整理，完成這個(gè)中文版手冊 ”, 工夫不負(fù)有心人 . ? 鏈接器將 .o 文件中使用的函數(shù)和其它 .o 或者庫文件中的相關(guān)符號進(jìn)行合并，對所有文件中的符號進(jìn)行重新安排（重定位），并鏈接系統(tǒng)相關(guān)文件（程序啟動文件等）最終生成可執(zhí)行程序。 ? 模塊中各個(gè)成員的地址（變量引用和函數(shù)調(diào)用）都是相對地址。 ? 在 make 讀取 Makefile 以后會建立一個(gè)編譯過程的描述數(shù)據(jù)庫。 但需要注意：反斜線之后不能有空格（這也是大家最容易犯的錯誤，錯誤比較隱蔽） ? 編譯 .c 源文件規(guī)則的命令可以不用明確給出。此默認(rèn)規(guī)則稱為 make的隱含規(guī)則。 這樣后期維護(hù)也會非常方便，而且 Makefile 會更清晰、明了。 但是這種風(fēng)格的 Makefile 并不值得我們借鑒。 ? “include” 指示符告訴 make 暫停讀取當(dāng)前的 Makefile，而轉(zhuǎn)去讀取“include” 指定的一個(gè)或者多個(gè)文件，完成以后再繼續(xù)當(dāng)前 Makefile的讀取。這 樣的做法比直接在主 Makefile 中追加依賴文件的方法要明智的多。當(dāng)完成讀取整個(gè) Makefile 后， make 將試圖使用規(guī)則來創(chuàng)建通過指示符 “include” 指定的 但未找到的文件，當(dāng) 不能創(chuàng)建它時(shí)（沒有創(chuàng)建這個(gè)文件的規(guī)則）， make 將提示致命錯誤并退出。 ? Maekfile 中表示文件名時(shí)可使用通配符。而是需要通過函數(shù) “wildcard” 來實(shí)現(xiàn)。當(dāng)需要變量 “objects” 代表所有 .o文件 列表示，需要使用函數(shù) “wildcard” （ objects = $(wildcar *.o)）。 ? 在 Makefile 中，它被展開為已經(jīng)存在的、使用空格分開的、匹配此模式的所有文件列表。這樣我們就可以得到在當(dāng)前 目錄可生成的 .o 文件列表。此情況下一般會存在一個(gè)變量，定義為所有需要 make 的子目錄。 \ done 但這種實(shí)現(xiàn)方法存在以下幾個(gè)問題 : 1. 當(dāng)子目錄執(zhí)行 make 出現(xiàn)錯誤時(shí)， make 不會退出。為了解決這個(gè)問題，可以在命令行部分加入 錯誤監(jiān)測，