路徑搜索的綜合示例（十三）

        我們在前面學(xué)習(xí)了 makefile 中的路徑搜索，那么我們今天就來實戰(zhàn)演練下。需求分析：1、工程中不需要源碼文件夾在編譯時被改動（只讀文件夾）；2、在編譯時自動創(chuàng)建文件夾（build）用于存放編譯結(jié)果；3、編譯過程中能夠自動搜索需要的文件；3、編譯過程中能夠自動搜索需要的文件；4、makefile 易于擴(kuò)展，能夠復(fù)用于相同類型的項目；5、支持調(diào)試版本的編譯選項。

        我們來看看這種項目的類型，如下

        那么我們需要的工具原料有：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ù)源文件列表生成目標(biāo)文件列表（變量的值替換）： OBJS := $(SRCS:.c=.o)；3、替換每一個目標(biāo)文件的路徑前綴（函數(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 是先進(jìn)入到 inc 文件夾下獲取到所需的 .h 頭文件，然后再經(jīng)過 notdir 去除掉它的路徑名。我們利用 TYPE_XXX 來定義相應(yīng)的 頭文件（或源文件或目標(biāo)文件），這樣做是為了讓這個 makefile 具有更好的移植性。利用 vpath 來指定相應(yīng)的路徑。通過 DEBUG 宏判斷它是否為調(diào)試版本。下來我們先來看看它是否能正常工作。

        我們看到它已經(jīng)正確工作了，并且在 build 文件夾下生產(chǎn)相應(yīng)的 app.out 以及 .o 文件，原 inc 和 src 文件夾并沒有被污染。這便達(dá)到了我們的要求了，如果是換一個類似的項目（包含有 .h 的頭文件庫和 .c 的源文件庫），我們也能直接拿去這個 makefile 進(jìn)行使用；如果是 C++ 項目，那么我們換個 g++ 編譯器就可以正常工作。但是有個小問題，就是如果其中有一個頭文件改動，整個項目就必須全部編譯。我們就得思考了：對于規(guī)則較小的項目，我們在 makefile 中是否也需要使用自動生成依賴關(guān)系的解決方案呢？如果使用自動生成依賴關(guān)系的解決方案，那么整個的 makefile 代碼的編寫就相當(dāng)復(fù)雜了。我們究竟該如何做呢？如果對于較小的項目，我們就不必使用自動生成依賴關(guān)系，因為此時不但是 makefile 的編寫比較復(fù)雜，而且不利用后期的維護(hù)。

        通過對路徑搜索的綜合開發(fā)的學(xué)習(xí)，總結(jié)如下：1、工程項目中不希望源碼文件夾在編譯時被改動，模式規(guī)則的靈活運用使得 makefile 具有復(fù)用性；2、變量的靈活運用使得 makefile 具有擴(kuò)展性；3、規(guī)模較小的項目沒必要使用自動生成依賴關(guān)系的解決方案；4、規(guī)則較小的項目可以直接讓源文件依賴于頭文件（原因就是易于維護(hù)）。

        歡迎大家一起來學(xué)習(xí) makefile 語言，可以加我QQ：243343083。