一、前言

???? 在分析源碼時，經?？梢钥吹筋愃?#if (NGX_PCRE) .... #endif 這樣的代碼段，這樣的設計可以在不改動源碼的情況下，通過簡單的定義宏的方式來實現功能的打開與關閉，但是在nginx/src目錄下始終沒有找到宏 NGX_PCRE 對應的 #define 語句。

???? 在之前介紹event模塊的時候，講到init_cycle函數中對cycle進行了初始化，其中很重要一步操作就是講包含所有module信息的數組拷貝到這個cycle對應的結構中（nginx/src/core/ngx_module.c），文件中函數用到的包含module名稱的數組ngx_module_names在源碼中也沒找到定義、初始化。

???? 上述兩個疑問的答案應該在對nginx源碼編譯前執行的./auto/configure命令，因為該命令的輸出中顯示了對一些函數、頭文件的檢測，所以就將重點分析放到nginx/auto/configure文件中。?

二、configure腳本

???? 由于nginx擁有豐富的功能選項，因此有經驗的使用者都會采用直接源碼編譯、安裝的方式。在編譯前，需要通過執行如下命令來完成源代碼的編譯。

?

1	cd nginx; ./auto/configure --with-pcre && make

其中./auto/configure --with-pcre 就是需要在源碼中啟用NGX_PCRE宏，但是如何實現的呢？?????

???? 打開nginx/auto/configure文件，發現該文件是一個shell腳本，并調用了一些其他文件

?

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758

################## nginx/auto/configure ########################!/bin/sh??# Copyright (C) Igor Sysoev# Copyright (C) Nginx, Inc.??LC_ALL=Cexport LC_ALL??#執行auto/options文件中的命令，行中的“.”表示在當前的sh環境中執行auto/options#文件中的命令（與source命令效果一樣）不同于sh命令會導致創建子進程，由于configure#文件中命令與options的命令都在同一sh環境下，所以變量在兩個文件中都是彼此可見的. auto/options?? #設置變量，并將之置空. auto/init???? #初始化一些變量諸如：NGX_AUTO_HEADERS_H=$NGX_OBJS/ngx_auto_headers.h. auto/sources?? #設置核心模塊、平臺代碼對應的源文件??test -d $NGX_OBJS || mkdir -p $NGX_OBJS??echo > $NGX_AUTO_HEADERS_Hecho > $NGX_AUTOCONF_ERR??echo "#define NGX_CONFIGURE \"$NGX_CONFIGURE\"" > $NGX_AUTO_CONFIG_H??if [ $NGX_DEBUG = YES ]; then??have=NGX_DEBUG . auto/have?? #設置NGX_DEBUG=1fi??.....??. auto/cc/conf?? #檢查編譯器相關選項??if [ "$NGX_PLATFORM" != win32 ]; then??. auto/headers?? #檢查相關頭文件，并將結果輸出到ngx_auto_headers.h文件中fi??. auto/os/conf?? #檢查系統平臺所需的函數??if [ "$NGX_PLATFORM" != win32 ]; then??. auto/unix?? #檢查unix環境下一些文件、函數fi???. auto/threads??#統計要編譯到nginx中的模塊信息，創建并初始化ngx_module_t *ngx_modules[]和#char *ngx_module_names[]兩個數組中（這兩個數組在init_cycle中被調用）存放#到之前創建的nginx/objs/ngx_modules.c文件中. auto/modules?. auto/lib/conf??.......??#定義變量NGX_SBIN_PATH的值為"\"$NGX_SBIN_PATH\""have=NGX_SBIN_PATH value="\"$NGX_SBIN_PATH\"" . auto/definehave=NGX_CONF_PATH value="\"$NGX_CONF_PATH\"" . auto/definehave=NGX_PID_PATH value="\"$NGX_PID_PATH\"" . auto/define??......

???? 上面簡要介紹了nginx/auto/configure文件中的一些內容，configure并沒有把工作全部集中于該文件內部，而是提供了一個框架，具體的工作交由auto/threads、auto/headers等文件來完成，并且采用 . auto/conf 這種調用方式，這樣可以做到變量共享；這種做法既簡化了configure文件的編寫，也不同類型的檢查工作拆分開，便于編寫、維護。下面就來解答第一部分提出的兩個問題：

NGX_PCRE宏定義，這類的宏定義可以在nginx/objs/ngx_auto_config.h中看到，這個文件是由have=$ngx_have_feature . auto/have這樣的語句生成的。

?

12345678

################ nginx/auto/have ##############cat << END >> $NGX_AUTO_CONFIG_H??#ifndef $have#define $have 1#endif??END

???? 文件中<<符號是來告知shell標準輸入來自一對分隔符（可以使字符串、數字等類型，只要保證開頭和結尾的一致）中間的內容；所以，have文件中的命令就是利用cat將分隔符END之間的5行內容追加到$NGX_AUTO_CONFIG_H文件中。效果如下：

?

123	#ifndef NGX_PCRE#define NGX_PCRE 1#endif

???? 這就回答了第一個問題。?

auto/configure文件中有一行. auto/modules， 這個文件中定義了要注冊到nginx中各個模塊的信息以及對應的源文件，然后遍歷文件中包含所有定義模塊名稱的變量modules，自動生成ngx_module_t *ngx_modules[]和char *ngx_module_names[]兩個數組，并寫入到 $NGX_MODULES_C文件中。這就解釋了第二個問題中兩個數組是從哪里定義的問題了。

?

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748

############## nginx/auto/modules ################......modules="$modules $MISC_MODULES"??cat << END????????????????? > $NGX_MODULES_C??#include <ngx_config.h>#include <ngx_core.h>??$NGX_PRAGMA??END??#聲明模塊為全局變量for mod in $modulesdo??echo "extern ngx_module_t $mod;"???? >> $NGX_MODULES_Cdone??#定義并初始化ngx_module_t *ngx_modules[] 數組，然后輸出重定向到$NGX_MODULES_Cecho???????????????????? >> $NGX_MODULES_Cecho 'ngx_module_t *ngx_modules[] = {'??? >> $NGX_MODULES_C??for mod in $modulesdo??echo "? &$mod,"???????????? >> $NGX_MODULES_Cdone??cat << END????????????????? >> $NGX_MODULES_C??NULL};??END??#定義并初始化char *ngx_module_names[]數組，然后輸出重定向到$NGX_MODULES_Cecho 'char *ngx_module_names[] = {'????? >> $NGX_MODULES_C??for mod in $modulesdo??echo "? \"$mod\","?????????? >> $NGX_MODULES_Cdone??cat << END????????????????? >> $NGX_MODULES_C??NULL};??END.......

nginx/auto/modules這個文件生成的兩個數組用于cycle的初始化，因此如果開發者開發的模塊要添加到nginx中，一定要記得修改nginx/auto/modules這個文件，否則是不會被編譯到nginx中的（當然不會生效啦）。

三、方法、函數檢查驗證

???? 由于nginx跨平臺的特性，因此增加了很多位于不同平臺下的函數（這些與平臺有關的函數、方法也是通過宏定義的方式來決定是否調用），nginx在configure的時候需要找出當前環境中支持的方法、函數，然后將這些支持的方法、函數用宏定義的方式來確定下來。

?

123456789101112131415161718192021222324

################# nginx/auto/unix ###############......#定義當前feature的各個元素ngx_feature="poll()"ngx_feature_name=ngx_feature_run=nongx_feature_incs="#include <poll.h>"ngx_feature_path=ngx_feature_libs=#測試當前feature是否可用的代碼段ngx_feature_test="int n; struct pollfd pl;?????????pl.fd = 0;?????????pl.events = 0;?????????pl.revents = 0;?????????n = poll(&pl, 1, 0);?????????if (n == -1) return 1"#利用上面定義的各個變量測試poll()函數這個feature是否可用. auto/feature??#如果上述的測試結果表明該feature不可用，就將相應的宏設置為NONEif [ $ngx_found = no ]; then??EVENT_POLL=NONEfi......

?

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950

################# nginx/auto/feature ###############......??#利用cat命令將END分隔符之間的內容（與測試feature的代碼段組合成的一個簡單的C程序）#寫到 $NGX_AUTOTEST.c文件中cat << END > $NGX_AUTOTEST.c??#include <sys/types.h>$NGX_INCLUDE_UNISTD_H$ngx_feature_incs??int main(void) {??$ngx_feature_test;??return 0;}??END??#將編譯鏈接$NGX_AUTOTEST.c的命令賦值給ngx_test變量ngx_test="$CC $CC_TEST_FLAGS $CC_AUX_FLAGS $ngx_feature_inc_path \?????-o $NGX_AUTOTEST $NGX_AUTOTEST.c $NGX_TEST_LD_OPT $ngx_feature_libs"??ngx_feature_inc_path=??#執行ngx_test變量指向的編譯、鏈接指令，完成對$NGX_AUTOTEST.c的編譯、鏈接生成可執行程序NGX_AUTOTESTeval "/bin/sh -c \"$ngx_test\" >> $NGX_AUTOCONF_ERR 2>&1"??#檢查是否成功生成可執行程序$NGX_AUTOTESTif [ -x $NGX_AUTOTEST ]; then???#根據feature的類型，采用不同的方案驗證feature的可行性??case "$ngx_feature_run" in????yes)??????# /bin/sh is used to intercept "Killed" or "Abort trap" messages??????#執行對應的可執行程序，并重定向輸出??????if /bin/sh -c $NGX_AUTOTEST >> $NGX_AUTOCONF_ERR 2>&1; then????????#執行成功，將ngx_found設成yes，表示該feature可用????????echo " found"????????ngx_found=yes??????????#調用auto/have文件，在$NGX_AUTO_CONFIG_H 文件中，設置該feature對應的宏的值為1（啟用該feature）????????if test -n "$ngx_feature_name"; then??????????have=$ngx_have_feature . auto/have????????fi????????else????????echo " found but is not working"??????fi????;;......

??? nginx的這種demo驗證機制，既做到了檢查當前系統是否擁有對應的方法、函數，也驗證了擁有的方法、函數是否提供了期望的功能。這種情況也提醒我們，運行nginx的生產環境與編譯nginx的開發環境要保持一致。

?感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！

總結

以上是生活随笔為你收集整理的nginx源码分析configure脚本详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。