Yocto Project ref-manual chapter3

3.1. User Configuration

챕터3에서는 Yocto Project development environment에 대해 더 자세히 알아보려고 한다. 아래의 그림은 high level의 개발환경을 표현하고 있다. 이 챕터의 나머지 부분에서는 Yocto Project 개발환경에서의 기본 입력(input), 출력(ouput), 프로세스, 메타데이터를 확장한다. 

출처 : http://www.yoctoproject.org/docs/2.3.1/ref-manual/ref-manual.html#sources-dev-environment

일반적인 Yocto Project 개발환경은 여려기능 영역을 포함하고 있다:

• User configuration: 빌드 프로세스를 제어하는데 사용할 수 있는 Metadata.
• Metadata layers: 소프트웨어, 머신(machine), distro Metadata를 다양한 계층에 제공한다.
• Source Files: 업스트림 릴리스(Upstream releases), 로컬 프로젝트, 그리고 SCMs
• Build System: 프로세스들은 BitBake의 통제하에 있다. 이 블록은 어떻게 BitBake가cross-development tools 생성, 이미지 생성, 테스트 패키지 생성을 위한 출력 분석, 컴파일 완성(completes compilation), 패치 적용, 소스(fetch source)를 가져오는지에 대해 확장하고 있다.
• Package Feeds: 출력 패키지가 포함된 디렉토리(RPM, DEB or IPK), 출력패키지가 포함된 디렉토리는 이미지 또는 SDk의 구조에 계속해서 사용되고, 빌드 시스템으로 부터 생성된다. 이러한 피드는 웹 서버 또는 다른 수단을 사용하여 복사 및 공유 할 수 있으므로 런타임 패키지 관리가 활성화 된 경우 런타임에 장치의 기존 이미지를 확장하거나 업데이트 할 수 있습니다
• Images: 개발 프로세스에 의해 생성된 이미지
• Application Development SDK: Cross-development tools은 BitBake와 별도로 생성되거나 이미지와 함께 생성된다.

3.1. User Configuration

User configuration은 build를 정의하는데 도움이 된다. user configuration을 통해, BitBake에서 이미지를 빌드하는 대상의 아키텍처, 다운로드 한 소스를 저장할 위치 및 기타 빌드 특성을 알 수 있다.

아래의 그림은 일반적인 Yocto Project 개발환경에 그림의 "사용자 구성(User Configuration)"박스의 확장된 것을 나타내고 있다.

출처 : http://www.yoctoproject.org/docs/2.3.1/ref-manual/ref-manual.html#sources-dev-environment

BitBake는 빌드를 완료하기 위해 몇가지 기본적인 구성이 필요하다. 이 파일은 *.conf 파일이다. 소스디렉토리(source directory) 안에 최소한의 필요한 예제들이 들어있다. 간단하게, 이 색션은 "Poky Directory"같은 소스 디렉토리에 대해 언급할 것이다.

poky git repository를 clone하거나 Ycoto Project 를 다운받았을 때, 당신이 원하는 이름으로 Source Directory를 설정할 수 있다. 복제된 저장소는 디폴트 네임으로 poky를 사용한다.

Poky안에 meta-poky계층은 예제구성 파일들이 들어있는 conf 폴더를 포함하고 있다. 이 예제 파일들은 빌드 환경 스크립트(build environment script)를 적용했을 때 실제 구성파일을 생성을 위한 기초로 사용된다.(oe-init-build-env 또는 oe-init-build-env-memres).

실제로 Quic Start에서 source oe-init-build-env 명령어를 사용한다.

만약 Build Directory가 없다면 빌드 환경 스크립트를 적용해서 생성해라. BitBake는 모든 작업을 하는중에 Build Directory를 사용한다. 빌드 폴더는 'local.conf'와 'bblayers.conf'구성 파일의 디폴트 버전을 포함하는 conf폴더를 가지고 있다. 이 기본구성 파일은 빌드 환경 설치 스크립트(build environment setup script)를 적용할 때 빌드 디렉토리 버전이 존재하지 않을 때에만 생성된다.

왜냐하면 Poky 저장소는 근본적으로 현재 저장소의 집합이기 때문이고, 몇몇 사용자들은 아마 싱글 포키 저장소(single Poky repository)를 사용할 바에는 분리된 OpenEmbedded-Core, BitBake 저장소에서 oe-init-build-env 또는 oe-init-build-env-memres 스크립트를 사용하는 것이 더 친근할 것이다.

스크립트의 위치에 따라서 적용되고, 빌드 디렉토리를 설정하기위해 하위 스크립트가 호출된다(Yocto 또는 OpenEmbedded). 분명하게, poky 폴더 안에 있는 스크립트 scripts/oe-setup-builddir 는 빌드 폴더를 셋업하고 Yocto Project 개발환경을 위한 적절한 파일들을 폴더로 함께 시드한다.

local.conf 파일은 빌드 환경을 정의한 많은 기초 변수들을 제공한다. 밑에서 몇가지 목록을 나열 할 것이다. 빌드 환경 스크립트로 작성된 local.conf 파일의 기본 구성을 보려면 local.conf.smaple 안에 meta-poky를 봐라. 

• 병렬 옵션(Parallelism Options) : BB_NUMBER_THREADS, PARALLEL_MAKE, and BB_NUMBER_PARSE_THREADS 변수로부터 제어된다.
• 타겟 머신 선택 : MACHINE 변수로부터 제어된다.
• 다운로드 폴더 : DL_DIR 변수로부터 제어된다.
• 공유 상태 폴더(Shared State Directory) : SSTATE_DIR 변수로부터 제어된다.
• 빌드 출력 : TMPDIR 변수로부터 제어된다.

bblayers.conf 파일은 빌드하는중에 고려해야 할 계층을 BitBake에 알려준다. 기본적으로, 이 파일(bblayers.conf)에 나열된 계층에는 빌드시스템에서 최소한으로 필요한 계층이 포함된다. 그러나, 너가 이 계층을 커스텀하고 싶다면 수동으로 추가해라. bblayers.conf 에 대해 더 자세히 알고싶다면 "Enabling Your Layer" 를 봐라.

site.conf 와 auto.conf는 환경 초기화 스크립트에서 생성되지 않는다. site.conf를 사용하길 원하면 직접 생성해야 한다. auto.conf는 보통 autobuilder로 생성된다. 

• site.conf : conf/site.conf 구성파일을 사용하여 다양한 빌드 폴더를을 구성하는데 사용한다. 

3.3. Sources

• 아래의 그림에서는 보통 Yocto project 개발환경에서 "Upstream Project Releases", "local Projects", "SCMs(optional)" 에서 사용하는 소스파일을 나타낸다.
• 소스파일을 궁극적으로 구성하는 방법은 프로젝트의 기능이다.
• 소스파일은 tarballs(tar 형식으로 압축되있는 파일) 또는 git repository를 통해 다운받을 수 있다.
• BitBake는 SRC_URI 변수를 사용해서 위치에 상관없이 소스파일을 지정할 수 있다.
• 소스파일의 출처에서 중요한 역할을 하는 다른 영역은 DL_DIR 변수로부터 지정된다.(소스를 다운받는 폴더의 위치를 지정해준다는 뜻인 것 같음)
• Git repositories에서 tarballs을 생성하도록 OpenEmbedded 빌드 시스템을 지시할 수 있고(meta-os,networking 등을 clone시키는 것을 예제로 생각 할 수 있다), 이것은 기본적으로 지정되어있는 것이 아니고(default), BB_GENERATE_MIRROR_TARBALLS변수를 사용해서 DL_DIR에 저장할 수 있다.

3.3.1. Upstream Project Releases

• 이 부분에서는 소스파일과 미러를 좀 더 자세히 알아볼 것이다.
• 이 부분은 개인 recipes과 일치한다.
• 아래의 그림은 BusyBox, Qt, Dbus 각각에 대해 특정 릴리즈를 사용한다.
• 아카이브 파일은 recipe을 사용해서 릴리즈된 제품에 빌드할 수 있다.

3.3.2. Local Pojects

• 로컬 프로젝트는 사용자가 제공하는 맞춤  소프트웨어의 작은 단위이다.
• 이것들은 프로젝트의 로컬 어딘가에 존재할 것이고 아마 사용자가 항목을 check in 할 때 생성되는 폴더일 것이다(e.g.그룹에 의해 사용되는 개발 소스 트리를 포함한 로컬 디렉토리).
• 로컬프로젝트를 포함하는 표준 방법은 externalsrc 클래스를 사용하여 해당 로컬 프로젝트를 포함시키는 것이다.
• enxternalsrc 클래스에 대해 더 많은 정보를 알고 싶다면, "externalsrc.bbclass" 부분을 읽어라.

3.3.3. Source Control Managers (Optional)

• 빌드시스템이 소스파일을 얻을 수 있는 또다른 장소는 Git 또는 Subversion 통해 얻을 수 있다. 이 경우에는 저장소(repository)를 복제하거나 체크아웃(check out)해야한다. 
• BitBake안에 do_fetch는 SRC_URI변수와 인자의 프리픽스를 옳바른 fetcher module로 결정하도록 사용한다.  
• 저장소(repository)를 가져올 때 BitBake는 SRCREV변수를 사용해서 빌드할 특정 버전을 결정한다.

3.3.4. Source Mirror(s)

• pre-mirrors와 regular mirrors가 존재한다. PREMIRRORS 와 MIRRORS 변수가 각각 이것들을 지정하고 있다.(PREMIRRORS변수는 pre-mirrors, MIRRORS변수는 regular mirrors)
• BitBake는 어떤 소스파일을 upstream에서 보기전에 pre-mirrors를 체크한다.
• pre-mirrors는 공유된 폴더가 DL_DIR 변수에 의해 정의되지 않은 경우 적절하다.(default 폴더 말고 다른 폴더로 정의해서 다운받는 것이 좋다고 함)
• pre-mirrors는 보통 조직의 로컬 공유 폴더를 가리키고 있다.
• Regular mirror는 기본 사이트가 어떤 이유로든 작동하지 않으면  소스코드의 대체 위치로 사용되는 인터넷상의 모든 사이트를 말한다.