我們在前面學習了 makefile 中的路徑搜索,那么我們今天就來實戰(zhàn)演練下。需求分析:1、工程中不需要源碼文件夾在編譯時被改動(只讀文件夾);2、在編譯時自動創(chuàng)建文件夾(build)用于存放編譯結(jié)果;3、編譯過程中能夠自動搜索需要的文件;3、編譯過程中能夠自動搜索需要的文件;4、makefile 易于擴展,能夠復(fù)用于相同類型的項目;5、支持調(diào)試版本的編譯選項。
創(chuàng)新互聯(lián)服務(wù)項目包括成都網(wǎng)站建設(shè)、成都網(wǎng)站制作、成都網(wǎng)頁制作以及成都網(wǎng)絡(luò)營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,成都網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到成都省份的部分城市,未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!
我們來看看這種項目的類型,如下
那么我們需要的工具原料有:a> $(wildcard $(DIR)/_pattern),用來獲取 $(DIR) 文件夾中滿足 _pattern 的文件;b> $(notdir _names),用于去除 _names 中每一個文件名的路徑前綴;c> $(patsubst _pattern, replacement, _text),用于將 _text 中符合 _pattern 的部分替換為 replacement。這里面的關(guān)鍵技巧有:1、自動獲取源文件列表(函數(shù)調(diào)用): SRCS := $(wildcard src/*.c);2、根據(jù)源文件列表生成目標文件列表(變量的值替換): OBJS := $(SRCS:.c=.o);3、替換每一個目標文件的路徑前綴(函數(shù)調(diào)用): OBJS := $(patsubst src/%, build/%, $(OBJS))。下來我們來看看編譯規(guī)則的依賴,如下圖所示
下來我們來看看 makefile 怎么寫,src 和 inc 文件夾還是之前的
.PHONY : all clean rebuild DIR_BUILD := build DIR_SRC := src DIR_INC := inc TYPE_INC := .h TYPE_SRC := .c TYPE_OBJ := .o CC := gcc CFLAGS := -I $(DIR_INC) ifeq ($(DEBUG), true) CFLAGS += -g endif MKDIR := mkdir RM := rm -rf APP := $(DIR_BUILD)/app.out HDRS := $(wildcard $(DIR_INC)/*$(TYPE_INC)) HDRS := $(notdir $(HDRS)) OBJS := $(wildcard $(DIR_SRC)/*$(TYPE_SRC)) OBJS := $(OBJS:$(TYPE_SRC)=$(TYPE_OBJ)) OBJS := $(patsubst $(DIR_SRC)/%, $(DIR_BUILD)/%, $(OBJS)) vpath %$(TYPE_INC) $(DIR_INC) vpath %$(TYPE_SRC) $(DIR_SRC) all : $(DIR_BUILD) $(APP) @echo "Target File ==> $(APP)" $(DIR_BUILD) : $(MKDIR) $@ $(APP) : $(OBJS) $(CC) -o $@ $^ $(DIR_BUILD)/%$(TYPE_OBJ) : %$(TYPE_SRC) $(HDRS) $(CC) $(CFLAGS) -o $@ -c $< clean : $(RM) $(DIR_BUILD) rebuild : $(MAKE) clean $(MAKE) all
我們看到變量 HDRS 是先進入到 inc 文件夾下獲取到所需的 .h 頭文件,然后再經(jīng)過 notdir 去除掉它的路徑名。我們利用 TYPE_XXX 來定義相應(yīng)的 頭文件(或源文件或目標文件),這樣做是為了讓這個 makefile 具有更好的移植性。利用 vpath 來指定相應(yīng)的路徑。通過 DEBUG 宏判斷它是否為調(diào)試版本。下來我們先來看看它是否能正常工作。
我們看到它已經(jīng)正確工作了,并且在 build 文件夾下生產(chǎn)相應(yīng)的 app.out 以及 .o 文件,原 inc 和 src 文件夾并沒有被污染。這便達到了我們的要求了,如果是換一個類似的項目(包含有 .h 的頭文件庫和 .c 的源文件庫),我們也能直接拿去這個 makefile 進行使用;如果是 C++ 項目,那么我們換個 g++ 編譯器就可以正常工作。但是有個小問題,就是如果其中有一個頭文件改動,整個項目就必須全部編譯。我們就得思考了:對于規(guī)則較小的項目,我們在 makefile 中是否也需要使用自動生成依賴關(guān)系的解決方案呢?如果使用自動生成依賴關(guān)系的解決方案,那么整個的 makefile 代碼的編寫就相當復(fù)雜了。我們究竟該如何做呢?如果對于較小的項目,我們就不必使用自動生成依賴關(guān)系,因為此時不但是 makefile 的編寫比較復(fù)雜,而且不利用后期的維護。
通過對路徑搜索的綜合開發(fā)的學習,總結(jié)如下:1、工程項目中不希望源碼文件夾在編譯時被改動,模式規(guī)則的靈活運用使得 makefile 具有復(fù)用性;2、變量的靈活運用使得 makefile 具有擴展性;3、規(guī)模較小的項目沒必要使用自動生成依賴關(guān)系的解決方案;4、規(guī)則較小的項目可以直接讓源文件依賴于頭文件(原因就是易于維護)。
歡迎大家一起來學習 makefile 語言,可以加我QQ:243343083。