[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2 일반적인 아이디어

다음에서는 어떻게 Automake가 동작하는지 이해하는데 필요한 기초적인 아이디어들을 다룬다.


[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.1 일반적인 동작

Automake가 동작하면 ‘Makefile.am’ 파일을 읽고, ‘Makefile.in’ 파일을 만든다. ‘Makefile.am’에 정의할 수 있는 매크로(macro)와 타겟(target(1))중에서 특정한 몇개는 Automake가 더욱 특별한 코드를 만들도록 알려 주는 역할을 한다; 예를 들어 ‘bin_PROGRAMS’ 매크로를 정의하면 컴파일되고, 링크되야 하는 타겟을 ‘Makefile.in’에 만들어낼 것이다.

Makefile.am’ 안의 매크로 정의와 타겟은, 앞으로 만들어 질 ‘Makefile.in’ 파일에 그대로 복사된다. 그러므로 어떤 임의의 코드라도 생성되는 ‘Makefile.in’ 파일에 집어넣을 수 있다. 예를 들어 Automake 배포판에는 비표준적인 cvs-dist 타겟이 들어있다. 이 타겟은 Automake 관리자가 소스 콘트롤 시스템에서 배포판을 만들때 이용한다.

Automake는 GNU make만의 확장기능을 이해하지 못한다는 점에 유의하기 바란다. ‘Makefile.am’에 그런 확장 기능을 사용하면 애러를 내거나, 괴상하게 동작할 것이다.

Automake는 똑똑한 방법으로 주석문을 인접한 타겟과 매크로 정의에 모아 놓는다.

보통 ‘Makefile.am’에 정의된 타겟이 automake가 자동으로 생성해 내는 같은 이름의 타겟보다 우선하고, 같은 이름이 있으면 재정의된다. 이것은 지원되는 기능중 하나이지만, 이 기능을 사용하지 않는 것이 좋다. 왜냐하면 이렇게 자동으로 생성되는 룰이 상세하게 잘 만들어져 있기 때문이다.

마찬가지로, ‘Makefile.am’에 변수를 정의하면 일반적으로 automake가 자동으로 만들어 내는 변수의 정의를 무시하고 재정의한다. 이 기능은 타겟의 정의를 재정의하는 기능보다 더 유용할 때가 훨씬 많다. 하지만, automake가 만들어 내는 많은 변수들은 내부적으로 사용된다고 가정하고 만들어 졌으므로, 훗날 그 이름이 바뀔 수도 있다는 것을 경고해 둔다.

Automake가 변수의 정의를 검사할 때, Automake는 재귀적으로 그 변수정의에 또 다른 변수가 들어가 있는지 검사할 것이다. 그 예로, Automake가 다음 부분에서 ‘foo_SOURCES’의 내용을 검사할 때,

xs = a.c b.c
foo_SOURCES = c.c $(xs)

foo_SOURCES’의 값으로 ‘a.c’, ‘b.c’, 그리고 ‘c.c’ 파일을 사용하게 될 것이다.

Automake의 주석문중에는 ‘Makefile.in’에 출력될 때 복사되지 않는 주석문도 있다; ‘##’로 시작하는 모든 줄은 Automake가 완전히 무시한다.

Makefile.am’의 첫번째 줄은 관례적으로 다음과 같이 한다:

## Process this file with automake to produce Makefile.in

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.2 깊이

automake는 세 가지 종류의 디렉토리 계층구조를 지원한다; ‘flat’, ‘shallow’, 그리고 ‘deep’이다.

flat 패키지는 모든 파일들이 한개의 디렉토리에 들어 있는 패키지이다. 정의가 이러하므로 flat 패키지의 ‘Makefile.am’는 SUBDIRS 매크로가 없다. 이러한 패키지의 한 예는 termutils이다.

deep 패키지는 모든 소스 파일이 서브디렉토리에 있는 패키지이다; 맨 위 디렉로티는 주로 설정 파일들만 들어 있다. GNU cpio는 이러한 패키지의 좋은 예이고, GNU tar도 그렇다. deep 패키지에서 맨 위 디렉토리의 ‘Makefile.am’는 SUBDIRS 매크로가 있고, 반면 이 파일의 어떤 매크로에서도 빌드해야 할 파일을 정의하지 않을 것이다.

shallow 패키지는 주요 소스가 맨 위 디렉토리에 있고, 다른 여러가지 부분(보통 라이브러리)이 서브디렉토리에 있는 패키지이다. automake는 그러한 패키지이다. (현재 automake를 사용하지 않긴 하지만, GNU make도 그렇다.)


[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.3 엄격성

Automake는 GNU 패키지 관리자가 쓰도록 한 것이지만, Automake를 사용하고 싶으면서, GNU의 관습 전부를 쓰고 싶지 않은 사람의 편의도 고려했다.

이를 위해, Automake는 세가지 단계의 엄격성(strictness)를 지원한다—엄격함은 표준을 따르는지 아닌지 얼마나 강력하게 검사해야 하는지를 나타낸다.

사용할 수 있는 엄격성 단계는:

foreign

Automake는 제대로 동작을 하는데 꼭 필요한 것만 검사한다. 예를 들어, GNU 표준에서는 ‘NEWS’ 파일이 있어야 한다고 정해져 있지만, 이 모드에서는 ‘NEWS’ 파일이 필요없다. ‘foreign’이라는 이름은 Automake가 GNU 프로그램에 사용되기 위한 도구라는 사실에서부터 나왔다 지어졌다; 이 느슨한 규칙은 기본 동작 모드가 아니다.

gnu

Automake는—가능하면 많이—패키지가 GNU 표준을 따르는지 검사한다. 이것이 기본 동작 모드이다.

gnits

Automake는 아직-작성되지-않은 Gnits 표준을 따르는지 검사한다. Gnits는 GNU 표준에 기초하지만, 훨씬 더 자세하다. GNITS 표준을 만드는 데 참여하는 사람이 아니라면, Gnits 표준이 실제로 발표될 때까지 이 옵션을 사용하지 않기를 권한다.

엄격성 단계에 정확히 무엇이 포함되었는 지에 대한 정확한 정보는 See section –gnu와 –gnits의 효과에 있다.


[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.4 일관적 명명법

Automake 매크로(여기서부터 변수라고 부르겠다)는 보통 일관적인 명명법을 따른다. 이 명명법을 통해 어떻게 프로그램(그리고 그외 다른 것으로부터 자동으로 만들어지는 오브젝트들)이 빌드되고, 어떻게 설치되는지 Automake가 더 쉽게 알 수 있다. 또 이 명명법을 이용해 configure 시에 무엇을 빌드해야 할지 결정하는 것까지도 지원한다.

make를 실행할때, 어느 오브젝트를 빌드해야 할지 알아보는 데 쓰이는 변수가 몇 개 있다. 이 변수를 주요(primary) 변수라고 한다. 그 한가지 예로, 주요 변수인 PROGRAMS의 값은 컴파일되고 링크될 프로그램들의 리스트를 담고 있다.

또 다른 종류의 변수들은 만들어진 오브젝트를 어디에 설치해야 할지 결정한다. 이 변수들의 이름은 주요 변수의 이름을 본따서 이름지어 졌지만, 어느 표준 디렉토리를 설치 디렉토리로 사용할지 나타내는 접두어를 갖고 있다. 이 표준 디렉토리들의 이름은 GNU 표준에 주어져 있다 (see Directory Variables in The GNU Coding Standards). automake는 이 리스트를 확장해서 pkglibdir, pkgincludedir, 그리고 pkgdatadir를 추가했다; 이 변수들은 ‘pkg’가 없는 버전과 같지만, 디렉토리에 ‘@PACKAGE@’가 뒤에 덧붙여진 이름이다. 예를 들어, pkglibdir$(datadir)/@PACKAGE@로 정의된다.

각 주요 변수에 대하여, 주요 변수의 이름 앞에 ‘EXTRA_’를 붙인 변수가 한가지씩 추가되어 있다. 이 변수는 configure가 어떻게 결정하냐에 따라서 만들어 질 수도 있고 만들어 지지 않을 수도 있는 오브젝트를 나열하는 데 쓰인다. 어떤 경우에도 제대로 동작하는 ‘Makefile.in’을 만드려면, 만들어야 할 오브젝트의 전체 리스트를 Automake가 고정적으로 알고 있어야 하기 때문에 이 변수가 필요하다.

그 한가지로, cpioconfigure 실행 시에 어떤 프로그램을 빌드할지 결정한다. 어떤 프로그램은 bindir에 설치할 것이고, 어떤 프로그램은 sbindir에 설치할 것이다:

EXTRA_PROGRAMS = mt rmt
bin_PROGRAMS = cpio pax
sbin_PROGRAMS = @PROGRAMS@

접두어가 없이 주요 변수를 정의하는 것은 (PROGRAMS처럼) 잘못된 명명법이다.

공통적으로 들어 있는 ‘dir’ 접미어는 변수 이름을 만드는 데 없앤다. 즉, ‘bin_PROGRAMS’으로 쓰지 ‘bindir_PROGRAMS’라고 쓰지는 않는다.

각각의 디렉토리에 설치될 수 있는 오브젝트의 종류는 제한되어 있다. 만약 해당 디렉토리에 설치할 수 없는 오브젝트를 설치하려는 시도를 하면 Automake는 오류로 처리한다. 또 Automake는 디렉토리 이름을 잘못 쓴 경우를 찾아낼 것이다.

때때로 표준 디렉토리들—Automake에 의해 변형된 디렉토리 이름이라도—로는 충분하지 않은 경우가 있다. 특히 더 명확하게 하기 위해, 오브젝트를 어떤 미리 정의된 디렉토리의 서브디렉토리에 설치하는 것이 유용할 때도 있다. 이것 때문에, Automake는 설치 가능한 디렉토리를 확장할 수 있게 해준다. 임의의 접두어(예로 ‘zar’)도 같은 이름에 ‘dir’가 뒤에 붙여진 변수(예로 ‘zardir’)를 정의하면 사용할 수 있다.

예를 들어, Automake가 HTML을 지원할 때까지 HTML 문서를 설치할 때 다음과 같이 사용할 수 있다.

htmldir = $(prefix)/html
html_DATA = automake.html

특별 접두어 ‘noinst’는 주어진 object들이 전혀 설치되지 말아야 한다는 뜻이다.

특별 접두어 ‘check’는 주어진 object들이 make check 명령이 실행될 때까지는 만들어지지 말아야 한다는 뜻이다.

사용 가능한 가능한 주요 변수의 이름은 ‘PROGRAMS’, ‘LIBRARIES’, ‘LISP’, ‘SCRIPTS’, ‘DATA’, ‘HEADERS’, ‘MANS’, 그리고 ‘TEXINFOS’이다.


[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.5 파생된 변수의 명명법

때때로 사용자가 쓰는 또 다른 문자열에서 Makefile 변수의 이름이 결정되는 경우가 있다. 그 한가지 예로, 프로그램의 이름은 Makefile의 매크로 이름으로 쓰여진다. Automake는 이 문자열을 Makefile 변수규칙에 맞게 변형해서, Makefile 변수의 명명법대로 이름을 지을 필요가 없도록 해준다. 글자, 숫자, 그리고 밑줄을 제외한 이름의 모든 문자는 매크로를 만들때 밑줄로 바뀐다. 예를 들어, 만약 프로그램의 이름이 sniff-glue라면, 여기에서 나오는 변수의 이름은 sniff_glue_SOURCES이지 sniff-glue_SOURCES가 아니다.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated on April 12, 2025 using texi2html 5.0.