Trans:EbuildHowTo
Ebuild HOWTO
포티지 트리
개요
포티지 트리는 보통 /usr/portage 디렉터리 에서 찾을 수 있으며, 각각의 패키지 디렉터리가 딸려오는 카테고리 디렉터리 들이 포함되어 계층적 구조로 이루어져 있습니다. 예를 들어, /usr/portage/sys-apps/util-linux 디렉터리에서 util-linux-2.11y.ebuild 파일을 찾을 수 있습니다. 이 디렉터리에서는 또한 util-linux-2.11y.ebuild 파일과 함께 다른 버전의 util-linux에 대한 ebuild가 있을 것입니다. 이는 포티지 오버레이를 설치하지 않는 한, (버전과 상관 없이) 제각각의 패키지에 대한 모든 ebuild 가 /usr/portage에서 mycat/mypkg를 공유하기 때문입니다.
CVS에서 포티지 트리 체크아웃 하기
CVS 시스템에 익숙하지 않다면 CVS 따라하기를 보시기 바랍니다. 포티지 트리는 젠투 리눅스 트리의 gentoo-x86 모듈에서 찾을 수 있습니다. (대략 350 메가 바이트 정도 되는) 모듈을 체크아웃 하려면 먼저 안내서에 따라 CVS를 설정한 다음에 gentoo-x86 모듈을 체크아웃 합니다.
포티지 트리에 놓을 (놓지 말아야 할) 것
새 ebuild를 작성하기 전에 패키지에 대한 ebuild가 이미 작성되었지만 아직 포티지 트리에 추가가 되었는지 안되었는지를 bugs.gentoo.org에서 확인합니다. bugs.gentoo.org로 이동하여 쿼리를 선택하고 Advanced Search를 선택한 다음, pruduct에는 Gentoo Linux를, component에는 ebuilds를 선택합니다. 검색 필드에는 ebuild의 이름을 입력하고 status에서는 NEW, ASSIGNED, REOPENED 그리고 RESOLVED (RESOLVED가 중요합니다) 를 선택한 다음 쿼리를 보냅니다. 게으른 분들을 위해 링크를 준비했습니다.
일반적으로, 포티지 트리는 패치는 예제 설정 파일들과 같은 상대적으로 작은 부록 >파일들과 함께 .ebuild 파일을 저장하는 용도로만 사용하는 것이 좋습니다. 이런 파일 들은 mycat/mypkg 디렉터리가 포화되지 않도록 /usr/portage/mycat/mypkg/files 디렉>터리에 저장됩니다. 이 규칙의 예외는 젠투 미러에 위치하여 수많은 양의 대역폭과 하드디스크 용량을 낭비하지 않도록 해야 할 큰 패치 파일 ( 20KB를 넘는 패치를 위해 권장합니다 ) 에 적용됩니다. 또한 (ASCII가 아닌) 바이너리 파일을 포티지 CVS트리에 넣지 말아야 합니다. 만약 예를 들어 다른 CVS 트리에서 이렇게 할 필요가 있다면, 이유 여하를 막론하고 작은 PNG 그림 파일을 추가할 필요가 있다면 다음과 같이 -kb 옵션을 사용하여 CVS에 추가하도록 합니다.
| 코드 예제 1-1: CVS에 바이너리 파일 추가하기 |
| # cvs add -kb myphoto.png |
-kb 옵션은 CVS에게 myphoto.png가 바이너리 파일이고 특별하기 다루어져야 한다는 것을 알려줍니다. 예를 들어 이 파일에 대해 제각기 다른 두개의 버전간의 차이를 명백한 이유로 병합하도록 하지 못하게 하여야 할 것입니다. 또한 변경사항의 병합에 대해 말하자면, 포티지에 추가한 어떤 패치도 일반적으로 압축되지 않게 하는것이 좋습니다. 이렇게 하면 CVS가 변경사항을 병합하게 하고 개발자에게 충돌 내용을 정확하게 알려줍니다.
커밋할 패키지는 안정버전으로 커밋되었을때 최종 사용자를 위해 반드시 제대로 준비가 되어야 한다는 것을 잊지 마셔야 합니다. 대부분의 시스템과 여러분의 패키지를 사용할 사용자들을 만족시킬 기본 설정이 갖춰졌는지 확인 바랍니다. 만약 패키지가 깨>졌고, 어떻게 동작하게 할 수 있을지 잘 모르겠다면, 패키지 자체버전을 완성한 다른 배포본을 확인합니다. 예제를 보기위해 맨드리바 나 데비안 혹은 페도라를 확인해 볼 수 있습니다.
CVS 커밋 정책
- 커밋 하기 전에 repoman scan을 항상 실행합니다.
- 커밋 하기 전에 repoman full을 실행해 주시기 바랍니다.
- 커밋 하기 전에 emerge --pretend mypkg를 실행하여 package.mask가 완전한지 시험하고 어떤 충돌 사항이 포함되지 않도록 점검합니다.
- 커밋 하기 전에 ChangeLog를 항상 갱신합니다.
- package.mask를 커밋하는 동안 충돌이 발생하는 경우, 갱신된 패키지를 올리기 전에 갱신된 package.mask를 항상 커밋합니다.
- 항상 요소별로 커밋합니다. 새로운 라이선스로 패키지를 커밋하거나 패키지가 가려졌을 때 최신 package.mask나 혹은 라이선스를 먼저 커밋한 다음 사용자의 설치가 깨지는 것을 막기 위해 ebuild, ChangeLog, 패치들 그리고 metadata.xml을 한꺼번에 커밋합니다.
files 디렉터리
앞서 참고한 바와 같이 각각의 패키지에 포함된 하위 디렉터리로서 files/ 디렉터리가 있습니다. 여러분의 패키지에 있는 어떤 패치나 설정 파일 혹은 기타 보조 파일들이 이 디렉터리에 추가될 필요가 있을 것이며, 20KB 그 이상을 넘는 어떤 파일의 경우는 우리 사용자들이 다운 받을 (불필요한) 많은 파일들을 줄이기 위해 미러에 넣는 것이 좋습니다. mypkg-1.0-gentoo.diff나 혹은 좀 더 간단하게 1.0-gentoo.diff와 같이 패키지를 빌드하기 위해 버전과 관련된 이름으로 여러분 자신이 만든 패치에 이름을 붙이고 싶을지도 모릅니다. 또 참고하셔야 할 것은 젠투 익스텐션은 사용자들에게 이 패치가 메일링 리스트나 다른 어떤 곳에서 가져온 것이 아니라, 젠투 리눅스 개발자들이 만들었다는 것을 알려준다는 것입니다. 다시 한번 말하지만, CVS가 바이너리 파일에 대해 제대로 동작하지 않기 때문에 패치들을 압축해선 안 됩니다.
files/ 디렉터리에 넣을 모든 파일이름에 접두하거나 (mypkg-1.0 처럼)접미하는 것을 고려하여, ebuild의 제각각의 버전에서 사용하는 파일들이 다른 것들과 구별될 수 있 도록 하여 리비전들간의 변경 차이점이 보이도록 합니다. 이러한 방법이 보통 정말 좋은 방법입니다 :). 패치 이름에 좀 더 많은 의미를 부여하려 다른 접미어를 사용하고 싶으실 수도 있습니다.
files/ 디렉터리로 갈 파일이 많다면, files/1.0/ 과 같은 하위 디렉터리를 만들고 적당한 하위 디렉터리에 관련 파일들을 넣는 것을 고려해 보도록 합니다. 만약 이 방법대로 한다면, 종종 더 편한 방법으로 활용되는 파일들의 이름에 버전 정보를 넣을 필요가 없습니다.
Ebuild 스크립트
개요
Ebuild 스크립트는 전체 포티지 시스템의 기반입니다. 어떤 추가적인 설치/제거 혹은 설정의 이전 이후 과정에서 어떻게 수행할 것인지와 같은, 다운로드하고 패키지를 풀고 소스 모음을 설치하는 일련의 정보들을 지니고 있습니다. 포티지의 대부분은 파이선으로 작성되었으며, 배시를 사용하여 명령줄에서 우리가 수행하게 될 명령을 호출할 수 있도록 하기 위해 ebuild 스크립트는 배시 스크립트로 작성되었습니다. ebuild 스크립트의 이면에 있어 중요한 설계 원칙 중 하나는, 패키지를 직접 설치하려 명령줄 상에서 직졉 입력할 명령들을 보유한다는 것입니다. 이 목적을 위해 배시 문법을 사용하는 방법이 가장 좋습니다.
Ebuild 스크립트는 ebuild와 emerge 명령에 의해 번역됩니다. ebuild 명령에 대한 개념은 저수준 빌드 도구 입니다. 이를 통해 단일 ebuild를 빌드하고 설치하지만, 그 이상의 역할은 하지 않습니다. 이를 통해 또한 의존성이 만족하는지 확인하겠지만, 이들 문제를 자동으로 풀려 시도하지는 않을 것입니다. 반면에 emerge 는 고수준의 ebuild 엔진이며, 필요에 따라 의존성을 자동으로 병합하는 능력이 있고, 병합할 내용들을 추측하여 사용자들이 어떤 ebuild가 병합될 것인지 등에 대해 확인할 수 있도록 해줍니다. 일반적으로 emerge는 일부분을 제외하고 ebuild를 능가합니다. ebuild를 통해서 패키지 이머지 (반입, 패키지 해제, 컴파일, 설치, 병합) 의 다양한 부분을 통해 점진적 절차를 한번에 수행할 수 있습니다. 개발자를 위해 귀중한 디버깅 도구가 될 수 있는데, ebuild의 특정 일부분에 대한 ebuild 문제를 봉인할 수 있게 해주기 때문입니다.
ebuild 파일 이름 짓기
Ebuild 파일 이름은 다음 네 부분의 논리적 하위섹션으로 구성되어 있습니다.
pkg_ver{_suf{#}}{-r#}.ebuild
참고: 중괄호 ({})는 선택적 필드를 나타내며 문자 그대로의 패키지 이름상에서>는 나타내지 않습니다. #은 0이 아닌 양의 정수를 나타냅니다.
첫 하위 섹션, pkg는 패키지의 이름을 나타내며 소문자, 0부터 9까지의 숫자 그리고 단일 하이픈 (-), 밑줄 문자 (_) 혹은 양의 부호 (+) 문자만이 포함됩니다. 예를 들자면 util-linux, sysklogd 그리고 gtk+가 있습니다. 어떤 패키지는 이 규칙을 따르지 않지만 여러분의 패키지는 이 규칙을 따르는 것이 좋습니다.
두번째 하위 섹션, ver은 패키지의 버전을 나타내며, 보통 주 소스 타르볼의 버전과 같습니다. 버전은 1.2나 4.5.2처럼 마침표로 구분된 둘 혹은 셋 (그 이상) 의 숫자들로 구성되며, 1.4b나 2.6h처럼 마지막 숫자 다음에 단일 문자가 따라올 수도 있습니다. 패키지 버전은 패키지 이름과 하이픈 (-) 으로 연결됩니다. 예를 들면 foo-1.0, bar-2.4.6 과 같습니다.
중요: 버전 문자열에 꼬리 문자를 사용하려 한다면, 알파와 베타들은 출시 이전 버전들이고 문자 버전은 좀더 새로운 버전임을 나타내기 때문에, 패키지의 알파 혹은 베타 상태를 구분하기 위해 사용되어서는 안된다는 것을 알아두시기 바랍니다. 이는 동일한 카테고리나 이름을 지닌 다른 패키지보다 최신이거나 혹은 더 오래되었을 경우 결정할 ebuild의 버전을 포티지가 사용하기 때문에 중요한 구별 사항입니다. 패키지의 버전을 버전 번호로 충실히 표현하여 포티지가 의존성 검사 정책을 제대로 수행하도록 하는 것은 매우 중요합니다.
세번째 하위 섹션, {_suf{#}}는 다음의 미리 정의된 접미어들중 하나를 선택적으로 포함하며, 덜 최신인 것부터 가장 최신인 순으로 나열하였습니다.
| 접미어 | 의미 |
|---|---|
| _beta | 베타 릴리즈 |
| _pre | 출시 이전 |
| _rc | 출시 후보 |
| (none) | 일반 릴리즈 |
| _p | 패치 레벨(보통 정수가 딸려옴) |
이들 접미어들에는 linux-2.4.0_pre10과 같이 0이 아닌 양의 정수가 딸려옵니다. 동>일한 버전 부분을 감안하여, 접미어는 다음과 같은 순서로 나열됩니다 ( 낮다는 것은 오래됨을 의미합니다 ): _alpha < _beta < _pre < _rc < (접미어 없음)< _p.
정수가 딸려오는 동일한 접미어를 비교할 때, 큰 수가 더 최신인 것으로 간주됩니다. foo-1.0_alpha4가 foo-1.0_alpha3보다 최신인 것입니다.
패키지 이름의 네번째 하위 섹션은 젠투 리눅스에서 지정한 리비전 번호({-r#})입니다. 이 하위 섹션에서는 접미사와 마찬가지로 선택적인 요소입니다. #은 package-4.5.3-r3에서와 같이 0이 아닌 양의 정수를 의미합니다.
이 리비전 번호는 소스 타르볼의 버전과는 별개이며, 사용할 수 있는 일부 패키지의 향상된 젠투리눅스 최신 리비전임을 나타낼 때 사용됩니다. ebuild의 초기 릴리즈는 package-4.5.3과 같이 리비전 번호가 없어야 하며 Portage는 리비전 번호가 0인 것으로 간주합니다. 이는 리비전 카운팅이 1.0(초기 버전), 1.0-r1, 1.0-r2와 같이 진행됨을 의미합니다.
기존의 ebuild 파일에 사소하지 않은 향상 요소를 넣었다면, 리비전 번호를 1 증가시킨 ebuild파일을 복사하는 것이 좋습니다. 리비전 충돌이 야기될 때 항상 ChangeLog와 CVS 커밋 메세지에 변경사항을 명시해야 하는걸 잊지 마시기 바랍니다. 이렇게 하지 않으면 정책을 위반하는 것입니다.
... 그리고 실제로 ebuild 이름의 다섯번째 섹션이 있지 않나 싶습니다. 이 이름에 붙는 .ebuild 확장자가 그것입니다.
ebuild 파일의 내용
이 섹션은 ebuild를 소개합니다. ebuild에서 가능한 모든 내용을 보려면, ebuild 스크립트에서 사용하는 자체 형식과 변수, 함수에 대해 설명하는 manpage가 있습니다: man 5 ebuild.
헤더
ebuild를 제출할 때 헤더는 /usr/portage/header.txt의 헤더와 완전히 동일해야 합니다. 무엇보다 중요한건, 무슨 일이 있더라도 수정해선 안되며, $Header: $부분에 손을 댔는지 확인해보셔야 합니다.
처음 세줄은 다음과 같이 보일 것입니다.
| 코드 예제 2-1: 유효한 헤더 |
| # Copyright 1999-2005 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 |
변수
모든 ebuild파일의 첫 부분은 변수들로 채워집니다. 제각각의 변수에 대한 내용을 보려면 개발설명서를 보도록 합니다.
함수
패키지의 빌드와 설치과정을 제어할 수 있는 ebuild 파일에서 정의할 수 있는 많은 제각각의 함수들이 있습니다.
| 함수 | 용도 |
|---|---|
| pkg_setup | 어떤 기타 조건 작업을 수행할때 이 함수를 사용합니다. 이는 아마도 기존의 설정파일을 검사하는 기능이 있을 것입니다. |
| pkg_nofetch | (라이센스 문제와 같은) 어떤 문제로 인해 소스가 포티지에 의해 자동으로 다운로드 되지 않을때 필요한 동작을 사용자에게 안내합니다. RESTRICT="fetch"와 함께 사용합니다. 이 함수에서는 메세지만 보여주기만 하며, die를 호출하지 않습니다. |
| src_unpack | 소스 패키지를 풀고 패치를 적용하며 autotools와 같은 외부 프로그램을 실행할때 이 함수를 사용합니다. 기본적으로 이 함수는 A에 나열된 패키지를 풉니다. 기본 작업 디렉터리는 WORKDIR에 정의되어 있습니다. |
| src_compile | 패키지를 설정하고 빌드할때 이 합수를 사용합니다. 기본 작업 디렉터리는 S' 입니다. |
| src_install | D에 있는 이미지로 패키지를 설치할 때 이 함수를 사용합니다. 패키지가 automake를 사용한다면 emake DESTDIR="${D}" install로 간단하게 수행할 수 있습니다. D 를 사용하여 패키지의 파일을 설치할 때 루트계정으로 수행하는지 확인하도록 합니다. 기본 작업 디렉터리는 S입니다. |
| src_test | FEATURES="test"가 설정되었고, RESTRICT="test"가 해제되었을 경우에만 실행되며, 이 함수는 기본적으로 제공되는 의존성에 따라 "make test"나 "make check"를 실행하여 ${S} 디렉터리에 있는 어떤 Makefile들로부터 존재하는 시험 기능들을 실행합니다. 사용자 정의 시험 설정을 만드는 것에 우선될 수 있습니다. |
| pkg_preinst | 이 함수의 명령은 시스템에 패키지 이미지를 병합하기 전에 실행할 것들입니다. |
| pkg_postinst | 이 함수의 명령은 시스템에 패키지 이미지를 병합하고 나서 실행할 것들입니다. |
| pkg_prerm | 이 함수의 명령은 시스템으로부터 패키지를 병합해제하기 전에 실행할 것들입니다. |
| pkg_postrm | 이 함수의 병령은 시스템으로부터 패키지를 병합해제하고 난 후에 실행할 것들입니다. |
| pkg_config | 패키지가 설치되고 나서 초기 설정을 수행할때 이 함수를 사용합니다. 이 함수의 모든 경로는 / 가 아닌 사용자 지정 설치 루트를 가리키는 ROOT가 접두사로 붙게 됩니다. 이 함수는 오직 사용자가 실행하려 할때만 사용합니다: emerge --config =${PF} |
도우미 함수
또한 ebuild에서 다음의 도우미 함수를 사용할 수도 있습니다.
| 함수 | 용도 |
|---|---|
| use | 하나 이상의 USE 플래그가 정의되었는지 확인합니다. 만약 정의되어 있다면 shell에 true를 반환합니다. 아무것도 없어도 표준 출력에 표시해줍니다. 자세히 보여주려면, USE 플래그가 정의되었을 때 USE플래그를 보여주는 usev를 사용해보기 바랍니다. |
| has_version | 제각각의 패키지에 대해 요청된 버전이 시스템에 있다면 1을 반환합니다. has_version >=sys-libs/glibc-2.3.0과 같이 사용합니다. |
| best_version | 요청한 category/package의 category/package-version을 반환합니다. best_version x11-libs/gtk+extra와 같이 사용합니다. |
| use_with | 이 함수는 USE플래그가 정의되었는지 확인하고 "- -with-foobar" 나 "- -without-foobar"를 즉시 반환합니다. 만약 단 한 가지의 인자를 사용한다면, 그 인자는 USE플래그와 with(out) 문자열에 해당됩니다. 그렇지 않다면 첫번째 인자는 USE플래그이고 두번째 인자는 with(out) 문자열입니다. use_with truetype freetype와 같이 사용하면 USE 플래그중 truetype을 사용한다면 "- -with-freetype"을 표시할 것입니다. |
| use_enable | use_with와 동일하지만, "- -enable-foobar" 혹은 "- -disable-foobar"를 즉시 반환합니다. |
| check_KV | 포티지가 파악하는 커널 버전을 확인합니다. 만약 안되면 오류를 출력하고 죽습니다. 스크립트 상에 커널 버전이 필요하다면, 포티지가 자동으로 정의한 KV 변수를 사용해보기 바랍니다. gentoo-sources-2.4.20-r6를 실행하는 시스템에서 KV는 2.4.20값을 지니고 있을 것입니다. |
| keepdir | (필요한 경우) 주어진 디렉터리에 .keep 파일을 만들어서 자동으로 제거되지 않도록 합니다. 절대로 .keep 파일을 임의대로 만들지 마시기 바랍니다. 포티지가 keepdir 동작을 변경할 때, 임의로 파일을 만드는 행위가 패키지를 깨지게 할 수도 있습니다. |
| econf | 필요한 경로변경 (prefix, host, mandir, infodir, datadir, sysconfdir, localstatedir)과 함께 ./configure를 수행합니다. econf를 호출했을 때 이들을 지정하여 ./configure에 추가 인자를 선택적으로 넘길 수 있으며, 사용자는 필요한 경우 환경변수 EXTRA_ECONF 를 설정할 수 있습니다. 옵션들은 설정을 위해 주어진 순서의 역순으로 전달됩니다. 다시 말해, 전달된 첫번째 인자는 항상 우선순위가 가장 나중으로 될 것입니다. |
| einstall | 필요한 경로변경 (prefix, datadir, mandir, infodir, datadir, sysconfdir, localstatedir)과 함께 make install을 수행합니다. 다시 말해, einstall을 호출하면 이들을 지정하여 make 명령으로 추가 인자를 넘길 수 있습니다. 패키지를 설치하기 위해 준비된 방법은 emake install DESTDIR="${D}" 명령을 통해서지 einstall을 통한 방법이 아님을 인지하여 주시기 바랍니다. 이 명령은 단지 깨진 make 퍄일에 우선하는 대체용일 뿐입니다. |
| die | 현재 프로세스를 중단하도록 합니다. 주어진 인자를 이유로 사용하여 사용자에게 알려줍니다. 단일 함수에서 이것을 한번 이상 호출한다면 메세지를 전달하는 것을 게을리하지 마시기 바랍니다. 어떤 패키지에서 실패가 발생했는지 알 수 없다면 이를 추적하는 것이 어렵기 때문입니다. |
| elog | 사용자에게 중요한 내용을 알려줍니다. elog에 주어진 인자는 사용자가 보게 될 메시지 입니다. "**************************************" 와 같은 배너를 보여주기 위해 elog를 사용하지 마시기 바랍니다. elog를 사용한다는 것은 사용자의 주의를 충분히 끄는 것입니다. 메시지는 ELOG 시스템을 사용하여 기록됩니다. |
| einfo | 도움이 되지만 로그될 필요가 없는 그다지 중요하지 않은 메시지를 보여줍니다. |
eutils.eclass에서 제공하는 도우미 함수
ebuild에서는 "eutils" eclass에서 제공하는 다음의 도우미 함수를 사용할 수 있습니다. 이 함수가 동작하려면 inherit eutils가 파일에 있는지 확인해보셔야 합니다.
| 함수 | 용도 |
|---|---|
| epatch | 이 함수는 patch의 친숙한 대체 대상처럼 동작하며 .bz2, .gz, .zip 그리고 순수 텍스트 패치와 함께 동작합니다. -p 옵션 뿐만 아니라 EPATCH_OPTS에 명시적으로 지정될 필요가 있는 어떤 옵션도 지정할 필요가 없습니다. 이 함수는 파일이나 디렉>터리 둘 중 하나가 인자로서 사용됩니다. 디렉터리를 사용한다면 "??_${ARCH}_..."와 같은 모양새의 모든 패치가 적용될 것입니다. 이 패치들을 적용하려면 실행중인 아키텍처와 일치하거나, 이름에 "_all_"이 들어가거나 EPATCH_FORCE가 반드시 "yes"로 설정될 필요가 있습니다. |
| gen_usr_ldscript | 이 함수는 /lib에 있는 동적 라이브러리에 대해 /usr/lib에 링커 스크립트를 생성합니다. 이는 /lib에 .so가 있고 /usr/lib에 .a 가 존재할때 연결 문제를 수정합니다. |
| edos2unix | 이 함수는 dos2unix 바이너리처럼 동작합니다. |
| egetent | egetent는 리눅스용 getent나 Mac OS X(R)용 nidump의 래퍼 처럼 동작합니다. |
| enewuser | 새 사용자를 만듭니다. 이 함수는 사용자 이름 인자를 필수로 사용하며 몇몇 추가적 인자가 지정될 수 있습니다: $2 에는 UID가 들어가는데 -1을 전달하면 그 다음 사용가능한 ID를 전달하게 됩니다. $3에는 쉘이 들어가며 -1은 기본값을 의미합니다. $4 에는 홈 디렉터리가 들어가는데 /dev/null이 기본값이 되며, $5 에는 사용자가 들어가게 될 그룹이 들어가는데 빈 값이 기본값이며, $6에는 useradd에 전달하고 싶은 추가적인 옵션이 들어갈 수 있습니다. |
| enewgroup | 새 그룹을 추가합니다. 이 함수는 그룹 이름을 필수로 사용합니다. 추가적인 두번째 인자는 그룹에 지정된 GID를 부여합니다. |
| make_desktop_entry | 데스크톱 엔트리를 만듭니다. 첫번째 인자는 바이너리의 경로를 포함합니다. 선택적으로 두번째 인자는 아이콘의 이름입니다. 기본값은 ${PN}; 입니다. 세번째 인자는 /usr/share/pixmaps에 상대적인 경로를 포함하거나 전체 경로를 포함할 수 있습니다. 기본값은 ${PN}.png; 입니다. 네번째 인자는 프로그램 카테고리를 포함할 수 있고, 다섯번째 인자는 선택적으로 프로그램의 시작 경로를 포함할 수 있습니다. |
| check_license | 사용자가 수락할 라이선스를 표시합니다. 만약 인자가 지정되지 않았다면 ${LICENSE}에 지정된 라이선스가 사용됩니다. |
| unpack_pdv | pdv가 생성한 아카이브를 풉니다. 첫번째 인자는 풀어낼 파일이 반드시 들어가야 하며 두번째 인자는 strace -elseek ${file}과 "4"라는 값을 전달할 lseek(3,-4,SEEK_END)"와 같은 것을 통해 수동 생성될 "off_t"가 들어가게 됩니다. |
| unpack_makeself | makeself가 생성한 아카이브를 풉니다. 풀 파일이름이 인자로서 필요합니다. |
| cdrom_get_cds | CD를 가져오려 시도합니다. 인자에 지정한 파일들은 시스템에 나타나며 ${CDROM_ROOT}에 마운트됩니다. |
| cdrom_load_next_cd | 첫번째 CD에 대한 작업이 끝났다면 다음 CD를 넣도록 합니다. 이 함수가 값을 반환하면 ${CDROM_ROOT}는 다음 CD를 가리킬 것입니다. |
| strip-linguas | 이 함수는 LINGUAS 변수에 패키지에서 지원할 수 있는 함수의 인자로 지정한 언어만 들어있는지를 확인합니다. 첫번째 인자가 -i라면, 지정된 디렉터리에 있는 .po 파일들의 목록이 만들어지고, 리스트들의 교집합이 사용될 것입니다. 첫번째 인자가 -u라면, 지정된 디렉터리의 .po파일 목록이 만들어지고, 전체 리스트들의 모든 항목을 사용할 것입니다. |
flag-o-matic.eclass에서 제공하는 도우미 함수
ebuild에서는 "flag-o-matic" eclass에서 제공하는 다음의 도우미 함수를 사용할 수 있습니다. 이 함수가 동작하려면 {{{#0000ff inherit flag-o-matic }}}이 파일에 있는지 확인해보셔야 합니다. 어떤 컴파일러의 설정이라도 직접 수정하지 않는 것이 좋으며, 문제를 일으>키는 플래그를 걸러내는 일련의 동작을 수행하기 위해서라면 flag-o-matic을 대신 사용해주시는 것이 좋겠습니다.
| 함수 | 용도 |
|---|---|
| filter-flags | 이 함수는 C(XX)FLAGS의 일부 플래그를 제거합니다. 일치하는 완전한 플래그에만 해당됩니다. |
| append-flags | 이 함수는 존재하는 C(XX)FLAGS 변수에 추가 플래그를 추가합니다. |
| replace-flags | 이 함수는 C(XX)FLAGS에 존재하는 플래그중 하나가 들어간 두번째 인자를 지정된 첫번째 인자로 대체합니다. |
| replace-cpu-flags | 두 인자가 필요합니다. 주어진 mtune/march/mcpu 값을 새로운 값으로 바꿉니다 (다음과 같이 될 것입니다: replace-cpu-flags 'i686' 'i586' 은 -mtune/-march/-mcpu=i686 을 -mtune/-march/-mcpu=i586으로 바꿀 것입니다). |
| strip-flags | 모든 플래그를 없애지만, ALLOWED_FLAGS에 지정된 것들은 제외합니다. |
| strip-unsupported-flags | 실행중인 GCC 버전에 의해 지원되지 않는 어떤 플래그든지간에 C(XX)FLAGS에 있으면 없앱니다. |
| get-flag | 플래그를 찾아서 값을 출력합니다. |
| is-flag | 현재 C(XX)FLAGS 에 설정되어 있는 플래그라면 true를 반환합니다. 완전히 일치하는 경우에만 수행됩니다. |
| append-ldflags | 이 함수는 존재하는 LDFLAGS변수에 추가 플래그를 추가합니다. |
| filter-ldflags | LDFLAGS로부터 완전히 일치하는 지정된 플래그만을 제거합니다. |
| fstack-flags | -fstack-protector와 -fstack-protector-all의 적용을 억제하는 -fno-stack-protector를 붙입니다. |
toolchain-funcs.eclass에서 제공하는 도우미 함수
ebuild에서는 "tollchain-funcs" eclass에서 제공하는 다음의 도우미 함수를 사용할 수 있습니다. 이 함수가 동작하려면 {{{#0000ff inherit toolchain-funcs}}} 가 파일에 있는지 확인해보셔야 합니다. 어떤 컴파일러나 binutils의 설정을 직접 명시적으로 지정하지 않는 >것이 좋으며 컴파일러나 binutils를 지정하려면 toolchain-funcs를 사용해주시는 것이 좋겠습니다.
아래 함수들에 대한 사용 목적은 크로스 컴파일링의 지원과 icc 컴파일러를 위한 것입니다. 이 함수들은 gcc, g++, ld, ranlib 또는 아래의 도구들 중 하나를 사용할 때 사용될 것입니다. 자동 설정 도구를 사용하는 일반적인 패키지들은 크로스 컴파일을 자동으로 감지하며 다음 함수를 필요로 하지는 않습니다.
| 함수 | 용도 |
|---|---|
| tc-getAR | 아카이버의 이름을 반환합니다. |
| tc-getAS | 어셈블러의 이름을 반환합니다. |
| tc-getCC | C 컴파일러의 이름을 반환합니다. |
| tc-getCXX | C++ 컴파일러의 이름을 반환합니다. |
| tc-getLD | 링커의 이름을 반환합니다. |
| tc-getNM | 심볼/객체 검사 도구의 이름을 반환합니다. |
| tc-getRANLIB | 아카이버 인덱서의 이름을 반환합니다. |
| tc-getF77 | 포트란 컴파일러의 이름을 반환합니다. |
| tc-getGCJ | 자바 컴파일러의 이름을 반환합니다. |
| tc-getBUILD_CC | 빌드를 위한 C 컴파일러의 이름을 반환합니다. |
| gcc-fullversion | $($CC -dumpversion)으로부터 나오는 버전을 반환합니다. |
| gcc-version | 버전을 반환하지만 <major>.<minor> 형식으로만 나옵니다 |
| gcc-major-version | 메이저 버전을 반환합니다. |
| gcc-minor-version | 마이너 버전을 반환합니다. |
| gcc-micro-version | 마이크로 버전을 반환합니다. |
ebuild 파일 작성 규칙
ebuild파일이 단지 쉘 스크립트이기 때문에, ebuild파일을 편집하려면 편집기의 쉘 스크립트 모드를 사용하는 것이 좋습니다. 적절한 들여쓰기를 하는 것이 좋으며, 들여쓰기에는 공백 문자입력이 아닌 탭을 사용합니다. 편집기가 탭 간격이 4칸으로 조정되어 있는지를 확인합니다. 그리고 환경변수 주변에 중괄호를 감쌌는지 항상 확인합니다. 예를 들어 그냥 $P가 아니라 ${P} 입니다.
긴 줄에 대해서는 '\'로 마무리 합니다. 따라서
| 코드 예제 2.3: ebuild 편집을 위해 vimrc 설정하기 |
| au BufRead,BufNewFile *.e{build,class} let is_bash=1|setfiletype sh au BufRead,BufNewFile *.e{build,class} set ts=4 sw=4 noexpandtab |
이맥스를 사용한다면, app-emacs/gentoo-syntax(GNU Emacs용)나 app-xemacs/gentoo-syntax (XEmacs 용) 둘 중 하나를 이머지 하는 것이 좋습니다. 이 패키지들은 자동 들여쓰기와 ebuild에 대한 문법 강조 그리고 기타 젠투에 특화된 파일 유형을 위한 이맥스 메이저 모드를 제공합니다.
나노를 사용한다면, 운이 참 좋은 것입니다! 단지 /etc/nanorc를 편집하여 ebuild참조 섹션에 대한 주석을 해제하기만 하면 됩니다.
USE 변수
USE 변수의 용도는 포티지 설정을 전체적으로 설정할 수 있게 하고 추가적 빌드 타임에 어떤 기능을 자동으로 활성화 혹은 비활성화 할 수 있게끔 합니다. 예를 들어보도록 합니다. 여러분은 그놈 팬이고 선택적으로 그놈을 지원할수 있는 옵션을 ebuild에 넣고 싶어합니다. 이 경우 /etc/make.conf의 USE 변수에 gnome 을 넣고 USE 변수에 그놈이 설정되지 않았는지 확인합니다. 젠투 리눅스는 여러분이 원하는 방식으로 정확하게 설정된 시스템을 가질 수 있도록, 압도적으로 많은 USE 옵션을 지니고 있습니다.
참고: {{{1}}}
여러분의 ebuild에서 use <variable> 명령을 통해 USE변수에 설정이 되었는지 검사할 수 있습니다. 보통 이 명령을 다음처럼 사용할 것입니다:
| 코드 예제 2.4: USE 플래그가 설정되어 있는지 찾아보기 |
| if use X; then # Commands specific to X... |
USE 변수는 또한 의존성을 설정하기 위해서도 사용됩니다. 예를 들어, 몇몇 USE 변수값이 설정되었을때 패키지를 요구하는 것만 원할지도 모릅니다. 이는 ebuild의 DEPEND 변수에서 flag? ( mycat/mypackage ) 문법을 사용하여 해결할 수 있습니다. 이 경우 mycat/mypackage는 flag가 USE에 있을때만 필요합니다. 또한 어떤 USE 플래그가 설정되었을때와 어떤 USE 플래그가 설정되지 않았을때 어떤 의존성이 사용될지 flag? ( mycat/mypackage ) 와 !flag? ( othercat/otherpackage )로 지정할 수도 있습니다. 이 경우 flag가 설정되어 있지 않았다면 othercat/otherpackage가 mycat/mypackage 대신 사용될 것입니다. 배시의 if를 사용하는 것이 아니라 ebuild의 이 문법을 사용했는지 확인해보시기 바랍니다. Bash 조건문은 포티지의 의존성 캐싱과 혼동되며, 배시 문법을 사용하면 ebuild를 깨지게 할 것입니다.
