Yocto Project Reference manual chap4

설계된것으로 부터, 오픈임베디드 시스템은 BitBake가 다시빌드가 필요하지않다고 결정한다면 모든것은 처음부터 빌드한다. 기본적으로, 처음부터 빌드하는 것은  불필요한 데이터 문제도 없고 깔끔한 빌드가 되므로 매력적이다. 개발자가 hit 문제를 겪을때, 보통 처음부터 다시 빌드하므로 처음부터 상황의 상태를 알 수 있다. 

처음부터 이미지를 빌드하는것은 프로세스에서 장점이자 단점일 수 있다. 이전 단락에서 언급했듯이, 처음빌딩하는것은 모든것을 최신 상태로 유지하고 알려진 상태(known state)에서 시작할 수 있다. 그러나, 처음빌드 하는것은 일반적으로 재구성 할 필요가 없다는 것을 다시 빌드하는 것을 의미하느로 훨씬 오래걸린다.

욕토 프로젝트는 추가적인 빌드를 지원하는 공유된 상태의 코드를 구현한다. 공유 상태 코드의 구현은 오픈임베디드 증가 빌드 서포트 시스템과 기본적인 장애물에 대한 아래의 질문에 답한다:

• 어떤 시스템이 변경되었고, 어떤시스템은 변경되지 않았냐?
• 어떤 소프트웨어가 변경되었거나 제거되었냐?
• 사용할 수 있을 때 처음부터 다시 빌드 할 필요가 없는 미리 빌드 된 구성 요소는 어떤 방식이냐??

첫번째 질문은, 작업의 입력에 체크섬(또는 시그니처)을 작성하여 태스크에 대한 "입력"의 변경사항을 감지한다. 만약 체크섬이 변경되었다면, 시스템은 입력이 바뀌었다고 추정할 것이고 작업은 재시작이 필요할 것이다. 두번째 질문으로는, 공유 상태 코드(sstate)가 빌드프로세스 출력에서 어떤 작업을 추가하는것을 추적할 수 있는지이다. 이 의미는 주어진 작업으로부터의 출력은 지워질 수 있고, 업그레이드 또는 다르게 다뤄질수도 있기 때문이다. 세번째 질문은 빌드시스템이 원격 위치에서 sstate 객채를 패치할 수 있고, 설치를 할 수 있다면 두번째 질문의 추정에 대한 부분적인 해결책이 될 것이다. 

이 섹션의 나머지는 종합 차등 빌드 아키텍처에서 언급할 것이다.

4.3.1. Overall Architecture

시스템의 어떤 부분을 빌드해야되는지 결정해야 할 때, BitBake는 레시피 단위(per-recipe basis)보다 작업단위(per-task basis)로 작동한다. 너는 아마 작업단위가 왜 레시피단위보다 선호되는지에 대해 우려할 수 있다. 설명을 돕기 위해, IPK를 패키징 백앤드를 활성화 시킨 다음 DEB로 전환하는것을 고려해봐라. 이 경우에는 do_insall 과 do_package 작업출력물(task output)은 유효하다. 그러나, 레시피 단위 관점에선, .deb파일을 포함하지 않는다. 게다가,전체빌드를 무효화하고 이것을 재실행해야 한다. 모든것을 재실행하는것은 최선의 해결책이 아니다. 또한, 이 경우에는 특정작업에 관해 "taught"하는게 핵심이다. 이 방법은 확장성이 뛰어나지 않으며 packaged-staging core를 건드리지 않고도 외부 레시피 또는 레이어로 새 작업을 쉽게 추가 할 수 없다.

4.3.2. Checksums (Signatures)

공유된 상태 코드(shared state code-sstate)는 체크섬을 사용한다. sstate는 작업을 다시 실행해야하는지 결정하기 위해 작업 입력의 고유한 서명이다. 왜냐하면 트리거가 재시작하는 작업의 입력은 바뀌고, 프로세스는 주어진 모든 일에 대한 감지가 필요하기 때문이다. shell작업에서는, 각 작업에 대해 "실행"셸 스크립트를 생성하고 작업의 데이터가 언제 변경되는지에 대한 좋은 아이디어를 제공하는 체크섬을 만들 수 있기 때문에 이것은 매우 쉽다. 문제를 복잡하게 하는것은, 체크섬에 포함되서는 안되는것들이다. 먼저, WORKDIR은 주어진 작업의 실제 특정빌드 경로이다. 작업폴더가 변경되지않는한 상관없다. 왜냐하면 타켓패키지의 출력에 영향을 주지 않기 때문이다. 또한 빌드프로세스는 네이티브 또는 크로스 패키지를 재배치 가능하게 만드는 목적을 가지고 있다.

네이티브와 크로스패키지는 빌드호스트에서 작동한다. 그러나, 크로스패키지는 타켓 아키텍처에 대한 출력을 생성한다.

체크섬은 따라서 WORKDIR을 배재해야 한다. 작업폴더를 배재시키는것에 대한 간단한 접근법은 몇개의 값을 WORKDIR에 설정하고 "실행"스크립트에 채크섬을 설정하는 것 이다. 

또 다른 문제점은 "실행"스크립트가 호출되거나 수신되지 않을 수 있는 기능을 포함하고 있기 때문이다. 증분 빌드 해결책에는 디펜던시(dependencies)와 쉘 함수(shell function) 을 파악하는 코드가 있다. 

이코드는  "run"스크립트를 최소집합으로 줄이기위해 사용된다. 그렇게 해서 앞서 언급한 문제를 해결하고 보너스로 "run"스크립트를 훨씬 더 읽기 쉽게 만들어 준다. 

쉘 스크립트의 해결책에 대해 어느정도 알아보았다. 파이썬 작업에 대해서는 어떻냐? 같은 관점이지만 이 작업은 더 복잡하다. 이 프로세스는 파이썬 함수의 접근 변수를 알아야 하고 어떤 함수를 부르는지 알아야 한다. 게다가, 증분 빌드 해결책은 먼저 변수 및 함수 종속성(dependencies)를 파악한 코드가 들어있으며 작업의 입력에 사용된 데이터의 체크섬을 생성한다. 

WORDIR 경우에는, 종속성(dependencies)을 무시해야 하는 상황이다. 이 경우에는, 아래의 명령어로부터 의존성을 거부하는 빌드 프로세스를 지시할수 있다.

PACKAGE_ARCHS[vardepsexclude] = "MACHINE"

이 예는 MACHINE(예: QEMUARM, QEMUX86, QEMUX86-64)의 값에 의존하지않는 PACKAGE_ARCHS변수를 보장한다. 

마찬가지로, BitBake가 찾을 수 없는 종속성을 추가해야하는 경우가 있다. 아래 라인처럼 입력해서 해낼 수 있다.

PACKAGE_ARCHS[vardeps] = "MACHINE"

이 예는 분명하게 PACKAGE_ARCHS 에 종속성(dependencies)처럼 MACHINE 변수를 추가한다.

즉시 처리하는(in-line)파이썬의 경우를 생각해보면, 예를들어 BitBake는 의존성(dependencies)를 파악할 수 없다. 디버그모드를 실행했을 때(예 : -DDD를 사용할때), BitBake는 종속성을 파악할 수 없는것을 발견하면  출력을 생성한다. Yocto 프로젝트 팀은 현재 이 의존성(dependencies)에 대해 자세히 관리하지 않고 이 상황을 고치는것이 필요하다.

지금까지, 이부분에는 작업에서 직접 입력하는것에 대한 논의가 제한적이였다. 직접입력기반 정보는 코드에서 "basehash"라고 한다. 그러나, 작업의 간접입력에 대한 질문은 여전히 남아있다 - 이러한 것들은 이미 Build Directory 에 언급되어있다. 이 작업을 위한 체크섬(또는 시그니처)는 각 작업에 의존하는 모든 것들의 해쉬를 추가하는 것이 필요하다. 추가할 종속성을 선택하면 정책은 결정이된다. 그러나, 이 효과는 작업 종속성의 해쉬(hash)와 basehash를 포함하는 마스터 체크섬(master checksum)을 생성한다.

코드레벨에선, basehash 와 종속작업(dependent task) 둘다 영향을 받을 수 있는 다양한 방법이 있다. BitBake구성파일과 함께, BitBake가 basehash를 만드는데 도움이 되는 몇 가지 추가 정보를 제공할 수 있다. 아래의 구문은 결과적으로 전역 변수 의존성 배제(global variable dependency exclude) 리스트를 생성한다 -  변수는 절때 어느 체크섬에도 포함되지 않는다 :

BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \        SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \        USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \        PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \        CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"

위에 예에서는 WORKDIR이 제외되었으므로 해당 변수는 실제로 허용 목록에 있는 TMPDIR 내의 경로로 생성됩니다. 종속성 체인(dependency chain)을 통해 포함하는 의존 작업의 해시를 결정하는 룰은 매우 복잡하고 보통 파이썬 함수로 실행된다.  meta/lib/oe/sstatesig.py에서 코드는 이 예제에서의 두가지를 보여주고 또한 원하는 경우 시스템에 자신의 정책을 삽입하는 방법을 보여줍니다. 이 파일은 OE-Core가 사용하는 "OE-Basic"과 "OEBasicHash".  기본적으로,  

=========

추후 업데이트 예정