nginx 소스 코드 분석 configure 스 크 립 트 상세 설명

nginx 소스 코드 분석 -- configure 스 크 립 트
머리말
     원본 코드 를 분석 할 때 흔히 볼 수 있 는 \ # if (NGX PCRE)... \ # endif 와 같은 코드 세그먼트 입 니 다. 이러한 디자인 은 원본 코드 를 바 꾸 지 않 고 간단 한 정의 매크로 방식 으로 기능 의 열 림 과 닫 기 를 실현 할 수 있 지만 nginx / src 디 렉 터 리 에서 매크로 NGX 를 찾 지 못 했 습 니 다.PCRE 에 대응 하 는 \ # define 문장 입 니 다.
     이벤트 모듈 을 소개 할 때 initcycle 함수 에서 cycle 를 초기 화 했 습 니 다. 그 중에서 중요 한 작업 은 모든 module 정 보 를 포함 하 는 배열 을 이 cycle 에 대응 하 는 구조 로 복사 하 는 것 입 니 다 (nginx / src / core / ngx module. c). 파일 에 함수 가 사용 하 는 module 이름 을 포함 하 는 배열 ngxmodule_names 는 원본 코드 에서 도 정의, 초기 화 를 찾 지 못 했 습 니 다.
     상기 두 가지 의문의 답 은 nginx 소스 코드 를 컴 파일 하기 전에 실 행 된. / auto / configure 명령 입 니 다. 이 명령 의 출력 에 함수, 헤더 파일 에 대한 검 측 이 표시 되 어 있 기 때문에 nginx / auto / configure 파일 에 중점 분석 을 두 어야 합 니 다. 
2. configure 스 크 립 트
     nginx 는 풍부 한 기능 옵션 을 가지 고 있 기 때문에 경험 이 있 는 사용자 들 은 모두 직접 소스 코드 를 컴 파일 하고 설치 하 는 방식 을 사용한다.컴 파일 하기 전에 다음 명령 을 실행 하여 소스 코드 의 컴 파일 을 완성 해 야 합 니 다.

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

그 중에서... / auto / configure -- with - pcre 는 원본 코드 에서 NGX 를 사용 해 야 합 니 다.PCRE 매크로, 그런데 어떻게 이 루어 졌 나 요?     
     nginx / auto / configure 파일 을 열 어 보 니 이 파일 은 셸 스 크 립 트 이 고 다른 파일 을 호출 하 였 습 니 다.

################## 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 파일 의 작성 을 간소화 할 뿐만 아니 라 서로 다른 유형의 검사 작업 도 분리 하여 작성 하고 유지 하기 편리 합 니 다.다음은 첫 번 째 부분 에서 제기 한 두 가지 문 제 를 풀 겠 습 니 다.
NGX_PCRE 매크로 정의, 이러한 매크로 정 의 는 nginx / objs / ngx 에 있 습 니 다.auto_config. h 에서 보 았 습 니 다. 이 파일 은 have = $ngx 입 니 다.have_feature. auto / have 라 는 문구 가 생 성 되 었 습 니 다.

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

     파일 중 <

#ifndef NGX_PCRE
#define NGX_PCRE 1
#endif

     첫 번 째 질문 에 답 했다. 
auto / configure 파일 에 한 줄 이 있 습 니 다. auto / modules. 이 파일 은 nginx 에 등록 할 각 모듈 의 정보 와 해당 하 는 원본 파일 을 정의 한 다음 파일 에 모듈 이름 을 정의 하 는 변수 modules 를 옮 겨 다 니 며 자동 으로 ngx 를 생 성 합 니 다.module_t *ngx_modules [] 와 char * ngxmodule_names [] 두 개의 배열 을 $NGX 에 기록 합 니 다.MODULES_C 파일 중 에두 번 째 문제 에서 두 배열 이 어디서 정 의 됐 는 지 설명 한 것 이다.

############## nginx/auto/modules ################
......
modules="$modules $MISC_MODULES"
 
cat << END                  > $NGX_MODULES_C
 
#include 
#include 
 
$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 에 컴 파일 되 지 않 습 니 다 (당연히 유효 하지 않 습 니 다).
3. 방법, 함수 검사 검증
     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="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
......

################# nginx/auto/feature ###############
......
 
#  cat   END        （   feature             C  ）
#   $NGX_AUTOTEST.c   
cat << END > $NGX_AUTOTEST.c
 
#include 
$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 를 컴 파일 하 는 개발 환경 이 일치 해 야 한 다 는 것 을 일 깨 워 준다.
 읽 어 주 셔 서 감사합니다. 여러분 에 게 도움 이 되 기 를 바 랍 니 다. 본 사이트 에 대한 여러분 의 지지 에 감 사 드 립 니 다!