9. Package Group & Build Env. | 패키지 그룹과 빌드 환경 구축

 

이번 학습에서는 패키지들을 묶어 한번에 이미지 빌드 레시피에 등록하는 패키지 그룹과 

커스텀 빌드 스크립트를 만들어 원하는 빌드 환경을 구축할 것이다.

 

#목차

1. IMAGE_INSTALL, IMAGE_FEATURES 변수

2. Package Group

3. 이미 정의된 Package Group

4. Custom Build Script를 통한 빌드 환경 구축

5. 최종

 

 

[1] IMAGE_INSTALL, IMAGE_FEATURES 변수

(1) IMAGE_INSTALL 변수

IMAGE_INSTALL 변수는 rootfs에 설치할 패키지를 나열한 변수다.

우리가 앞서 hello/ nano 예제에서 core-image-minimal.bbappend 레시피 확장 파일에

IMAGE_INSTALL += "<package_name>" 작업을 함으로써 rootfs에 설치할 패키지를 등록해줬다.

 

이미지 생성에 있어서 IMAGE_INSTALL 변수에 할당된 패키지와 IMAGE_FEATURES 변수에 할당된 기능들을 종합해 최종 이미지를 생성하는 것이다.

 

(2) IMAGE_FEATURES 변수

IMAGE_FEATURES 변수는 rootfs을 생성하는 대상 이미지 레시피(여기서는 core-image-minimal.bb)에서 상속한 기반 이미지 클래스에 따라 할당할 수 있는 값들이 달라진다.

=> 이미지 클래스는 미리 정의된 기능 목록을 가지고 있고 여기서 필요한 기능을 이 변수에 할당하는 것이다.

 

레시피에 기능을 추가할 때는 IMAGE_FEATURES 변수를 사용하고

 local.conf같은 환경 설정 파일에 기능을 추가할 땐 EXTRA_IMAGE_FEATURES 변수를 사용한다.

실제로 EXTRA_IMAGE_FEATURES변수는 최종적으로 IMAGE_FEATURES에 추가된다.

 

#이미지 클래스(image.bbclass)에 정의된 기능 中 일부

I. debug-tweaks : 개발시 주로 사용되는 기능으로, 비밀번호가 없어 ssh 로그인이 자유로운 특징을 가진다.

II. package-management : rootfs 만들 경우 PACKAGE_CLASSES변수에 설정된 패키지 관리 유형에 따른 패키지 관리 시스템을 설치

III. read-only-rootfs : 읽기 전용으로 rootfs 생성

IV. splash : 부팅 시 스플래시 스크린이 동작한다.

이 외 많은 기능을 제공한다.

 

IMAGE_FEATURES 변수는 이미지에 특정 기능을 활성화 시켜준다. 

#IMAGE_FEATURES변수로 간단 기능 추가 예제

I. poky_src/build/conf/ 디렉터리 아래 local.conf 파일을 아래와 같이 작업한다.

...
EXTRA_IMAGE_FEATURES += "splash"

II. 빌드를 통한 결과 확인

bitbake core-image-minimal -C rootfs
runqemu

#결과
splash screen 표시

 

(3) IMAGE_INSTALL와 IMAGE_FEATURES 차이

rootfs은 위 두 변수로 구성된다. 두 변수는 같은 값을 갖지 않는데.

어떤 변수에 어떤 값을 넣어야할까??

 

일단, IMAGE_FEATURES 변수에 할당되는 값은 무조건 사전에 정의된 목록에 존재해야한다.

그리고 FEATURE_PACKAGES 변수와 함께 사용해야한다.

 

FEATURE_PACKAGES  변수는 아래와 같은 형식으로 사용된다.

FEATURE_PACKAGES_feature1 = "package1 package2"

위 코드는 IMAGE_FEATURES 변수에 feature1 값이 할당되어 있다면 FEATURE_PACKAGES 변수에는 'package1'과 'package2'를 포함시키겠단 뜻이다.

(참고로 IMAGE_FEATURES 변수에 feature1 값이 포함되지 않았다면 실행되지 않는다.)

=> FEATURE_PACKAGES는 rootfs에 package1과 package2를 포함시키게 된다.

 

결론적으로 rootfs을 만드는 이미지 레시피들은 상속한 기본 클래스에 따라 미리 정의된 기능 목록을 다르게 가지며 IMAGE_FEATURES는 사전 정의된 기능 목록 중 사용하고자 하는 기능을 할당해야하고

IMAGE_INSTALL은 레시피에 의해 만들어지는 패키지를 rootfs에 추가할 때 해당 패키지 값을 할당한다.

 

ex) gcc 컴파일러를 가지고있는 'tools-sdk'를 EXTRA_IMAGE_FEATURES 변수에 할당하면 이미지 실행 후 간단한 C 파일을 작성해 실행시켜볼 수 있다.

 

 

[2] Package Group

패키지 그룹은 이미지에 포함될 패키지들을 하나로 묶는 것이다. 

우리가 앞서 hello 등 레시피로 만든 실행 파일을 rootfs에 등록하기 위해 IMAGE_INSTALL += "<package_name>" 작업을 수행했었다. 실제로 IMAGE_INSTALL은 rootfs을 확장하는데 사용된다. 

레시피 확장 파일에 IMAGE_SINTALL += 동작을 하기도 하고...!!

패키지 그룹 동작이 이와 같다... 차이는 패키지를 개별로 추가하는게 아니라 하나로 묶어서 

한번에 추가한다는 것이다.

 

**패키지 그룹은 packagegroups.bbclass 클래스 파일을 상속해 사용한다. 여기서 패키지 그룹을 사용하려고 만든 레시피는 다른 레시피와는 다르게 빌드도, 결과물도 없고 단지 여러 패키지들을 그룹핑해 의존성 부여만 한다!!!

 

패키지 그룹의 레시피 파일 이름은 packagegroup-<name>.bb 형식이고

레이어 디렉터리 아래 레시피 작업 디렉터리(recipes-xxxx) 아래 packagegroups라는 디렉터리 아래에 위치해야한다.

즉, meta-xxxx/recipes-xxxx/packagegroups/packagegroup-xxxx.bb 와 같은 절대 경로를 가질 것이다.

 

(1) core-image-minimal 이미지에 패키지 그룹을 통해 패키지 추가

 I. meta-great이라는 새로운 레이어를 생성하고 기본 디렉터리 구조는 아래와 같다.

poky_src/poky/meta-great

meta-great/
|--conf/
|	|--layer.conf
|--recipes-core/
	|--image/
    |	|--core-image-minimal.bbappend
    |--packagegroups/
    	|--packagegroup-great.bb

 

II. layer.conf 파일을 아래와 같이 작업한다.

BBPATH =. "${LAYERDIR}:"
BBFILES += "${LAYERDIR}/recipes*/*/*.bb"
BBFILES += "${LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLEECTIONS += "great"
BBFILE_PATTERN_great = "^${LAYERDIR}/"
BBFILE_PRIORITY_great = "11"
LAYERSERIES_COMPAT_great = "${LAYERSERIES_COMPAT_core}"

여기서 great 레이어가 최종 반영해야할 메타데이터(패키지 등) 갖고있을 것이기 때문에 레이어 우선순위를 다른 레이어 보다 크게 '11' 값으로 설정해두었다.

BBFILE_PRIORITY_xxx = "숫자값" 이 해당 레이어의 우선순위 값임을 알고있자!

 

III. packagegroup-great.bb 파일을 아래와 같이 작업한다.

DESCRIPTION = "this package group is great`s pkg"
inherit packagegroup

PACKAGE_ARCH = "${MACHINE_ARCH}"
RDEPENDS_${PN} = "\
        hello \
        "

패키지 그룹 레시피 파일에는 전에 만들었던 실행파일 hello의 PROVIDES 변수 값 혹은 패키지명을 RDEPENDS (실행 시간 의존성) 변수에 추가해준다. 

PACKAGE_ARCH는 빌드 후 생성된 이미지가 어떤 아키텍처로 생성돼야하는지 지정할 수 있다.

우리 학습에선 qemu에서 구동 시키니 qemux86_64로 되어있을 것이다. 하지만 hello 패키지는 호스트 pc에서 빌드했기 때문에 intel 프로세서 core2-64로 되어있을 것이다. 문제될 것 같아 보이지만 그건 아니고.. 이 변수는 분류에 따른 접근을 나타낸다.

=> 생성된 이미지가 qemu 머신에서만 동작한다는 것이고, hello패키지는 core2-64를 사용하는 모든 머신에서 호환이 가능 하다는 것이다.

 

레시피 결과물인 패키지가 종송적 아키텍처를 가질 때 

(a) 머신 의존적 패키지 : 특정 머신에 의존적이라면 아래 코드를 추가한다.

PACKAGE_ARCH = ${MACHINE_ARCH}

단, 위 코드 사용시 해당 패키지는 머신 의존적으로 바뀐다..! 주의해서 사용하자

그리고 빌드 시 산출물은 ${MACHINE_ARCH} 디렉터리에 생성된다. 

 

*참고로 bitbake는 산출물 타깃 머신에 따라 디렉터리를 별도로 생성해 결과물을 관리한다.

build/tmp/work/ 디렉터리 아래 가면 여러 디렉터리를 볼 수 있고 각 디렉터리 명을 보면 아키텍처 명이다.

구성은 all-poky-linux/ (아키텍처에 독립적 패키지 빌드), qemux86-...-linux/ (타깃 머신 아키텍처), core2-../ (호스트pc 아키텍처), x86-64-linux/ (현재 pc,  크로스 툴체인에 필요한 산출물 저장) 

 

(b) 아키텍처 의존적 패키지 : 빌드 대상인 머신과 관계없이 모든 아키텍처에서 적용되는 패키지라면

아래 코드를 추가한다.

inherit allarch

 

 

IV. 생성한 패키지 그룹을 rootfs 빌드 레시피에 추가하기 위해 core-image-minimal.bbappend 파일을 아래와 같이 작업한다.

앞서 생성한 패키지 그룹 packagegroup-great.bb를 core-image-minimal의 rootfs 생성 레시피에 추가해준다.

IMAGE_INSTALL += "packagegroup-great"

IMAGE_INSTALL에 패키지 그룹을 추가했으니 패키지 그룹에 속한 모든 패키지들이 추가된것이다.

 

V. 새로운 레이어 great을 bitbake가 인식할 수 있게 build/conf/ 디렉터리 아래 bblayers.conf 파일을 아래와 같이 작업한다.

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /home/yoncho/poky_src/poky/meta \
  /home/yoncho/poky_src/poky/meta-poky \
  /home/yoncho/poky_src/poky/meta-yocto-bsp \
  /home/yoncho/poky_src/poky/meta-hello \
  /home/yoncho/poky_src/poky/meta-great \
  "

위 작업을 통해 패키지 그룹 great에 속한 패키지가 rootfs에 등록될 수 있게 되었다.

하지만! 여기서 끝이 아니라 패키지 그룹에 속한 패키지 레시피 파일에 

core-image-minimal.bbappend 레시피 확장 파일에 패키지 등록 코드가 있다면 지워줘야한다.

 

VI. 패키지 그룹에 속한 패키지의 rootfs 레시피의 확장 파일 내 패키지 등록 코드 제거

# IMAGE_INSTALL_append = " hello"

주석 처리로 처리했다.

위 과정까지 진행했으면 패키지 그룹 준비가 끝났고 빌드하고 타깃 시스템에서 패키지 그룹에 속한 패키지를 실행시켜보자.

 

VII. 빌드 및 타깃 시스템 상 패키지 실행

bitbake core-image-minimal
runqemu core-image-minimal nographic

qemu가 실행 완료되면 추가한 hello 패키지를 실행시켜보자

#패키지 실행
hello

#결과
hello동작...

 

 

(2) 대체 패키지 생성 시 의존성 대체

Yocto 글 중 8번에 해당하는 의존성 내용을 통해 패키지 그룹이 실행 시간 의존성을 이용해 의존된 패키지를 rootfs에 설치한다는걸 알았다. 여기선 추가로 패키지 대체가 필요할 때 실행 시간 의존성 사용법을 공부해보겠다.

 

만약, 앞서 진행한 hello 패키지에 대체 패키지 newhello가 있다고 가정하고 실습해보겠다.

#실습

I. meta-hello/ 디렉터리에 recipes-hello/ 를 복사한 뒤 recipes-newhello/에 복사하고 아래 구조로 작업한다.

meta-hello/recipes-newhello/

recipes-newhello/
|--newhello.bb
|--source/
	|--COPYING
    |--hello.service
    |--newhello.c

위와 같이 파일 이름을 맞춰준다.

 

II. newhello.bb 파일의 내용을 아래와 같이 작업한다.

DESCRIPTION = "Simple Hello World"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=fc535da43eabb329160c3db56b2d9e7e"

SRC_URI = "file://newhello.c"
SRC_URI_append = " file://COPYING"
SRC_URI_append = " file://hello.service"
inherit systemd

S = "${WORKDIR}"
SYSTEMD_SERVICE_${PN} = "hello.service"
SYSTEMD_AUTO_ENABLE = "enable"

do_compile(){
        ${CC} newhello.c ${LDFLAGS} -o hello
}

do_install(){
        install -d ${D}${bindir}
        install -m 0755 hello ${D}${bindir}
        install -d ${D}${systemd_unitdir}/system
        install -m 0644 hello.service ${D}${systemd_unitdir}/system
}

RREPLACES_${PN} = "hello"
RPROVIDES_${PN} = "hello"
RCONFLICTS_${PN} = "hello"

FILESEXTRAPATHS_prepend := "${THISDIR}/source:"
FILE_${PN} += "${bindir}/hello"
FILE_${PN} += "${systemd_unitdir}/system/hello.service"

SRC_URI = "file://newhello.c" 부분과 do_compile() 내용, RREPLACES, RPROVIDES, RCONFLICTS가 수정/추가 되었다. 여기서 RREPLACES, RPROVIDES, RCONFLICTS는 패키지 대체와 관련된(호환성) 변수로 Yocto 8번 글에 설명되어있다.

 

III. newhello.c 파일의 내용을 아래와 같이 작업한다.

#include <stdio.h>
#include <unistd.h>

int main(){

        int i = 0;
        while (i < 10){
                printf("NEW hello world!\n");
                //sleep(1);
                i++;
        }
        return 0;
}

단순 출력 코드이기 때문에 대체된 걸 알려주기 위해 printf문만 바꾸었다.

위 코드 작업이 끝났으면 newhello 대체 패키지를 만드는게 끝이 났다. 하지만 이대로 실행하면

hello 패키지가 중복 생성될 것이다. 왜??

=> bitbake가 recipes-xxx/ 디렉터리를 레시피 빌드 디렉터리로 인식하는데 

우리가 recipes-hello/ 와 recipes-newhello/가 있기 때문이다..

 

위 문제를 우리는 제거하는 방식이 아닌 bitbake가 레시피 파일을 못 찾게 숨기는 기능인  BBMASK라는 변수로 처리할 것이다.

 

IV. build/conf/ 디렉터리 아래 local.conf 파일에 BBMASK 변수를 아래와 같이 추가하자

...
BBMASK = "meta-hello/recipes-hello/"

 

V. 빌드 후 타깃 시스템에서 동작 확인

bitbake newhello
bitbake core-image-minimal -C rootfs
runqemu core-image-minimal nographic

타깃 시스템에서 hello 명령어를 실행 시키면 대체한 패키지의 newhello.c 가 동작하는걸 확인할 수 있다.

 

 

[3] 이미 정의된 Package Group

앞서 우리는 패키지 그룹을 직접 만들었다. 

Yocto에서는 사전에 만들어진 공용 패키지 그룹이 존재한다. 

우리가 사용하는 core-image-minimal.bb 레시피 파일도 확인해보면 

packagegroup-core-boot 라는 패키지 그룹을 사용한다.

 

packagegroup-core-boot.bb 레시피 파일을 확인해보면 

(경로: poky/meta/recipes-core/packagegroups/packagegroup-core-boot.bb)

패키지를 제공, 설치하는게 아니라 실행 시간 의존성 RDEPENS변수를 이용해 각 패키지가 rootfs이 만들어질 때 이미지에 함께 설치되도록 한다. 

 

**보통 이미지 생성을 위한 레시피 파일을 열어보면 packagegroup-core-boot.bb 패키지 그룹 레시피 파일이 존재하는걸 알 수 있다. 왜냐하면 해당 패키지 그룹이 부팅이 가능한 이미지를 생성해주기 때문이다. !!!!

 

패키지 그룹 레시피 파일은 패키지를 실제로 설치하는게 아닌... 추가해야할 패키지를 실행 시간 의존성으로 할당만 해놓고 있다.

 

 

[4] Custom Build Script를 통한 빌드 환경 구축

간단한 빌드 스크립트를 만들어보자..! 우리는 항상 oe-init-build-env라는 빌드 스크립트를 실행시켜 왔다.

oe-init-build-env를 실행시키면 build/ 디렉터리가 생성되고 그 아래 conf/ 디렉터리에 bblayer.conf, local.conf 파일이 자동으로 생성된다. 정확히 생성되는건 아니고 어디 원본이 있는 디렉터리에서 복사해 오는 것이다.

 

빌드 스크립트는 추후에 머신레이어, 배포레이어를 만들고, 환경에 따라 빌드 디렉터리 아래 구조도 변경되어야하기 때문에 배우는 것이고 여기선 기초적인것만 하겠다!

 

우선 TEMPLATECONF 변수를 알아야한다.

TEMPLATECONF : 빌드에 필요한 환경 설정 파일을 어디서 복사해올지 경로를 지정해주는 변수다.

기본값은 poky/meta-poky/conf/ 디렉터리이다.

 

poky/meta-poky/conf/ 디렉터리를 보면 아래와 같다.

bblayers.conf.sample  
conf-notes.txt  
distro  
layer.conf  
local.conf.sample  
local.conf.sample.extended  
site.conf.sample

oe-init-build-env 스크립트를 실행해 bblayer.conf.sample, layer.conf.sample, conf-notes.txt를 복사해온다.

 

복사해올 때 맨뒤 .sample 은 삭제하고 bblayer.conf.sample 파일 내 OEROOT변수는 oe-build system의 특정 파일 절대 경로로 변경된다. 

OEROOT 변수 예시는 아래와 같다.

BBLAYERS ?= " \
  ##OEROOT##/meta \
  ##OEROOT##/meta-poky \
  ##OEROOT##/meta-yocto-bsp \
  "

이게 oe-init-build-env 스크립트를 실행 시키면 아래와 같이 변경된다.

BBLAYERS ?= " \
  /home/yoncho/poky_src/poky/meta \
  /home/yoncho/poky_src/poky/meta-poky \
  /home/yoncho/poky_src/poky/meta-yocto-bsp \
  "

이걸 보고 알 수 있다. OEROOT변수는 oe-init-build-env 스크립트 파일의 절대 경로를 가지고 있다. 

특히, 배포시 build/ 디렉터리를 포함시키면 문제가 될 수 있는 부분이 BBLAYER이다..! 사람마다 파일 위치가 다를 수 있으니 조심해야한다..! 

 

TEMPLATECONF 변수는 oe-init-build-env 스크립트에서 include하고있는

poky/scripts/oe-setup-builddir 파일 내에서 처리되는 변수다..!

oe-setup-builddir 파일 내용 中 아래가 bblayer, local, conf-note 파일을 build/conf/ 디렉터리 아래에 복사해오겠다고 명시되어있는 부분이다.

OECORELAYERCONF="$TEMPLATECONF/bblayers.conf.sample"
OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"

TEMPLATECONF는 oe-init-build-env 스크립트 파일이 위치한 poky/meta-poky/conf/ 디렉터리 경로가 할당되어있다.

참고로 가져오는 파일중 conf-notes.txt는 내용을 확인해보면 알겠지만  oe-init-build-env 스크립트 실행 시 콘솔에 출력되는 안내 문구들이다.

 

 

#Custom Build Script 만들기

I. 레이어 great 디렉터리 아래에 template/ 디렉터리 생성 후 bblayer.conf.sample, local.conf.sample, conf-notes.txt를 복사해온다.

#template 디렉터리 생성
mkdir template

#3개 파일 복사 후 template/ 아래 위치
cp ~/poky_src/poky/meta-poky/conf/local.conf.sample .
cp ~/poky_src/poky/meta-poky/conf/bblayers.conf.sample .
cp ~/poky_src/poky/meta-poky/conf/conf-notes.txt .

 

II. bblayer.conf.sample 파일을 아래와 같이 작업한다.

POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  ##OEROOT##/meta \
  ##OEROOT##/meta-poky \
  ##OEROOT##/meta-yocto-bsp \
  ##OEROOT##/meta-hello \
  ##OEROOT##/meta-great \
  "

 

III. local.conf.sample 파일에 아래 내용을 추가한다.

...
CONF_VERSION = "1"

#Specify own PREMIRRORS location
INHERIT += "own-mirrors"
SOURCE_MIRROR_URL = "file://${COREBASE}/../source-mirrors"

# compress tarballs for mirrors
BB_GENERATE_MIRROR_TARBALLS = "1"

# make shared state cache mirror
SSTATE_MIRRORS = "file://.* file://${COREBASE}/../sstate-cache/PATH"
SSTATE_DIR = "${TOPDIR}/sstate-cache"

DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_remove = "sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts ="systemd-compat-units"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscript = "systemd-compat-units"

 

IV. conf-note.txt 파일을 아래와 같이 작업한다.

### Shell environment set up for builds. ###
Welcome! this is my yocto example
You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal

You can also run generated qemu images with a command like 'runqemu qemux86'

YONCHO WORLD!

 

V. 빌드 스크립트 작성, build/ 디렉터리와 동일한 poky_src/ 디렉터리 아래에 buildenv.sh 스크립트 생성 후 아래와 같이 작업

#!/bin/bash

function find_top_dir()
{
        local TOPDIR=poky
#move into script file path
        cd $(dirname ${BASH_SOURCE[0]})
        if [ -d $TOPDIR ]; then
                echo $(pwd)
        else
                while [ ! -d $TOPDIR ] && [ $(pwd) != "/" ];
                do
                        cd ..
                done
                if [ -d $TOPDIR ]; then
                        echo $(pwd)
                else
                        echo "/dev/null"
                fi
        fi
}

ROOT=$(find_top_dir)
export TEMPLATECONF=${ROOT}/poky/meta-great/template/
source poky/oe-init-build-env build2

여기서 function 부분은 poky/ 디렉터리를 가리킨다. 즉, poky/ 디렉터리의 절대 경로를 얻는 함수이다.

=> 필요한 이유는 poky/ 절대 경로를 알아야 사용하고자 하는 환경 설정 파일이 저장된 디렉터리인 template 디렉터리의 절대 경로를 알 수 있기 때문이다.

TEMPLATECONF변수에는 template/ 디렉터리의 절대 경로를 지정해준다. 즉, 우리가 방금 만든 great 레이어의 template을 기반으로 빌드 환경을 구축하는것이다.

마지막으로 oe-init-build-env 스크립트를 실행하는데 build2는 앞으로 bitbake가 빌드 시 해당 디렉터리에 빌드 결과물을 저장하겠다는 것이다. 

=> 이미 build/ 디렉터리는 기본값으로 생성되기 때문에 build2라 명명했다. 

 

VI. buildenv.sh 권한 부여 및 실행 후 build2/ 디렉터리 확인

#파일 권한 설정
chmod 777 buildenv.sh

#스크립트 실행
source buildenv.sh

 위 명령어 실행 시 결과는 아래와 같다.

### Shell environment set up for builds. ###
Welcome! this is my yocto example
You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal

You can also run generated qemu images with a command like 'runqemu qemux86'

YONCHO WORLD!
yoncho@Desktop_yoncho:~/poky_src/build2$

자동으로 build2/ 디렉터리 아래 위치하게된다.

그리고 추가로 conf/ 디렉터리 아래를 확인해보면 bblayer.conf , local.conf 파일이 정상적으로 존재하는걸 알 수 있다.

bitbake core-image-minimal 명령어로 이미지도 생성되는것도 알 수 있다.

이후 bitbake 실행 시 결과물은 build2/ 디렉터리 아래에 생성될 것이다!!!

 

 

[5] 최종

이번 학습을 통해 IMAGE_INSTALL, IMAGE_FEATURES, FEATURE_PACKAGES 변수에 대해 알 수 있었다.

그리고 패키지 그룹을 통해 rootfs에 올리고싶은 패키지를 각각 등록하는게 아닌 하나로 묶어 등록할 수 있다는 것도 알게되었다. 마지막으로 직접 빌드 환경을 생성하는 빌드 스크립트를 작성해봄으로써 

원하는 빌드 환경을 여러개 구축할 수 있게 되었다..!!

 

너무 유익한 시간이다!! 패키지 그룹과 빌드 스크립트를 꼭 기억하겠다.