nginx源码分析configure脚本详解

2024-02-21 23:32:03 46

nginx源码分析——configure脚本

一、前言

在分析源码时，经常可以看到类似#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拥有丰富的功能选项，因此有经验的使用者都会采用直接源码编译、安装的方式。在编译前，需要通过执行如下命令来完成源代码的编译。

cdnginx;./auto/configure--with-pcre&&make

其中./auto/configure--with-pcre就是需要在源码中启用NGX_PCRE宏，但是如何实现的呢？

打开nginx/auto/configure文件，发现该文件是一个shell脚本，并调用了一些其他文件

##################nginx/auto/configure#######################
#!/bin/sh

#Copyright(C)IgorSysoev
#Copyright(C)Nginx,Inc.

LC_ALL=C
exportLC_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"#defineNGX_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_PATHvalue="\"$NGX_SBIN_PATH\"".auto/define
have=NGX_CONF_PATHvalue="\"$NGX_CONF_PATH\"".auto/define
have=NGX_PID_PATHvalue="\"$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这样的语句生成的。

################nginx/auto/have##############
cat<>$NGX_AUTO_CONFIG_H

#ifndef$have
#define$have1
#endif

END

文件中<<符号是来告知shell标准输入来自一对分隔符（可以使字符串、数字等类型，只要保证开头和结尾的一致）中间的内容；所以，have文件中的命令就是利用cat将分隔符END之间的5行内容追加到$NGX_AUTO_CONFIG_H文件中。效果如下：

#ifndefNGX_PCRE
#defineNGX_PCRE1
#endif

这就回答了第一个问题。

auto/configure文件中有一行.auto/modules，这个文件中定义了要注册到nginx中各个模块的信息以及对应的源文件，然后遍历文件中包含所有定义模块名称的变量modules，自动生成ngx_module_t*ngx_modules[]和char*ngx_module_names[]两个数组，并写入到$NGX_MODULES_C文件中。这就解释了第二个问题中两个数组是从哪里定义的问题了。

##############nginx/auto/modules################
......
modules="$modules$MISC_MODULES"

cat<$NGX_MODULES_C

#include
#include

$NGX_PRAGMA

END

#声明模块为全局变量
formodin$modules
do
echo"externngx_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

formodin$modules
do
echo"&$mod,">>$NGX_MODULES_C
done

cat<>$NGX_MODULES_C
NULL
};

END

#定义并初始化char*ngx_module_names[]数组，然后输出重定向到$NGX_MODULES_C
echo'char*ngx_module_names[]={'>>$NGX_MODULES_C

formodin$modules
do
echo"\"$mod\",">>$NGX_MODULES_C
done

cat<>$NGX_MODULES_C
NULL
};

END
.......

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

三、方法、函数检查验证

由于nginx跨平台的特性，因此增加了很多位于不同平台下的函数（这些与平台有关的函数、方法也是通过宏定义的方式来决定是否调用），nginx在configure的时候需要找出当前环境中支持的方法、函数，然后将这些支持的方法、函数用宏定义的方式来确定下来。

#################nginx/auto/unix###############
......
#定义当前feature的各个元素
ngx_feature="poll()"
ngx_feature_name=
ngx_feature_run=no
ngx_feature_incs="#include"
ngx_feature_path=
ngx_feature_libs=
#测试当前feature是否可用的代码段
ngx_feature_test="intn;structpollfdpl;
pl.fd=0;
pl.events=0;
pl.revents=0;
n=poll(&pl,1,0);
if(n==-1)return1"
#利用上面定义的各个变量测试poll()函数这个feature是否可用
.auto/feature

#如果上述的测试结果表明该feature不可用，就将相应的宏设置为NONE
if[$ngx_found=no];then
EVENT_POLL=NONE
fi
......

#################nginx/auto/feature###############
......

#利用cat命令将END分隔符之间的内容（与测试feature的代码段组合成的一个简单的C程序）
#写到$NGX_AUTOTEST.c文件中
cat<$NGX_AUTOTEST.c

#include
$NGX_INCLUDE_UNISTD_H
$ngx_feature_incs

intmain(void){
$ngx_feature_test;
return0;
}

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_ERR2>&1"

#检查是否成功生成可执行程序$NGX_AUTOTEST
if[-x$NGX_AUTOTEST];then
#根据feature的类型，采用不同的方案验证feature的可行性
case"$ngx_feature_run"in
yes)
#/bin/shisusedtointercept"Killed"or"Aborttrap"messages
#执行对应的可执行程序，并重定向输出
if/bin/sh-c$NGX_AUTOTEST>>$NGX_AUTOCONF_ERR2>&1;then
#执行成功，将ngx_found设成yes，表示该feature可用
echo"found"
ngx_found=yes

#调用auto/have文件，在$NGX_AUTO_CONFIG_H文件中，设置该feature对应的宏的值为1（启用该feature）
iftest-n"$ngx_feature_name";then
have=$ngx_have_feature.auto/have
fi

else
echo"foundbutisnotworking"
fi
;;
......

nginx的这种demo验证机制，既做到了检查当前系统是否拥有对应的方法、函数，也验证了拥有的方法、函数是否提供了期望的功能。这种情况也提醒我们，运行nginx的生产环境与编译nginx的开发环境要保持一致。

感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！

nginx源码分析configure脚本详解

热门推荐

随机推荐