[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Automake는 패키지의 ‘configure.in’을 검색해서 패키지에 어떤 정보가
있는지 결정한다. 몇개의 autoconf
매크로가 필요하고, 몇개의 변수가
‘configure.in’에 정의되어야 한다. Automake는 ‘configure.in’
안의 정보를 사용해서 더욱 알맞게 출력물을 낼 것이다.
Automake는 메인테이너를 좀더 쉽게 해주는 autoconf
매크로를 같이
포함한다. 이 매크로들은 aclocal
프로그램을 써서 자동으로
aclocal.m4
에 추가된다.
5.1 Configuration에 필요한 것 | ||
5.2 그외 Automake가 이해하는 것 | ||
5.3 aclocal.m4의 자동 생성 | ||
5.4 Automake가 제공하는 Autoconf 매크로 | ||
5.5 자기만의 aclocal 매크로 작성하기 |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Automake에서 필요한 기본적인 것을 만족시키는 가장 간단한 방법은
AM_INIT_AUTOMAKE
매크로를 사용하는 것이다 (FIXME: xref). 하지만,
더 좋아한다면, 필요한 것을 하나씩 손으로 해 나갈 수 있다.
PACKAGE
와 VERSION
변수를 AC_SUBST
와 함께 정의한다.
PACKAGE
는 배포하려고 묶을 때 나타나는 패키지의 이름이 되야
한다. 예를 들어, Automake는 PACKAGE
를 ‘automake’로
정의하였다. VERSION
은 개발된 것을 release할 때 버전 번호가 되야
한다. ‘configure.in’이 패키지에서 버전 번호가 정의된 유일한 곳으로
하라고 추천한다: 이렇게 하면 release가 간편해 진다.
Automake는 PACKAGE
나 VERSION
에 대해서 ‘Gnits’ 모드에
있을 때를 제외하고는 어떤 해석도 하지 않는다.
AC_ARG_PROGRAM
매크로를 사용한다.
AC_PROG_MAKE_SET
을 사용한다.
AM_SANITY_CHECK
를 쓴다.
AM_PROG_INSTALL
을 사용한다. 그렇지 않으면,
AC_PROG_INSTALL
.
aclocal
, autoconf
, automake
, autoheader
,
그리고 makeinfo
가 컴파일 환경에서 존재하는지 알아보려면,
AM_MISSING_PROG
를 사용한다. 다음과 같이 한다:
missing_dir=`cd $ac_aux_dir && pwd` AM_MISSING_PROG(ACLOCAL, aclocal, $missing_dir) AM_MISSING_PROG(AUTOCONF, autoconf, $missing_dir) AM_MISSING_PROG(AUTOMAKE, automake, $missing_dir) AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir) AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
그 외에 Automake가 필요로 하지만, AM_INIT_AUTOMAKE
에 의해
실행되지 않는 매크로가 여기 있다:
AC_OUTPUT
Automake는 만들어질 파일들을 결정하는 데 이 매크로를 사용한다.
Makefile
이라는 이름으로 열거된 파일들은 ‘Makefile’로
다뤄진다. 그 외에 열거된 파일들은 다른 식으로 처리된다. 현재 다른 점은
‘Makefile’들이 make distclean
에 의해 지워지지만, 다른
파일들은 make clean
으로 지워진다는 것 뿐이다.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
또한 Automake는 특정 매크로를 알아내서 적절히 만들어지는 ‘Makefile.in’을 손본다. 현재 Automake가 알아내는 매크로와 그 효과는:
AC_CONFIG_HEADER
Automake는 config header를 자동으로 다시 만들어 내는 rule을 만들어 낸다.
이 매크로를 사용하면, ‘stamp-h.in’ 파일을 소스 디렉토리에 만들어야
한다. 이 파일은 빈 파일일 수 있다. 또 ‘configure.in’의
AC_OUTPUT
명령은 ‘stamp-h’를 만들어야 한다. 예를 들어:
AC_OUTPUT(Makefile, [test -z "$CONFIG_HEADERS" || echo timestamp > stamp-h])
현재는 Automake가 AC_OUTPUT
명령이 올바른지 검사하지 않는 것에
유의하자. 바라건데 앞으로 autoconf
버전은 Automake가 이 일을
자동으로 처리하게 해 줄 것이다.
AC_CONFIG_AUX_DIR
Automake는 ‘mkinstalldirs’와 같은 여러가지 도움이 되는 스크립트를 이 매크로가 불리워진 디렉토리에서 찾을 것이다. 만약 찾을 수 없으면, 스크립트를 그 “표준” 위치(맨 위 소스 디렉토리나, 또는 현재 ‘Makefile.am’에 해당하는 소스 디렉토리 중에 적당한 곳)에서 찾는다. FIXME: give complete list of things looked for in this directory
AC_PATH_XTRA
Automake는 AC_PATH_XTRA
가 정의한 변수에 대한 정의문을 C
프로그램이나 라이브러리를 build하는 각 ‘Makefile.in’에 넣는다.
AC_CANONICAL_HOST
AC_CHECK_TOOL
Automake는 ‘config.guess’와 ‘config.sub’이 있는지 확인할 것이다. 또, ‘Makefile’ 변수 ‘host_alias’와 ‘host_triplet’이 사용될 것이다.
AC_CANONICAL_SYSTEM
이것ㅇ은 AC_CANONICAL_HOST
와 비슷하지만, ‘Makefile’ 변수
‘build_alias’와 ‘target_alias’를 정의한다.
AC_FUNC_ALLOCA
AC_FUNC_GETLOADAVG
AC_FUNC_MEMCMP
AC_STRUCT_ST_BLOCKS
AM_FUNC_FNMATCH
AM_FUNC_STRTOD
AC_REPLACE_FUNCS
AC_REPLACE_GNU_GETOPT
AM_WITH_REGEX
Automake는 적당한 소스 파일이 배포본의 일부인지를 확인할 것이다. 그리고 이 object에 대해서 적당한 의존성이 만들어졌는지 확인할 것이다. 더 많은 정보를 얻으려면 See section 라이브러리를 build하기.
LIBOBJS
Automake는 ‘.o’ 파일들을 LIBOBJS
로 넣는 문장을 찾아내고, 이
부가적인 파일들을 마치 AC_REPLACE_FUNC
를 통해 발견된 것처럼
다룰 것이다.
AC_PROG_RANLIB
AC_PROG_CXX
AM_PROG_LIBTOOL
Automake는 libtool
을 위한 처리를 할 것이다. (see The Libtool Manual in The Libtool Manual).
AC_PROG_YACC
Yacc 소스 파일이 보이면 이 매크로를 사용하거나, ‘configure.in’에 ‘YACC’ 변수를 정의해야 한다. 앞의 방법이 더 좋다.
AC_DECL_YYTEXT
AC_PROG_LEX
ALL_LINGUAS
Automake가 ‘configure.in’ 안에 이 변수가 정의된 것을 보면, Automake는 ‘po’ 디렉토리를 검사해서 여기서 언급된 모든 ‘.po’ 파일들이 있는지 확인한다. 그리고 모든 ‘.po’ 파일이 언급되었는지 확인한다.
AM_C_PROTOTYPES
자동으로 ANSI C 문법을 없애는 기능을 사용하려면, 이 매크로가 필요하다. 자동 ANSI문법 없애기를 보라.
AM_GNU_GETTEXT
GNU gettext(see section Gettext)를 사용하는 패키지에 이 매크로가 필요하다. 이 매크로는 gettext와 함께 배포된다. Automake가 이 매크로를 보면, 패키지가 gettext에서 필요한 것들을 만족하는지 확인한다.
AM_MAINTAINER_MODE
이 매크로는 configure
에 ‘--enable-maintainer-mode’ 옵션을
붙인다. 이 매크로가 쓰이면, automake
는 만들어 지는
‘Makefile.in’에서 기본으로 “maintainer만 사용하는” rule 들을
없애도록 한다. 이 매크로는 ‘Gnits’ 모드에서는 사용할 수 없다.
FIXME xref.
AC_SUBST
AC_CHECK_TOOL
AC_CHECK_PROG
AC_CHECK_PROGS
AC_PATH_PROG
AC_PATH_PROGS
각각의 매크로에 대하여 첫번째 arugment는 자동으로 각각의 만들어지는 ‘Makefile.in’의 변수로 정의도니다.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Automake는 패키지 내에서 쓰일 여러개의 Autoconf 매크로를 포함한다;
몇개는 실제로 특정 상황에서만 필요하다. 이러한 매크로는
‘aclocal.m4’에 정의되야 한다; 그렇지 않으면, autoconf
가
찾아내지 못할 것이다.
aclocal
프로그램은 자동으로 ‘aclocal.m4’ 파일을
‘configure.in’ 내용에 기초해서 만든다. 이 프로그램은 여기저기
돌아다닐 필요없이 Automake가 제공하는 매크로를 사용을 편리하게 해 준다.
또, 이러한 aclocal
의 방법은 또다른 패키지에서 사용할때 확장할 수
있다.
aclocal
이 시작할때, 매크로 정의를 찾아 내기 위해서, 찾을 수 있는
모든 ‘.m4’ 파일을 검색한다. 그 다음에 ‘configure.in’을
검색한다. 첫번째 단계에서 발견되는 매크로중 하나라도 언급되어 있으면 그
매크로와 그 매크로에서 필요한 다른 매크로들을 ‘aclocal.m4’에 집어
넣는다.
aclocal
에 다음 옵션을 줄 수 있다:
--acdir=dir
설치 디렉토리 대신에 dir에서 매크로 파일들을 찾는다. 보통 이 옵션은 디버깅을 위해 사용된다.
--help
명령 행 옵션의 요약을 표시하고 종료한다.
--output=file
출력을 ‘aclocal.m4’ 대신에 file로 쓴다.
--verbose
검사하고 있는 파일의 이름들을 출력한다.
--version
Automake의 버전 번호를 표시하고 종료한다.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
AM_CONFIG_HEADER
Automake는 컨피그 헤더(config header) 파일을 자동으로 다시 만드는 룰(rule)을 만들어 낼 것이다. 이 매크로를 사용하면, ‘stamp-h.in’ 파일을 소스 디렉토리에 만들어야 한다. 이 파일은 텅 빈 파일일 수 있다.
AM_CYGWIN32
configure
가 ‘Cygwin32’ 환경에서 동작하는지 체크한다.
(FIXME xref). 만약 그렇다면, 변수 EXEEXT
를 ‘.exe’로
정의한다; 그렇지 않으면 이 변수를 빈 문자열로 한다. Automake는 이
매크로를 발견하면, ‘Cygwin32’에서 자동으로 동작하는
‘Makefile.in’을 만들도록 할 것이다. ‘Cygwin32’ 환경에서,
gcc
는 파일 이름이 ‘.exe’로 끝나는 실행 파일을 만든다 (비록
명령행에서 ‘.exe’를 명시할 필요는 없지만). Automake는 이것을
멋지게 처리하는 특별한 코드를 ‘Makefile.in’에 추가한다.
AM_FUNC_STRTOD
strtod
함수를 사용할 수 없거나, 올바르게 동작하지 않으면 (SunOS
5.4의 함수처럼), ‘strtod.o’를 LIBOBJS
변수에 출력한다.
AM_FUNC_ERROR_AT_LINE
AM_FUNC_MKTIME
AM_FUNC_OBSTACK
AM_C_PROTOTYPES
함수 원형(prototype)이 컴파일러가 알아듣는지 확인한다. 만약 그렇다면, ‘PROTOTYPES’를 정의하고, 변수 ‘U’와 ‘ANSI2KNR’을 빈 문자열로 정의한다. 그렇지 않으면, ‘U’를 ‘_’로 정의하고, ‘ANSI2KNR’을 ‘./ansi2knr’로 정의한다. Automake는 이 값들을 자동으로 ANSI C 기능을 없애는 데 사용한다.
AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL
TIOCGWINSZ
를 쓸때 ‘<sys/ioctl.h>’가 필요하면,
GWINSZ_IN_SYS_IOCTL
을 정의한다. 아니면,
TIOCGWINSZ
는 ‘<termios.h>’에 있을 수도 있다.
AM_INIT_AUTOMAKE
대부분의 ‘configure.in’에서 필요한 많은 매크로들을 실행한다. 이
매크로는 두개의 인수로 패키지와 버전 번호가 필요하다. 기본적으로,
이 매크로는 ‘PACKAGE’와 ‘VERSION’을 AC_DEFINE
한다.
이 기능은 세번째 인수로 무언가를 넘겨주면 피할 수 있다.
AM_PATH_LISPDIR
emacs
프로그램을 찾는다. 그리고 찾으면, 출력 변수
lispdir
을 Emacs의 site-lisp 디렉토리의 경로(full path)로 맞춘다.
AM_PROG_CC_STDC
만약 C 컴파일러가 기본적으로 ANSI C 모드가 아니면, 옵션을 추가해서
CC
가 ANSI C 모드로 동작하도록 시도한다. 이 매크로는 여러가지
시스템에서 ANSI C를 선택하는 옵션들을 시도해 본다. 만약
__STDC__
가 1이고, 함수 원형(prototype)을 제대로 처리하면 ANSI C
모드라고 생각한다.
이 매크로를 쓰면, 매크로가 실행된 뒤에 C 컴파일러가 ANSI C를
받아들이도록 맞춰졌는지 확인해야 한다; 그렇지 않으면, 셸 변수
am_cv_prog_cc_stdc
가 ‘no’로 정의된다. 소스 코드가 ANSI C로
되어 있으면, ansi2knr
옵션을 써서 ANSI 기능을 없앤 카피를 만들 수
있다.
AM_PROG_INSTALL
AM_SANITY_CHECK
이 매크로는 빌드(build) 디렉토리에서 생성되는 파일이 소스 디렉토리의
파일보다 최근에 만들어졌는지 확인한다. 이 기능은 시계가 잘못 맞춰진
시스템에서는 실패한다. 이 매크로는 AM_INIT_AUTOMAKE
에서 자동으로
실행된다.
AM_SYS_POSIX_TERMIOS
시스템에서 POSIX termios 헤더와 함수가 사용 가능한지 검사한다.
가능하다면, am_cv_sys_posix_termios
셸 변수를 ‘yes’로
정의한다. 그렇지 않으면, 변수를 ‘no’로 정의한다.
AM_TYPE_PTRDIFF_T
AM_WITH_DMALLOC
dmalloc
패키지 지원을 추가한다. 사용자가 ‘--with-dmalloc’
옵션을 붙여서 configure를 하면, WITH_DMALLOC
을 정의하고,
LIBS
에 ‘-ldmalloc’을 추가한다. dmalloc
패키지는
ftp://ftp.letters.com/src/dmalloc/dmalloc.tar.gz에 있다.
AM_WITH_REGEX
configure
명령행에 ‘--with-regex’을 추가한다. 만약
이 매크로가 사용된다면 (사용되는 것이 기본), ‘regex’ 정규식(regular
expression) 라이브러리가 사용되고, ‘regex.o’가 ‘LIBOBJS’에
추가되고, ‘WITH_REGEX’가 정의된다. ‘--without-regex’ 옵션이
있다면, ‘rx’ 정규식(regular expression) 라이브러리가 사용되고,
‘rx.o’가 ‘LIBOBJS’에 추가된다.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Aclocal은 내부적으로 어떤 매크로에 대해서도 알지 못하기 때문에, 자기만의 매크로를 가지고 확장하는 것은 쉬운 일이다.
확장하는 것은 다른 프로그램에서 사용할때 쓰이는 고유한 Autoconf 매크로를
포함하는 라이브러리가 사용한다. 예를 들어, gettext
라이브러리는
gettext
를 쓰는 어떤 패키지든지 사용해야 하는
AM_GNU_GETTEXT
매크로를 포함한다. 라이브러리가 설치되면,
라이브러리는 aclocal
이 찾을 수 있도록 이 매크로를 설치한다.
매크로 파일은 AC_DEFUN
의 연속이어야 한다. 또 aclocal
은
AC_REQUIRE
를 알아보기 때문에, 각각의 매크로를 다른 파일에 넣는
것도 가능하다.
매크로 파일의 이름은 ‘.m4’로 끝나야 한다. 이러한 파일은 ‘$(datadir)/aclocal’에 설치되어야 한다.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on February 24, 2015 using texi2html 5.0.