이 장에서는 GNU 프로그램의 메이크파일을 작성할 경우의 습관들을 설명한다.
모든 메이크파일은 다음과 같은 줄이 들어 있다:
SHELL = /bin/sh
SHELL 변수를 환경변수에서부터 내려받는 시스템에서 발생할 지
모르는 문제를 피하기 위해서 위와 같이 한다. (GNU make에는 이
문제가 없다.)
.SUFFIXES: .SUFFIXES: .c .o
첫번째 줄은 점미어 리스트를 지우고, 두번째 줄에는 이 메이크파일에서 암묵적인 룰에 사용될 수 있는 모든 접미어가 쓰여 있다.
`.'이 명령어 실행 경로 안에 들어 있다고 가정하지 말라. 메이크를 실행할 때 패키지의 일부인 프로그램을 실행해야 할 경우, 프로그램이 메이크 도중에 만들어 질 때는 `./'를 사용하고 프로그램이 소스 코드에서 변하지 않는 부분이면 `$(srcdir)/'를 사용한다. 이렇게 앞에 붙이지 않으면, 현재 찾기 경로가 사용된다.
사용자는 `configure'에 `--srcdir' 옵션을 사용해서 별도의 디렉토리에서 빌드할 수도 있으므로, `./'(빌드 디렉토리(build directory))와 `$(srcdir)/'(소스 디렉토리(source directory)의 차이는 중요하다.
foo.1 : foo.man sedscript
sed -e sedscript foo.man > foo.1
위의 룰은 빌드 디렉토리가 소스 디렉토리가 아닐 경우 실패할 것이다. `foo.man'과 `sedscript'는 소스 디렉토리에 없기 때문이다.
GNU make를 사용할 때, `VPATH'에 따라 소스 파일을 찾는 건
의존성 파일이 한개만 있을 경우에 동작한다. make의 자동 변수
`$<'는 어디에 있든 간에 소스 파일을 나타낼 것이기 때문이다. (많은
make의 버전들은 암묵적인 룰에서만 `$<'의 값을 지정한다.)
다음과 같은 메이크파일은
foo.o : bar.c
$(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o
다음과 같이 쓰여져야 한다:
foo.o : bar.c
$(CC) -I. -I$(srcdir) $(CFLAGS) -c $< -o $@
`VPATH'가 올바르게 동작하도록 하려면 위와 같이 써야 한다. 타겟이 여러개의 의존성을 가진 경우, 명시적으로 `$(srcdir)'를 쓰는 것이 룰을 잘 동작하게 만드는 가장 쉬운 방법이다. 예를 들어, 위의 `foo.1'에 대한 타겟은 다음과 같이 쓰는 것이 가장 좋다:
foo.1 : foo.man sedscript
sed -e $(srcdir)/sedscript $(srcdir)/foo.man > $@
GNU 배포판은 보통 소스 파일이 아닌 파일도 들어 있다---예를 들어, Info 파일, Autoconf, Autoconf, Bison, 혹은, Flex의 출력 파일과 같은 파일도 들어 있다. 이 파일들은 보통 소스 디렉토리에 나타나기 때문에, 이 파일들은 언제나 빌드 디렉토리가 아닌 소스 디렉토리에 있어야 한다. 그러므로 메이크파일 룰은 이 파일들을 업데이트할 때 업데이트된 파일들을 소스 디렉토리에 놓아야 한다.
하지만, 파일이 배포판에 없을 경우, 메이크파일은 이 파일을 소스 디렉토리에 넣어서는 안 된다. 보통 상황에서 프로그램을 빌드하는 일은 절대 소스 디렉토리를 수정하지 않기 때문이다.
최소한 빌드와 설치 타겟은 (그리고 이 타겟에서 갈라져 나오는 타겟들)
동시에 실행되는 make에서 제대로 동작하도록 작성하라.
메이크파일의 명령어들은 (그리고 configure와 같은 모든 셸
스크립트들은) sh에서 실행되도록 (csh이 아니라) 작성하라.
ksh이나 bash의 특수 기능들을 절대 사용하리 말라.
configure 스크립트와 빌드와 설치용 메이크파일 룰들은 다음
명령어들을 제외하고는 직접 사용하면 안 된다.
cat cmp cp diff echo egrep expr false grep install-info ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true
압축 프로그램 gzip은 dist 룰에서 사용될 수 있다.
이 프로그램에서 일반적으로 지원되는 옵션들만 사용하라. 예를 들어, `make -p'는 편리할 지 모르나, 대부분의 시스템이 지원하지 않으므로 사용하면 안 된다.
메이크파일에서 심볼릭 링크를 만들지 않는 것이 좋다. 몇몇 시스템에서는 심볼릭 링크를 지원하지 않는다.
빌드와 설치용 메이크파일 룰들은 컴파일로와 관련 도구들도 쓸 수 있지만,
make 변수를 통해 사용해서 사용자가 다른 도구로 바꿀 수 있도록
한다. 여기서 말하는 프로그램은 다음과 같은 것들이다:
ar bison cc flex install ld ldconfig lex make makeinfo ranlib texi2dvi yacc
위의 프로그램을 실행할 때 다음 make 변수를 사용한다:
$(AR) $(BISON) $(CC) $(FLEX) $(INSTALL) $(LD) $(LDCONFIG) $(LEX) $(MAKE) $(MAKEINFO) $(RANLIB) $(TEXI2DVI) $(YACC)
ranlib나 ldconfig를 사용할 경우, 시스템에 그 프로그램이
없을 때 문제가 생기지 않도록 해야 ㅎ나다. 명령에서 애러를 무시하도록
만들고, 명령어 앞에 사용자에게 이 명령이 실패했다고 해서 문제가 아니라는
것을 알려주는 메세지를 표시한다. (Autoconf의 `AC_PROG_RANLIB'
매크로가 이 일에 쓸모가 있다.)
심볼릭 링크를 사용한다면, 심볼릭 링크가 없는 시스템을 위해 대체 장치를 만들어야 한다.
그 외에 Make 변수를 통해 사용될 수 있는 유틸리티는:
chgrp chmod chown mknod
해당 유틸리티가 존재한다는 걸 알고 있는 특정 시스템을 위한 경우라면 메이크파일 내에 (혹은 스크립트에) 그 외의 유틸리티를 사용해도 좋다.
메이크파일에서는 어떤 명령어, 옵션 등을 무시하고 다시 정의할 수 있도록 변수를 사용해야 한다.
특히, 대부분의 유틸리티 프로그래을 변수를 통해 사용해야 한다. 즉,
Bison을 사용한다면, 기본값이 `BISON = bison'과 같이 맞춰져 있는
BISON이라는 변수를 사용하고, Bison을 사용하는 모든 곳에서
$(BISON)을 쓴다.
ln, rm, mv, 등과 같은 파일 관리 유틸리티들은,
사용자가 다른 프로그램으로 대체할 필요가 전혀 없으므로 이렇게
변수를 사용할 필요가 없다.
각 프로그램의 이름을 담는 변수들은 그 프로그램에 옵션으로 주어지는 옵션
변수가 따라 와야 한다. 옵션 변수의 이름은 프로그램 이름 변수의 이름
다음에 `FLAGS'를 추가한다---예를 들어, BISONFLAGS와 같이
한다. (C 컴파일러의 CFLAGS, yacc의 YFLAGS, lex의
LFLAGS는 이 규칙의 예외이지만, 이 변수들은 표준이기 때문에 이
예외를 계속 유지한다.) 전처리기를 실행하는 모든 컴파일 명령에서는
CPPFLAGS를 쓰라. 그리고, ld를 직접 사용하는 경우는
물론이고 링크를 하는 모든 컴파일 명령에서는 LDFLAGS를 사용하라.
정상적으로 컴파일하기 위해서 꼭 필요한 C 컴파일러 옵션이
있으면, 그 옵션은 CFLAGS에 포함하지 않는다. 사용자는 직접
CFLAGS의 값을 지정할 수 있기를 기대한다. 대신에,
CFLAGS와는 별도로 필요한 C 컴파일러 옵션들을 정리해서 넘겨준다.
그 옵션은 직접 컴파일 명령에 추가하거나, 다음과 같이 암묵적인 룰에서
정의한다:
CFLAGS = -g
ALL_CFLAGS = -I. $(CFLAGS)
.c.o:
$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
`-g' 옵션은 정상적으로 컴파일하는 데 필요한 옵션이 아니므로,
CFLAGS에 포함한다. 이건 추천되기만 하는 기본 사항으로 생각하면
된다. 이 패키지가 기본으로 GCC로 컴파일해야 하도록 만들어진 경우라면,
CFLAGS의 값으로 `-O'도 포함할 수 있을 것이다.
컴파일 명령에서 CFLAGS를 컴파일러 옵션이 들어 있는 그 외 변수
뒤에, 맨 마지막에 놓아서, 사용자가 CFLAGS로 다른 변수들을
무시하고 재정의할 수 있도록 만든다.
CFLAGS는 컴파일하는 부분과 링크하는 부분 모두, C 컴파일러를
실행하는 모든 곳에서 사용되야 한다.
모든 메이크파일은 INSTALL 변수를 정의해야 한다. 이 변수는 파일을
시스템에 설치하는 기본 명령어이다.
모든 메이크파일은 INSTALL_PROGRAM과 INSTALL_DATA 변수를
정의해야 한다. (이 변수들의 기본값은 $(INSTALL)이다.) 그
다음에 이 변수들을 사용해서, 각각 실행 파일과 실행할 수 없는 파일들을
설치하는 명령어에서 사용해야 한다. 다음과 같이 이 변수들을 사용한다:
$(INSTALL_PROGRAM) foo $(bindir)/foo $(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a
설치 명령의 두번째 인수로, 항상 디렉토리 이름이 아닌 파일 이름을 사용한다. 설치할 각 파일에 대해서 별도의 명령어를 사용한다.
설치 디렉토리는 언제나 변수로 이름지어서, 표준이 아닌 장소에 설치하기 쉽도록 해야 한다. 이 변수의 표준 이름들은 아래에 설명되어 있다. 이 변수들은 표준 파일시스템 배치에 기초하고 있다; SVR4, 4.4BSD, Linux, Ultrix v4, 그 외의 현대적인 운영체제들에서 여기서부터 나온 파일시스템을 쓰고 있다.
다음 두개의 변수는 설치할 루트 디렉토리를 결정한다. 그 외의 모든 설치 디렉토리는 이 두 디렉토리의 서브 디렉토리여야 하고, 이 두 디렉토리로 직접 설치되는 파일은 없어야 한다.
prefix의 기본 값은 `/usr/local' 이어야 한다. 완전한 GNU
시스템을 만드는 경우, 이 접두어는 비어 있거나 `/usr'가 `/'의
심볼릭 링크일 것이다. (Autoconf를 사용한다면, 이 값을
`@prefix@'로 한다.)
exec_prefix의 기본값은 $(prefix)이어야 한다. (Autoconf를
사용한다면, 이 값을 `@exec_prefix@'로 한다.)
일반적으로, $(exec_prefix)는 (실행 파일이나 서브루틴 라이브러리와
같은) 기계-의존적인 파일들을 담고 있는 디렉토리에서 사용된다. 반면
$(prefix)는 그 외의 디렉토리에서 사용된다.
실행 가능한 프로그램은 다음 디렉토리중의 하나에 설치된다.
프로그램 실행 중에 사용하는 데이타 파일은 크게 두가지 방법으로 구분할 수 있다.
이렇게 여섯 가지의 가능성이 생긴다. 하지만, 오브젝트 파일과 라이브러리를 제외한 아키텍쳐에 의존하는 파일들은 사용하지 말라고 권하고 싶다. 그 외 데이타 파일들은 아키텍쳐에 상관없이 만드는 편이 훨씬 깨긋하고, 이건 대부분 어려운 작업이 아니다.
그러므로, 다음이 메이크파일에서 디렉토리를 지정하는 변수이다:
libdir의 값은 보통
`/usr/local/lib'이지만, `$(exec_prefix)/lib'라고 쓴다.
(Autoconf를 사용한다면, `@libdir@'라고 쓴다.)
lispdir='${datadir}/emacs/site-lisp'
AC_SUBST(lispdir)
includedir이고, 또
하나는 oldincludedir이다.
oldincludedir의 값이 없는지 있는지 검사해야
한다. 그 값이 없다면, 이 값을 사용하지 않는다; 헤더 파일을 여기에
설치하지 말아야 한다.
패키지는 같은 패키지에서 나온 헤더 파일이 아닌 한 이 디렉토리에 이미
존재하는 헤더 파일을 덮어 씌우면 안 된다. 즉, Foo라는 패키지가
`foo.h'라는 헤더 파일을 사용한다면, (1) `foo.h'가
oldincludedir 디렉토리에 없거나 (2) 이 디렉토리에 있는
`foo.h'가 Foo 패키지에서 나온 것일 때 이 헤더 파일을
oldincludedir에 설치한다.
`foo.h'가 Foo 패키지에서 나온 파일인지 아닌지 알려면, 그 파일을
판별할 수 있는 문자열을 `foo.h'에 (주석으로) 넣고, 그 문자열을
grep한다.
유닉스 스타일의 맨 페이지는 다음중 하나에 설치된다:
마지막으로, 다음 변수 값을 결정해야 한다:
configure 셸 스크립트가 집어 넣는다. (Autoconf를 사용한다면
`srcdir = @srcdir@'를 사용한다.)
예를 들어:
# 설치 디렉토리의 공통적인 접두어 # 주의: 이 디렉토리는 설치를 시작할 때 존재해야 한다. prefix = /usr/local exec_prefix = $(prefix) # `gcc' 명령어 실행 파일을 넣을 장소 bindir = $(exec_prefix)/bin # 컴파일러가 사용할 디렉토리를 넣을 장소 libexecdir = $(exec_prefix)/libexec # Info 파일을 넣을 장소 infodir = $(prefix)/info
프로그램이 아주 많은 수의 파일들을 표준 사용자 지정 디렉토리중의 하나에
설치한다면, 그 프로그램을 위해 특별히 만들어진 서브 디렉토리 안에 모아
놓는 것이 좋다. 그렇게 하려면 이러한 서브 디렉토리를 만들도록
install 룰에 써 넣어야 한다.
사용자가 위에 열거된 변수의 어떤 값중에 서브디렉토리 이름을 포함할 것이라고 기대하지 말라. 설치 디렉토리의 변수 이름을 통일된 모양으로 가지고 있는다는 생각은, 사용자가 여러가지 GNU 패키지들에 대해서 정확히 같은 값을 지정하도록 하는 것이다. 이 생각을 쓸모있게 하기 위해, 모든 패키지는 사용자가 지정하는 디렉토리에 맞게 동작하도록 설계되어야 한다.
모든 GNU 프로그램은 Makefile에 다음 타겟을 가지고 있어야 한다:
install-strip 타겟으로 디버깅 심볼을 없앨 수 있다.
가능하다면, `make all'이 끝났다는 가정하에 프로그램이 빌드되는
디렉토리에 있는 어떤 파일도 수정하지 않도록 install 타겟의 룰을
만든다. 이렇게 하면 한 사용자 이름으로 프로그램을 빌드한 다음 다른
사용자 이름으로 설치할 때 편리하다.
명령어들은 파일이 설치될 디렉토리가 없다면, 그 디렉토리들을 모두
만들어야 한다. 이 규칙은 필요한 모든 서브디렉토리는 물론,
prefix와 exec_prefix 변수의 값으로 지정된 디렉토리까지
포함한다. 한가지 방법은 아래에 설명할 installdirs 타겟을
사용하는 것이다.
맨 페이지를 설치하는 모든 명령 앞에 `-'를 사용해서, make에서
애러를 무시하도록 한다. 유닉스 맨 페이지 문서 시스템이 없는 시스템도
있기 때문이다.
Info 파일을 설치하는 방법은 그 Info 파일을 `$(infodir)'에
$(INSTALL_DATA)로 (see section 명령어를 지정하는 변수)복사하고,
install-info 프로그램이 있다면 그걸 실행한다.
install-info는 Info `dir' 파일을 편집해서 주어진 Info 파일에
대한 메뉴 항목을 추가하거나 업데이트하는 것이다; 이 프로그램은 Texinfo
패키지의 일부이다. 다음은 Info 파일을 설치하는 간단한 룰이다:N
$(infodir)/foo.info: foo.info
$(POST_INSTALL)
# srcdir에 있는 파일보다 .에 있는 info 파일이 새로운 파일일 수 있다
-if test -f foo.info; then d=.; \
else d=$(srcdir); fi; \
$(INSTALL_DATA) $$d/foo.info $@; \
# install-info가 존재할 경우에만 실행한다.
# `-'를 앞에 붙이는 대신에 `if'를 사용해서
# install-info에서 나오는 애러를 알 수 있도록 한다.
# 알 수 없는 명령어를 만나면 정상적으로 종료하지 않는
# 셸이 있기 때문에 `$(SHELL) -c'를 사용한다.
if $(SHELL) -c 'install-info --version' \
>/dev/null 2>&1; then \
install-info --dir-file=$(infodir)/dir \
$(infodir)/foo.info; \
else true; fi
install 타겟을 작성할 때, 모든 명령어가 다음 세가지중 하나로
분류될 수 있도록 해야 한다: 보통, 설치-전 명령, 그리고
설치-후 명령이다. See section 설치 명령어 구분.
install과 같지만, 실행 파일을 설치할 때 디버깅 심볼을 없앤다.
대부분의 경우에, 이 타겟의 정의는 매우 간단하다:
install-strip:
$(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
install
프로그램에 버그가 없다는 걸 확신하지 않는 한, 실행 파일의 디버깅 심볼을
없애지 않기를 권한다. 하지만, 버그가 있을 경우에도 디버깅 심볼을 없앤
실행 파일을 설치하고, 디버깅 심볼이 있는 실행 파일을 다른 곳에 저장해
두는 것도 조리에 맞다.
distclean에서 지워지는 모든 것을
포함하고, 여기에 Bison이 만드는 C 소스 파일, tags 테이블, Info 파일 등을
더 지운다.
"거의 모든 것들을"이라고 말한 이유는 `make maintainer-clean'은
`configure'의 경우는 메이크파일의 룰에서 만들어 질 수 있더라도
지우지 않기 때문이다. 일반적으로 말해, `make maintainer-clean'은
`configure'를 실행하고, 프로그램을 빌드하기 위해 필요한 어떤 파일도
지우지 않는다. 이것은 유일한 예외이다; maintainer-clean은 다시
빌드될 수 있는 그 외의 모든 것들을 지운다.
`maintainer-clean' 타겟은 보통의 사용자가 아니라, 패키지의
메인테이너가 사용하기 위해 만들어졌다. `make maintainer-clean'이
지우는 파일들을 다시 만들기 위해서는 특별한 도구가 필요할 수도 있다. 이
파일들은 보통 배포본 안에 포함되기 때문에, 이 파일을 다시 만들기 쉽도록
하지 않는다. 다시 전체 배포본의 압축을 풀어야 할 일이 생기더라도
원망하지 말기 바란다.
사용자가 이 사실을 알도록 하려면, maintainer-clean 타겟의
명령어들은 다음 두 줄로 시작해야 한다:
@echo 'This command is intended for maintainers to use; it' @echo 'deletes files that may need special tools to rebuild.'
info: foo.info
foo.info: foo.texi chap1.texi chap2.texi
$(MAKEINFO) $(srcdir)/foo.texi
메이크파일 내에 MAKEINFO 변수를 정의해야 한다. 이 룰은
Texinfo 배포본의 일부인 makeinfo 프로그램을 실행한다.
보통 GNU 배포본은 Info 파일이 들어 있고, 그 말은 Info 파일이 소스
디렉토리에 들어 있다는 뜻이다. 즉, Info 파일의 메이크 룰은 소스
디렉토리 안의 Info 파일을 갱신해야 한다. 사용자가 패키지를 빌드할 때
보통 Info 파일은 이미 갱신되어 있는 상태일 것이므로, Info 파일은
갱신하지 않는다.
dvi: foo.dvi
foo.dvi: foo.texi chap1.texi chap2.texi
$(TEXI2DVI) $(srcdir)/foo.texi
메이크파일에 TEXI2DVI 변수를 정의해야 한다. 이 룰은 Texinfo
배포본의 일부인 texi2dvi 프로그램을 실행해야
한다.(3) 또 다른 방법은,
의존성만 작성하고, GNU make에서 명령어를 제공하도록 하는 것이다.
ln이나 cp로 집어 넣고, 그 서브 디렉토리에
tar를 실행하는 것이다.
tar 파일을 gzip으로 압축한다. 예를 들어, GCC 버전 1.40의 실제
배포 파일은 `gcc-1.40.tar.gz'이다.
dist 타겟은 배포본에 들어있는 모든 소스가 아닌 파일들에 의존해야
한다. 이렇게 하면 완전히 업데이트된 상태라는 걸 보장한다.
See section `발표하기' in GNU 코딩 표준.
다음 타겟은 이런 타겟이 필요한 프로그램의 경우에 사용하기를 권하는, 관습적인 타겟 이름이다.
installcheck
installdirs
# 모든 설치 디렉토리에 대해서 (예: $(bindir)) 필요하면
# 디렉토리를 만들어서 디렉토리가 존재하도록 만든다.
installdirs: mkinstalldirs
$(srcdir)/mkinstalldirs $(bindir) $(datadir) \
$(libdir) $(infodir) \
$(mandir)
이 룰은 컴파일이 수행되는 디렉토리를 수정하면 안 된다. 이 룰은 설치
디렉토리들을 만드는 것 이외에 아무 것도 하면 안 된다.
install 타겟을 작성할 때, 모든 명령어를 세가지 중의 하나로
분류해야 한다; 보통, 설치-전 명령, 그리고 설치-후 명령이다.
보통 명령어는 파일들을 적당한 위치로 옮기고, 그 파일의 모드를 결정한다. 이 명령어는 해당 패키지에 속해 있는 파일을 제외한 어떤 파일들도 고치면 안 된다.
설치-전 명령어와 설치-후 명령어는 그 외의 파일들도 고칠 수 있다: 특히, 이 명령어들은 전체 설정 파일이나 데이타 베이스를 수정할 수 있다.
설치-전 명령어는 대부분 보통 명령어 전에 실행되고, 설치-후 명령어는 보통 명령어 뒤에 실행된다.
설치-후 명령어를 사용하는 가장 전형적인 예는 install-info를
실행하는 일이다. 이 작업은 보통 명령어로 할 수 없다.
install-info는 설치할 패키지에서 나오는 파일이 아닌 (Info
디렉토리의) 파일을 바꾸기 때문이다. install-info는 패키지의 Info
파일들을 복사하는 보통 명령어 다음에 실행해야 하기 때문에 설치-후
명령어이다.
대부분의 프로그램은 설치-전 명령어가 필요없지만, 우리는 이런 명령어가 필요한 경우를 위해 그러한 명령어에 대해 써 놓았다.
install 룰의 명령어를 이 세가지로 분류하려면, 분류
줄(category line)을 명령어 사이에 첨가한다. 분류 줄은 다음에
나올 명령어의 분류를 지정한다.
분류 줄은 탭과 특별한 메이크 변수에 대한 참조, 그리고 그 뒤에 옵션으로 주석이 들어간다. 각각의 명령어 분류에 따라 사용할 수 있는 세개의 변수가 있다; 변수의 이름이 각 명령어 분류를 지정한다. 분류 줄은 보통의 경우 아무일도 하지 않는데, 이 세 개의 메이크 변수는 보통 정의되지 않은 상태이기 때문이다 (그리고 메이크 파일에서 정의하면 안 된다).
다음은 가능한 세개의 분류 줄로, 각각은 무슨 뜻인지 설명하는 주석이 붙어 있다:
$(PRE_INSTALL) # 설치-전 명령어가 뒤에 온다.
$(POST_INSTALL) # 설치-후 명령어가 뒤에 온다.
$(NORMAL_INSTALL) # 보통 명령어가 뒤에 온다.
install 룰의 앞 부분에 분류 줄을 사용하지 않는다면, 모든 명령어는
분류 줄이 나올 때까지 보통으로 분류된다. 분류 줄을 전혀 사용하지
않는다면 모든 명령어는 보통으로 분류된다.
다음은 uninstall을 위한 분류 줄이다:
$(PRE_UNINSTALL) # 설치제거-전 명령어가 다음에 온다.
$(POST_UNINSTALL) # 설치제거-후 명령어가 다음에 온다.
$(NORMAL_UNINSTALL) # 보통 명령어가 다음에 온다.
흔한 예로, 설치제거-전 명령어는 Info 디렉토리의 항목을 제거하는 데 사용될 것이다.
insatll이나 uninstall 타겟이 설치의 서브루틴으로 작용하는
의존성이 들어 있다면, 각각의 의존성의 명령어를 분류 줄로 시작해야
하고, 주요 타겟의 명령어도 분류 줄로 시작한다. 이렇게 하면, 모든
명령어가 실제 어떤 의존성이 실행되었는지에 관계없이 올바른 분류에
들어가게 된다.
설치 전 명령어와 설치 후 명령어는 다음을 제외하고는 어떤 프로그램도 사용하면 안 된다:
[ basename bash cat chgrp chmod chown cmp cp dd diff echo egrep expand expr false fgrep find getopt grep gunzip gzip hostname install install-info kill ldconfig ln ls md5sum mkdir mkfifo mknod mv printenv pwd rm rmdir sed sort tee test touch true uname xargs yes
이런 식으로 명령어들을 구분하는 이유는 이진 패키지를 만들 경우를 위해서이다. 보통 한 바이너리 패키지는 설치할 실행 파일 및 그 외의 파일들을 포함하고 있고, 또 그 파일들을 설치하는 고유한 방법이 들어 있다---즉 보통의 설치 명령을 실행할 필요가 없다. 하지만 이진 패키지를 설치하는 일은 설치-전 명령어와 설치-후 명령어를 실행해야 할 필요가 있다.
이진 패키지를 만드는 프로그램은 설치-전 명령어와 설치-후 명령어들을 뽑아내는 식으로 동작한다. 다음은 설치-전 명령어를 뽑아내는 한가지 방법이다.
make -n install -o all \
PRE_INSTALL=pre-install \
POST_INSTALL=post-install \
NORMAL_INSTALL=normal-install \
| gawk -f pre-install.awk
이 때, `pre-install.awk'는 다음과 같다:
$0 ~ /^\t[ \t]*(normal_install|post_install)[ \t]*$/ {on = 0}
on {print $0}
$0 ~ /^\t[ \t]*pre_install[ \t]*$/ {on = 1}
설치-전 명령어들이 들어있는 파일은 이진 패키지를 설치할 때 셸 스크립트로 실행된다.
Go to the first, previous, next, last section, table of contents.