【正文】 ? 這個手冊翻譯整理 : 徐海兵 , 先表示一些尊敬 . “ 本人在工作之余，花了 18 個多月時間完成對 “info make” 的翻譯整理，完成這個中文版手冊 ”, 工夫不負有心人 . ? 鏈接器將 .o 文件中使用的函數(shù)和其它 .o 或者庫文件中的相關符號進行合并，對所有文件中的符號進行重新安排（重定位），并鏈接系統(tǒng)相關文件（程序啟動文件等）最終生成可執(zhí)行程序。 ? Linux 中，共享庫文件格式通常為 “ELF” 格式。共享庫已經(jīng)具備了可執(zhí)行條件。 ? 模塊中各個成員的地址（變量引用和函數(shù)調用）都是相對地址。使用此共享庫的程序在運行時，共享庫被動 態(tài)加載到內存并和主程序在內存中進行連接。多個可執(zhí)行程序可共享庫文件的代碼段（多個程序可以共享的使用庫中的某一個模塊，共享代碼，不共享數(shù)據(jù)）。另外共享庫的成員對象可被執(zhí)行（由 提供支持）。 ? 在 make 讀取 Makefile 以后會建立一個編譯過程的描述數(shù)據(jù)庫。此數(shù)據(jù)庫中記錄了所有各個文件之間的相互關系，以及它們的關系描述 (要是我能 看 到這個數(shù)據(jù)庫，就能使用程序 trace，你知道一個大型的 project的 makefile 有多復雜 ) ? 當使用 make 工具進行編譯時，工程中以下幾種文件在執(zhí)行 make 時 將會被編譯（重新編譯）： 1. 所有的源文件沒有被編譯過，則對各個 C 源文件進行編譯并進行鏈接，生成最后的可執(zhí)行程序； 2. 每一個在上次執(zhí)行 make 之后修改過的 C 源代碼文件在本次執(zhí)行 make時將會被重新編譯； 3. 頭文件在上一次執(zhí)行 make 之后被修改。則所有包含此頭文件的 C源文件在本次執(zhí)行 make 時將會被重新編譯。 (這就是為什么頭文件修改后，很多文件都會被重新 pile 的原因 ) ? 首先書寫時，可以將一個較長行使用反斜線（ \）來分解為多行，這樣可以使我們的 Makefile 書寫清晰、容易閱讀理解。 但需要注意：反斜線之后不能有空格（這也是大家最容易犯的錯誤，錯誤比較隱蔽） ? 編譯 .c 源文件規(guī)則的命令可以不用明確給出。這是因為 make 本身存在一個默認的規(guī)則，能夠自動完成對 .c 文件的編譯并生成對應的 .o 文件。它執(zhí)行命令 “cc c” 來編譯 .c 源文件。 ? 對一個目標文件是 “” ，倚賴文件是 “” 的規(guī)則，完全可以省略其規(guī)則的命令行，而由 make 自身決定使用默認命令。此默認規(guī)則稱為 make的隱含規(guī)則。 ? 書寫規(guī)則建議的方式是：單目標，多依賴。就是說盡量要做到一個規(guī)則中只存在一個目標文件，可有多個依賴文件。盡量 避免多目標，單依賴的方式。 這樣后期維護也會非常方便，而且 Makefile 會更清晰、明了。 ? 在這個 Makefile 中， 根據(jù)依賴而不是目標對規(guī)則進行分組 (Wrong!)。上例的 Makefile 就可以這樣來實現(xiàn)： sample Makefile objects = \ edit : $(objects) cc o edit $(objects) $(objects) : : : 例子中頭文件 “” 作為所有 .o 文件的依賴文件。其它兩個頭文件作為其對應規(guī)則的目標中所列舉的所有 .o文件的依賴文件。 但是這種風格的 Makefile 并不值得我們借鑒。 問題在于：同時把多個目標文件的依賴放在同一個規(guī)則中進行描述（一個規(guī)則中含有多個目標文件），這樣導致 規(guī)則定義不明了，比較混亂。 建議大家不要在 Makefile 中采用這種方式了書寫。否則后期維護將會是一件非常痛苦的事情。 ? “include” 指示符告訴 make 暫停讀取當前的 Makefile，而轉去讀取“include” 指定的一個或者多個文件，完成以后再繼續(xù)當前 Makefile的讀取。 通常指示符 “include” 用在以下場合： 1. 有多個不同的程序，由不同目錄下的幾個獨立的 Makefile 來描述其重建規(guī)則。它們需要使用一組通用的變量定義或者模式規(guī)則。 2. 當根據(jù)源文件自動產(chǎn)生依賴文件時；我們可以將自動產(chǎn) 生的依賴關系保存在另外一個文件中，主 Makefile 使用指示符 “include” 包含這些文件。這 樣的做法比直接在主 Makefile 中追加依賴文件的方法要明智的多。其它版本的 make 已經(jīng)使用這種方式來處理。 (我想看看這方面的例子 ) 當 在這些目錄下都沒有找到 “include” 指定的文件時， make 將會提示一個包含文件未找到的告警提示，但是不會立 刻退出。而是繼續(xù)處理Makefile 的后續(xù)內容。當完成讀取整個 Makefile 后， make 將試圖使用規(guī)則來創(chuàng)建通過指示符 “include” 指定的 但未找到的文件，當 不能創(chuàng)建它時（沒有創(chuàng)建這個文件的規(guī)則）， make 將提示致命錯誤并退出。 ? 通常我們在 Makefile 中可使用 “ include” 來代替 “include” ，來忽略由于包含文件不存在或者無法創(chuàng)建時的錯誤提示（ “ ” 的意思是告訴make，忽略此操作的錯誤。 make 繼續(xù)執(zhí)行）。 ? Makefile 中符號 “$” 有特殊的含義（表示變量或者函數(shù)的引用）， 在規(guī)則中需要使用符號 “$” 的地方，需要書寫兩個連續(xù)的（ “$$” ）。 ? Maekfile 中表示文件名時可使用通配符?？墒褂玫耐ㄅ浞校?“*” 、“?” 和 “[?]” 。 在 Makefile 中這些統(tǒng)配符并不是可以用在任何地方， Makefile 中統(tǒng)配符可以出現(xiàn)在以下兩種場合： 1. 可以用在 規(guī)則的目標、依賴中 ， make 在讀取 Makefile 時會自動對其進行匹配處理（通配符展開）； 2. 可出現(xiàn)在 規(guī)則的命令中 ，通配符的通配處理是在 shell 在執(zhí)行此命令 時完成的。 除這兩種情況之外的其它上下文中，不能直接使用通配符。而是需要通過函數(shù) “wildcard” 來實現(xiàn)。 比如變量定義中使用的通配符不會被統(tǒng)配處理（因此在變量定義中不能使用通配符，否則在某些情況下會出現(xiàn)非預期的結果，下一小節(jié)將會詳 細討論）。在 Makefile 有這樣一個變量定義： “objects = *.o” 。它表示變量 “objects” 的值是字符串 “*.o” （并不是期望的空格分開的 .o文件列表）。當需要變量 “objects” 代表所有 .o文件 列表示，需要使用函數(shù) “wildcard” （ objects = $(wildcar *.o)）。 在規(guī)則中，通配符會被自動展開。但在變量的定義和函數(shù)引用時，通配符將失效。這種情況下如果需要通配符有效，就需要使用函數(shù) “wildcard” ，它的用法是： $(wildcard PATTERN...) 。 ? 在 Makefile 中，它被展開為已經(jīng)存在的、使用空格分開的、匹配此模式的所有文件列表。如果不存在任何符合此模式的文件，函數(shù)會忽略模式字符并返回空。 ? 一 般我們可以使用 “$(wildcard *.c)” 來獲取工作目錄下的所有的 .c文件列表。復雜一些用法；可以使用 “$(patsubst %.c,%.o,$(wildcard *.c))” ，首先使用 “wildcard” 函數(shù)獲取工作目錄下的 .c 文件列表；之后將列表中所有文件名的后綴 .c替換為 .o。這樣我們就可以得到在當前 目錄可生成的 .o 文件列表。因此在一個目錄下 可以使用如下內容的Makefile 來將工作目錄下的所有的 .c文件進行編譯并最后連接成為一個可執(zhí)行文件： sample Makefile objects := $(patsubst %.c,%.o,$(wildcard *.c)) foo : $(objects) cc o foo $(objects) 使用偽目標有兩點原因： 1. 避免在我們的 Makefile 中定義的只執(zhí)行命令的目標（此目標的目的為了執(zhí)行執(zhí)行一些列命令，而不需要創(chuàng)建這個目標）和工作目錄下的實際文件出現(xiàn)名字沖突。 2. 提高執(zhí)行 make 時的效率，特別是對于一個大型的工程來說，編譯的效率也許你同樣關心。 如 :在 make 的并行和遞歸執(zhí)行過程中。此情況下一般會存在一個變量，定義為所有需要 make 的子目錄。對多個目錄進行 make 的實現(xiàn)方式可以是：在一個規(guī)則的命令行中使用 shell 循環(huán)來完成。如下： SUBDIRS = foo bar baz subdirs: for dir in $(SUBDIRS)。 do \ $(MAKE) C $$dir。 \ done 但這種實現(xiàn)方法存在以下幾個問題 : 1. 當子目錄執(zhí)行 make 出現(xiàn)錯誤時， make 不會退出。就是說，在對某一個目錄執(zhí)行 make 失敗以后，會繼續(xù)對其他的目錄進行 make。在最終執(zhí)行失敗的情 況下，我們很難根據(jù)錯誤提示定位出具體是在那個目錄下執(zhí)行 make 時發(fā)生錯誤。這樣給問題定位造成了很大的困難。為了解決這個問題，可以在命令行部分加入 錯誤監(jiān)測，在命令執(zhí)行錯誤后主動退出。不幸的是，如果在執(zhí)行 make 時使用了“ k” 選項，此方式將失效。 2. 另外一個問題就是使用這種 shell 的循環(huán)方式時，沒有用到 make 對目錄的并行處理功能，由于規(guī)則的命令是一條完整的 shell 命令，不能被并行處理。 有了偽目標之后，我們可以用它來克服以上實現(xiàn)方式所存在的兩個問題。 SUBDIRS = foo bar baz .PHONY: subdirs $(SUBDIRS) subdirs: $(SUBDIRS) $(SUBDIRS): $(MAKE) C $@ foo: baz 上邊的實現(xiàn)中有一個沒有命令