Oracle 系统管理 - Linux 系统 - Backtrack 5 - 安全 - Juniper 技术 - Cisco 技术 - 思科模拟器 - Cisco 认证 - Cisco ios 下载

您现在的位置是:Docker > Centos > nginx源码分析 configure脚本

nginx源码分析 configure脚本

时间:2018-06-09 15:26  来源:未知  阅读次数: 复制分享 我要评论

一、前言
     在分析源码时,经常可以看到类似 #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脚本,并调用了一些其他文件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
################## nginx/auto/configure  #######################
#!/bin/sh
 
# Copyright (C) Igor Sysoev
# Copyright (C) Nginx, Inc.
 
LC_ALL=C
export 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_H
echo > $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=1
fi
 
.....
 
. 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/define  
have=NGX_CONF_PATH value="\"$NGX_CONF_PATH\"" . auto/define
have=NGX_PID_PATH value="\"$NGX_PID_PATH\"" . auto/define
 
......

 

     上面简要介绍了nginx/auto/configure文件中的一些内容,configure并没有把工作全部集中于该文件内部,而是提供了一个框架,具体的工作交由auto/threads、auto/headers等文件来完成,并且采用 . auto/conf 这种调用方式,这样可以做到变量共享;这种做法既简化了configure文件的编写,也不同类型的检查工作拆分开,便于编写、维护。下面就来解答第一部分提出的两个问题:
  1. NGX_PCRE宏定义,这类的宏定义可以在nginx/objs/ngx_auto_config.h中看到,这个文件是由have=$ngx_have_feature . auto/have这样的语句生成的。
    1
    2
    3
    4
    5
    6
    7
    8
    ################  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文件中。效果如下:
1
2
3
4
#ifndef NGX_PCRE
#define NGX_PCRE  1
#endif
     这就回答了第一个问题。
 
  1. auto/configure文件中有一行. auto/modules, 这个文件中定义了要注册到nginx中各个模块的信息以及对应的源文件,然后遍历文件中包含所有定义模块名称的变量modules,自动生成ngx_module_t *ngx_modules[]和char *ngx_module_names[]两个数组,并写入到 $NGX_MODULES_C文件中。这就解释了第二个问题中两个数组是从哪里定义的问题了。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    ############## 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 $modules
    do
        echo "extern ngx_module_t  $mod;"         >> $NGX_MODULES_C
    done
     
    #定义并初始化ngx_module_t *ngx_modules[] 数组,然后输出重定向到$NGX_MODULES_C
    echo                                          >> $NGX_MODULES_C
    echo 'ngx_module_t *ngx_modules[] = {'        >> $NGX_MODULES_C
     
    for mod in $modules
    do
        echo "    &$mod,"                         >> $NGX_MODULES_C
    done
     
    cat << END                                    >> $NGX_MODULES_C
        NULL
    };
     
    END
     
    #定义并初始化char *ngx_module_names[]数组,然后输出重定向到$NGX_MODULES_C
    echo 'char *ngx_module_names[] = {'           >> $NGX_MODULES_C
     
    for mod in $modules
    do
        echo "    \"$mod\","                      >> $NGX_MODULES_C
    done
     
    cat << END                                    >> $NGX_MODULES_C
        NULL
    };
     
    END
    .......

    nginx/auto/modules这个文件生成的两个数组用于cycle的初始化,因此如果开发者开发的模块要添加到nginx中,一定要记得修改nginx/auto/modules这个文件,否则是不会被编译到nginx中的(当然不会生效啦)。

三、方法、函数检查验证
     由于nginx跨平台的特性,因此增加了很多位于不同平台下的函数(这些与平台有关的函数、方法也是通过宏定义的方式来决定是否调用),nginx在configure的时候需要找出当前环境中支持的方法、函数,然后将这些支持的方法、函数用宏定义的方式来确定下来。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
################# nginx/auto/unix  ###############
......
#定义当前feature的各个元素
ngx_feature="poll()"
ngx_feature_name=
ngx_feature_run=no
ngx_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不可用,就将相应的宏设置为NONE
if [ $ngx_found = no ]; then
    EVENT_POLL=NONE
fi
......
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
################# 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_AUTOTEST
eval "/bin/sh -c \"$ngx_test\" >> $NGX_AUTOCONF_ERR 2>&1"
 
#检查是否成功生成可执行程序$NGX_AUTOTEST
if [ -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的开发环境要保持一致
相关资讯