Yocto Project Reference manual chap3 - 3.5

3.5. BitBake

오픈임베디드 시스템은 이미지를 생성하기 위해 BitBake를 사용한다. General Yocto Project Development Environment figure를 보면 BitBake영역은 몇개의 기능으로 구성되어 있다.

하늘색으로 칠해져 있는 부분(Build system)이 BitBake 영역이다.

3.5.1. Source Fetching

recipe을 빌딩하는 첫번째 단계는 소스를 가져와서 언팩하는 것이다.

do_fetch 와 do_unpack은 소스파일을 가져와서 work directory에 소스파일을 압축해제 한다.

Note 모든 파일(예를들어 file:// 같은 경로)은 recipe에 SRC_URI 에서 설정할 수 있고, 오픈임베디드 빌드 시스템은 recipe파일에 검사합(checksum)을 취하여 do_fetch에 checksum의 서명을 삽입한다. 만약 로컬파일이 변형되었다면, do)fetch와 모든 이에 종속된 모든 task는 재실행된다.

기본적으로 모든것은 빌드 폴더(Build Directory) 에서 설치되고, 빌드 폴더는 정의된 구조를 가진다. 

압축해제(unpack)된 소스파일은 s변수로 지정된다. 각 recipe는 압축해제된 소스코드가 있는 빌드 폴더에 있다. 주어진 레시피에 대한 폴더(directory)이름은 몇몇의 변수들로부터 정의된다. 

• TMPDIR - 오픈임베디드시스템이 빌드하는중에 모든 작업을 수행하는 기본 폴더.
• PACKAGE_ARCH - 빌드 패키지 또는 빌드의 아키텍처
• TARGET_OS - 타겟 디바이스의 운영체제
• PN - 빌드 패키지의 이름(PACKAGE NAME)
• PV - 패키지를 빌드하는 것에 사용되는 recipe의 버전(PACKAGE VERSION)
• PR - 패캐지를 빌드하는데 사용된 recipe의 수정본(PACKAGE REVISION)
• WORKDIR - 특정 패키지가 빌드된 TMPDIR의 위치
• S - recipe에 주어진 압축해제(unpack)된 소스파일을 포함하고 있다.

3.5.2. Patching

소스코드를 가져와서 언팩되었던적이 있다면, BitBake는 패치파일을 찾아 소스파일에 적용한다.

do_patch는 적용가능한 패치파일의 위치를 SRC_URI를 사용해서 recipe에 처리한다. 기본적으로 *.patch 또는 *.diff파일이거나 SRC_URI에 "apply=yes"로 적혀저 있는 파일이다.

BitBake는 패치(patch)를 찾은 순서대로 single recipe에 대해 여러 패치를 찾아 적용한다. 패치는 s폴더에 위치한 recipe의 소스파일로부터 적용된다.

더 자세한 정보를 알고싶으면 "Source Fetching" 부분을 봐라.

3.5.3. 구성과 컴파일(Configuration and Compilation)

소스코드가 패치된 후에, BitBake는 소스코드를 구성하고 컴파일하는 일을 실행한다.

빌드프로세스는 세가지로 구성되어있다:

• do_prepare_recipe_sysroot: ${WORKDIR}에 두개의 sysroot(recipe-sysroot 및 recipe-sysroot-native)을 설정하고, 
• do_configure: 이 작업은 빌드되는 소프트웨어에 대한 빌드 타임 및 구성 옵션을 활성화 및 비활성화하여 소스를 구성합니다. 구성은 recipe 자체뿐만 아니라 상속된 클래스에서도 가져올 수 있다. 또한, 소프트웨어 자체는 빌드 대상에 따라 자체적으로 구성할 수 있다. 

    do_configure로부터 다뤄진 구성은 recipe으로 빌드된 소스코드의 특정 소스코드의 구성이다.(??? 이     해되면 추후에 다시 수정)

    만약 autotools클래스를 사용한다면, EXTRA_OECONF 또는 PACKAGECONFIG_CONFARGS변수를 사     용해서 추가 옵션을 사용할 수 있다. 이 변수가 클래스에서 어떻게 작동하는지 자세히 알고싶다면       META/CLASSES/AUTOTOOLS.BBCLASS파일을 봐라

• do_compile: 일단 구성작업이 만족스럽다면, BitBake는 do_compile을 사용해서 소스를 컴파일 한다. 컴파일은 B 변수가 가리키는 폴더에서 발생한다. B 폴더는 기본적으로 S 폴더와 같다. 
• do_install: 컴파일이 완료되었다면, BitBake는 do_install을 실행한다. do_install은 D변수를 사용해서 복사한 B폴더에서 복사한 파일들의 위치를 지정한다.

3.5.4. Package Splitting

소스코드가 컴파일되고 구성된 후에, 오픈임베디드시스템은 결과를 분석하고 패키지에서 나온 결과물들을 분리한다.

do_package 와 do_packagedata 을 결합하여 D 폴더에 있는 파일을 분석하고 사용 가능한 패키지 및 파일을 기반으로 하위 집합(subset)으로 분할한다. 분석 프로세스는 다음항목 뿐만 아니라 다른 항목도 포함하고 있다: 디버깅 기호(debugging symbol) 분리하기, 패키지에 있는 공유된 라이브러리 종속성(dependencies) 확인, 패키지 관계 확인. do_packagedata는 OpenEmbedded 빌드 시스템이 최종패키지를 생성 할 수 있도록 분석을 기반으로 패키지 메타 데이터를 작성한다.

• PKGD - 분할되기 전에 패키지에 대한 폴더
• PAGDATA_DIR - 공유되었고, 패키징을 진행하는 동안에 데이터가 생성되는 전역-상태(global-state) 폴더.
• PKGDESTWORK - do_package로 사용된 임시 작업 영역
• PKGDEST - 분할 된 후 패키지의 부모 폴더(parent directory)

FILES 변수는 PACKAGES의 각 패키지(package)에 들어갈 파일을 정의한다. 더 자세히 알고싶으면 "package" 클래스를 참조해라.

패키지 타입에 의존하는 

3.5.5. Image Generation

패키지는 패키지 피드 영역에서 저장되고 분리된다. 오픈임베디드 빌드 시스템은 루트파일시스템을 만들기 위해 BitBake를 사용한다.

이미지 생성 프로세스는 몇단계로 구성되어 있고 다수의 task와 변수에 의존한다. do_rootfs는 이미지를 위한 루트파일시스템(파일과 폴더 구조)을 생성한다(os image). do_rootfs는 패키지 인스톨 리스트를 생성하는데 도움을 주는 다수의 키 변수(key variable)을 사용한다.

• IMAGE_INSTALL: 패키지 피드 영역에서 설치할 기본 패키지 세트들을 나열한다.
• PACKAGE_EXCLUDE: 설치할 패키지를 지정.
• IMAGE_FEATURES: 이미지를 포함할 기능을 구성. 이 기능의 대부분은 설치를 위한 추가 패키지에 매핑된다.
• PACKAGE_CLASSES: 패키지 백앤드(backend)에 사용할 것을 지정하고 패키지 피드 영역과 함께 패키지 찾을 위치를 지속적으로 결정하는데 도와준다.
• IMAGE_LINGUAS: 추가언어지원 패키지가 설치된 언어를 결정한다.
• PACKAGE_INSTALL: 이미지 설치를 위해 패키지 관리자로부터 전달받은 최종 패키지 리스트.

작성중인 파일시스템의 위치를 가리키는 IMAGE_ROOTFS와 설치하기위한 최종 패키지 목록을 제공하는 PACKAGE_INSTALL변수를 사용하면, 루트 파일 시스템은 생성된다.

패키지 관리가 대상에 대해 활성화되어 있는지 여부에 관계없이 패키지 설치가 패키지 관리자 (예 : dnf / rpm, opkg 또는 apt / dpkg)의 제어하에 있습니다

do_rootfs작업의 마지막 단계는 post processing에 의해 처리된다. post processing은 매니페스트 파일 작성 및 최적화가 포함되어 있다.

매니페스트파일(.manifest)은 루트 파일시스템 이미지 와 같은 폴더에 들어있다.

3.5.6. SDK Generation

오픈임베디드 빌드 시스템은 표준 및 확장가능한 SDK(Software Development Kit)를 포함하는 소프트웨어 개발 킷(SDK)설치 스크립트를 생성하기 위해 BitBake를 사용한다.

교차 개발 툴체인(cross-development toolchain) 생성에 대해 더 알고싶으면, "Cross-Development Toolchain Generation"을 봐라

이미지를 생성하는 것처럼, SDK 스크립트 프로세스는 다수의 단계와 많은 변수에 의존하는것으로 구성되어있다. do_populate_sdk 와 do_populate_sdk_ext는 실제 설치하는 패키지의 리스트를 만드는것을 돕기 위한 중요한 변수들을 사용한다. 이 변수들에 대해 더 알고싶다면 "Application Development SDK"부분을 봐라.

do_populate_sdk는 표준 SDK의 생성과 타겟파트의 생성과 호스트파트를 처리하는데 도움을 준다. 타겟 파트는 타겟 하드웨어에 빌드된 파트이고 헤더와 라이브러리를 포함하고 있다. 호스트 파트는 SDKMACHINE 을 실행하는 SDK의 부분중 하나이다.

do_populae_sdk_ext는 확장가능한 SDK를 생성을 도와주고 표준SDK를 위한 카운터 파츠와는 다른방식으로 호스트와 타겟파츠를 다룬다. 확장가능한 SDK는 빌드시스템을 캡슐화하고 SDK에 요구되는(host와 tartget) 모든것을 포함한다.

SDK가 구성되는 타입과 상관없고, 작업은 일부 정리 작업(clean up)을 수행한 후에 교차개발환경 설치 스크립트와 구성파일(configuration files)에 필요한것이 생성된다. 마지막 출력(output)은 교차개발툴체인(Cross-development toolchain)설치 스크립트(.sh 파일)에 환경 설정 스크립트를 포함하고 있다.

3.5.7. 스탬프 파일과 작업 재실행(Stamp Files and the Rerunning of Tasks)

성공적으로 완료되는 각 작업은, BitBake가 STAMPS_DIR 폴더안에 스탬프파일을 작성한다. 스탬프파일이름의 시작은 STAMP 변수로부터 결정되고 이름의 끝부분은 작업의 이름과 현재 입력의 체크섬(checksum)으로 구성되어 있다.

작업을 재시작해야되는지 확인하려면, BitBake는 작업을 위한 현재입력 체크섬과 일치하는 스탬프 파일을 확인해야 한다. 만약 스탬프파일이 존재한다면, 작업의 출력은 존재하고 유효한 것으로 추정한다. 만약 존재하지 않는다면, 작업은 재시작한다.

STAMPS_DIR은 보통 TMPDIR의 하위폴더이므로, TMPDIR을 지우는것은 STAMPS_DIR을 지우는거나 마찬가지이다. TMPDIR을 다시 만드는 것은 적절하게 다시 실행하는것이나 마찬가지이다.

만약 작업이 항상 "out of date"에 대해 염려된다면, nostamp varflag를 적어라. 만약 몇몇의 다른 작업이 이런 작업에 의존하는 경우, 그 작업은 항상 "out of date"에 대해 고려해야 되고, 이것은 당신이 원하는 것이 아닐 것 이다.

작업의 특징(task's signature)에 대해 더 알고싶으면 "Viewing Task Variable Dependencies" 부분을 봐라.

3.5.8. Setscence 작업와 공유 상태(Setscence Tasks and Shared State)

지금까지의 작업에 대한 설명은 BitBake가 모든 것을 빌드해야하며 미리 만들어진 객체가 없다고 가정한다. BitBake는 만약 이전에빌드했던 객체가 사용가능하면 작업들을 스킵하는걸 지원한다. 이 객체들은 보통 공유 상태(sstate) 캐시의 형태로 제공된다.

sstate에 영향을 주는 변수에 대해 더 알고싶으면, SSTATE_DIR 과 SSTATE_MIRRORS 변수를 봐라

SSTATE_DIR : 공유 상태 캐시(Shared state cache)를 위한 폴더

setscene작업의 개념은 무언가(do_taskname_setscene)를 구축하는 대신 작업의 버전이다, BitBake는 작업 결과를 생략할 수 있고, 필요에 따라 특정 파일 세트를 특정 위치에 배치할 수 있다. 몇가지 예를 들어보면, BitBake는 setscene작업(예 : do_package_write_* 작업에서 패키지 파일 생성)을 사용하는것이 좋다. 다른예로는,