今天在編譯一個代碼時發(fā)現(xiàn)Android編譯系統(tǒng)在設置頭文件搜索路徑的順序上好像有些問題。Android編譯系統(tǒng)本身設置了一堆公共的頭文件搜索路徑（參見pathmap.mk中pathmap_INCL的定義），然后允許每個項目在自己的Android.mk中通過LOCAL_C_INCLUSES 來添加獨特的搜索路徑。按照一般的想法，在最后的編譯參數(shù)中，項目自己獨特的搜索路徑應該放在公共搜索路徑之前，這樣，一旦出現(xiàn)頭文件名沖突的情況，會優(yōu) 先使用項目自己指定的頭文件。但是在Android的編譯系統(tǒng)中情況并非如此，項目自定義的頭文件搜索路徑反而被放在了最后。參見 definitions.mk文件里的下面這個定義：

成都創(chuàng)新互聯(lián)長期為近千家客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為四平企業(yè)提供專業(yè)的成都網(wǎng)站制作、網(wǎng)站設計、外貿(mào)網(wǎng)站建設，四平網(wǎng)站改版等技術(shù)服務。擁有十載豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

 
 

  
  
define transform-cpp-to-o 
  
  
@mkdir -p $(dir $@) 
  
  
@echo "target $(PRIVATE_ARM_MODE) C++: $(PRIVATE_MODULE) <= $<" 
  
  
$(hide) $(PRIVATE_CXX) \ 
  
  
    $(foreach incdir, \ 
  
  
        $(if $(PRIVATE_NO_DEFAULT_COMPILER_FLAGS),, \ 
  
  
        $(TARGET_PROJECT_INCLUDES) \ 
  
  
        $(TARGET_C_INCLUDES) \ 
  
  
         ) \ 
  
  
        $(PRIVATE_C_INCLUDES) \ 
  
  
      , \ 
  
  
        -I $(incdir) \ 
  
  
     ) \ 
  
  
    -c \ 
  
  
    $(if $(PRIVATE_NO_DEFAULT_COMPILER_FLAGS),, \ 
  
  
        $(TARGET_GLOBAL_CFLAGS) \ 
  
  
        $(TARGET_GLOBAL_CPPFLAGS) \ 
  
  
        $(PRIVATE_ARM_CFLAGS) \ 
  
  
     ) \ 
  
  
    -fno-rtti \ 
  
  
    $(PRIVATE_CFLAGS) \ 
  
  
    $(PRIVATE_CPPFLAGS) \ 
  
  
    $(PRIVATE_DEBUG_CFLAGS) \ 
  
  
    -MD -o $@ $< 
  
  
$(hide) $(transform-d-to-p) 
  
  
endef 
 
 

這個定義就是編譯C++文件使用的命令行。注意紅字部分，PRIVATE_C_INCLUDES中包含了項目的LOCAL_C_INCLUDES的定義 （參見binary.mk）。明顯項目自定義的搜索路徑被放在了最后。后面還有C文件的編譯命令行的定義（define transform-c-or-s-to-o-no-deps）也同樣如此。

不知道Android這樣設計是出于什么考慮。我嘗試把順序調(diào)整一下，看是否會影響Android的編譯。上述定義調(diào)整之后如下：

 
 

  
  
define transform-cpp-to-o 
  
  
@mkdir -p $(dir $@) 
  
  
@echo "target $(PRIVATE_ARM_MODE) C++: $(PRIVATE_MODULE) <= $<" 
  
  
$(hide) $(PRIVATE_CXX) \ 
  
  
    $(foreach incdir, \ 
  
  
        $(PRIVATE_C_INCLUDES) \  
  
  
$(if $(PRIVATE_NO_DEFAULT_COMPILER_FLAGS),, \ 
  
  
        $(TARGET_PROJECT_INCLUDES) \ 
  
  
        $(TARGET_C_INCLUDES) \ 
  
  
         ) \ 
  
  
      , \ 
  
  
        -I $(incdir) \ 
  
  
     ) \ 
  
  
    -c \ 
  
  
    $(if $(PRIVATE_NO_DEFAULT_COMPILER_FLAGS),, \ 
  
  
        $(TARGET_GLOBAL_CFLAGS) \ 
  
  
        $(TARGET_GLOBAL_CPPFLAGS) \ 
  
  
        $(PRIVATE_ARM_CFLAGS) \ 
  
  
     ) \ 
  
  
    -fno-rtti \ 
  
  
    $(PRIVATE_CFLAGS) \ 
  
  
    $(PRIVATE_CPPFLAGS) \ 
  
  
    $(PRIVATE_DEBUG_CFLAGS) \ 
  
  
    -MD -o $@ $< 
  
  
$(hide) $(transform-d-to-p) 
  
  
endef  
 
 

對define transform-c-or-s-to-o-no-deps也做類似調(diào)整。重新編譯后發(fā)現(xiàn)只有webkit的編譯有問題。原因在于webkit的代碼中 包含了幾個STL的頭文件（WebKit/android/stl），特別是其中的strings與bionic定義的頭文件沖突，在調(diào)整頭文件搜索順序 后，優(yōu)先選擇了這個文件。這個strings文件其實是一個空文件（除了注釋沒有任何語句），干脆刪除了它，果然編譯順利進行了，一直到編譯完成再也沒有 出現(xiàn)問題?？磥砩鲜稣{(diào)整時可行的。我用的android源代碼版本是2.0，其它版本沒有試過不知道怎么樣。BTW，如果想在編譯時打印出編譯命令，在make的參數(shù)中加上SHOW_COMMANDS=1即可。

當前標題：Android編譯系統(tǒng)中頭文件搜索路徑的順序問題
轉(zhuǎn)載注明：http://uogjgqi.cn/article/cdjopgg.html