nginx的自动脚本指的是configure脚本程序和auto子目录下面的脚本程序。自动脚本完成两件事情,其一是检查环境,其二是生成文件。生成的文件有两类,一类是编译代码需要的Makefile文件,一类是根据环境检查结果生成的c代码。生成的Makefile很干净,也很容易阅读。生成的c代码有三个文件,ngx_auto_config.h是根据环境检查的结果声明的一些宏定义,这个头文件被include进ngx_core.h中,所以会被所有的源码引用到,这确保了源码是可移植的;ngx_auto_headers.h中也是一些宏定义,不过是关于系统头文件存在性的声明;ngx_modules.c是默认被包含进系统中的模块的声明,如果想去掉一些模块,只要修改这个文件即可。
configure是自动脚本的总驱动,它通过组合auto目录下不同功能的脚本程序完成环境检查和生成文件的任务。环境检查主要是三个部分:编译器版本及支持特性、操作系统版本及支持特性、第三方库支持,检查的脚本程序分别存放在auto/cc、auto/os、auto/lib三个子目录中。检查的方法很有趣,通过自动编译用于检查某个特性的代码片段,根据编译器的输出情况判定是否支持该种特性。根据检查的情况,如果环境足以支持运行一个简单版本的nginx,就会生成Makefile和c代码,这些文件会存放在新创建的objs目录下。当然,也可能会失败,假如系统不支持pcre和ssh,如果没有屏蔽掉相关的模块,自动脚本就会失败。
auto目录下的脚本职能划分非常清晰,有检查环境的,有检查模块的,有提供帮助信息的(./configure --help),有处理脚本参数的,也有一些脚本纯粹是为了模块化自动脚本而设计出来的,比如feature脚本是用于检查单一特性的,其他的环境检查脚本都会调用这个脚本去检查某个特性。还有一些脚本是用来输出信息到生成文件的,比如have、nohave、make、install等。
之所以要在源码分析中专门谈及自动脚本,是因为nginx的自动脚本不是用autoconf之类的工具生成的,而是作者手工编写的,并且包含一定的设计成分,对于需要编写自动脚本的人来说,有很高的参考价值。这里也仅仅是粗略的介绍一下,需要详细了解最好是读一下这些脚本,这些脚本并没有使用多少生僻的语法,可读性是不错的。
btw,后面开始进入真正的源码分析阶段,nginx的源码中有非常多的结构体,这些结构体之间引用也很频繁,很难用文字表述清楚之间的关系,觉得用图表是最好的方式,因此需要掌握一种高效灵活的作图方法,我选择的是graphviz,这是at&t贡献的跨平台的图形生成工具,通过写一种称为“the dot language”的脚本语言,然后用dot命令就可以直接生成指定格式的图,很方便。
configure是自动脚本的总驱动,它通过组合auto目录下不同功能的脚本程序完成环境检查和生成文件的任务。环境检查主要是三个部分:编译器版本及支持特性、操作系统版本及支持特性、第三方库支持,检查的脚本程序分别存放在auto/cc、auto/os、auto/lib三个子目录中。检查的方法很有趣,通过自动编译用于检查某个特性的代码片段,根据编译器的输出情况判定是否支持该种特性。根据检查的情况,如果环境足以支持运行一个简单版本的nginx,就会生成Makefile和c代码,这些文件会存放在新创建的objs目录下。当然,也可能会失败,假如系统不支持pcre和ssh,如果没有屏蔽掉相关的模块,自动脚本就会失败。
auto目录下的脚本职能划分非常清晰,有检查环境的,有检查模块的,有提供帮助信息的(./configure --help),有处理脚本参数的,也有一些脚本纯粹是为了模块化自动脚本而设计出来的,比如feature脚本是用于检查单一特性的,其他的环境检查脚本都会调用这个脚本去检查某个特性。还有一些脚本是用来输出信息到生成文件的,比如have、nohave、make、install等。
之所以要在源码分析中专门谈及自动脚本,是因为nginx的自动脚本不是用autoconf之类的工具生成的,而是作者手工编写的,并且包含一定的设计成分,对于需要编写自动脚本的人来说,有很高的参考价值。这里也仅仅是粗略的介绍一下,需要详细了解最好是读一下这些脚本,这些脚本并没有使用多少生僻的语法,可读性是不错的。
btw,后面开始进入真正的源码分析阶段,nginx的源码中有非常多的结构体,这些结构体之间引用也很频繁,很难用文字表述清楚之间的关系,觉得用图表是最好的方式,因此需要掌握一种高效灵活的作图方法,我选择的是graphviz,这是at&t贡献的跨平台的图形生成工具,通过写一种称为“the dot language”的脚本语言,然后用dot命令就可以直接生成指定格式的图,很方便。