Yocto - (R)PROVIDES, PREFERRED_(PROVIDER|VERSION)_

markyang92·2021년 8월 26일

Yocto

yocto

목록 보기

24/53

${TMPDIR}/cache

parsing data를 cache한다.
만약 이 폴더를 지우면, parsing하는데 엄청 오래걸린다.

bitbake namespace

recipe name(build time target) : (${PN} 같이, 통합 package, PROVIDES)
1-1. build time target은 bitbake로 build 가능

$ bitbake myhello
$ bitbake mydhyang

package names(run time target) : (${PN}-dev, 같이 component내 packages-split에 있는 구별된 패키지)
2-1. run time target은 bitbake로 build 불가능

$ bitbake myhello-dev

PROVIDES에서 제공되는 것만 build를 시도할 수 있다.

PROVIDES

bitbake는 컴포넌트에 대해 자동적으로 최신 레시피를 빌드한다.
- e.g., myhello/myhello_0.1.bb, myhello_0.2.bb 시
  자동으로 myhello_0.2.bb 를 빌드함

bitbake는 모든 레시피를 파싱한다.
bitbake는 각 레시피(컴포넌트)의 PROVIDES 리스트를 통해 <target>을 가져온다.

PROVIDES list는 무엇인가?
- 레시피가 알 수 있는 name list
- By default, ${PN}은 자동적으로 PROVIDES 리스트에 추가된다.

myhello 컴포넌트에 대해 PROVIDES를 찾아보자.

$ bitbake -e myhello | grep ^PROVIDES=

PROVIDES Extend 예

레시피에 PROVIDES += "name" 하면 된다.

write 하면, 따로 bitbake build가 없어도, PROVIDES list에 추가된다.

RPROVIDES

RPROVIDES
- package 가 제공하는 PROVIDES라 생각하면 된다.
- RDEPENDS에 의한 다른 패키지 에서의 빌드를 만족 시키는데 유용하다.
- openssh.bb 에서는 RPROVIDES_${PN}-ssh = "ssh" 로 제공한다.
  즉, 다른 레시피에서 RDEPENDS_${PN} = "ssh" ->만 쓰면 = "ssh-ssh"를 사용하는 효과

RPROVIDES 예

myhellolib 컴포넌트

myhellolib-staticdev 만 사용하고 싶다

1-1. myhellolib.bb 레시피

packagegroup-dhyang.bb에 추가

custom-image에서 packagegroup-dhyang 추가

runqemu 로 확인, myhellolib-staticdev만 설치됨

virtual target

recipe가 PROVIDES를 사용한다면, additional aliases는 레시피에 대해 동의어이다. aliases는 다른 레시피 빌드동안 DEPENDS로 명시되어 디펜던시를 만족 시킨다.

PROVIDES는 virtual targets를 가질 수 있다.
같은 특정한 기능과 일치하는 이름을 가진 것
E.g., Kernel, Bootloader, C Library
PROVIDES에서 virtual recipe를 찾는 기능이 있다.
virtual/function (e.g., "virtual/kernel")
slash는 이름과 관단하게 구분 짓고 syntatical significance를 가지지 않는다.

virtual provider를 사용할 때, hard code를 하지 마라..
DEPENDES변수를 virtual/kernel과 같이 지정한다.
DEPENDES = "virtual/kernel"

빌드동안 OpenEmbedded build system이 virtual/kernel 디펜던시에 PREFERRED_PROVIDER 변수를 기반으로 하여 필요한 올바른 레시피를 뽑아낸다.

PREFERRED_PROVIDER

PROVIDES 리스트는 target's recipe에 대해 뽑아낸 솔루션의 부분이다.
target은 multiple providers를 가지고 있으며, bitbake는 providers 우선순위를 매겨야한다. 지정된 provider preferrences

PREFERRED_PROVIDER는 어떤 레시피가 preference를 받는지 결정한다. 멀티플 레시피 provide the same item. 타겟이 멀티플 providers를 가지는 일반적인 예제는 "virtual/kernel"이다. 이는 각 커널 레시피에서 PROVIDES 리스트에 있다.

각 머신은 machine configuration file의 다음 라인을 보고 best kernel provider를 선택한다.
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"

mygit 레시피에 PROVIDES=mylwl을 추가하자
$ bitbake mylwl
아마 당신은 Consider defining a PREFERRED_PROVIDER entry to match mylwl" 메시지를 받을 것이다.

topdir/conf/local.conf에

PREFERRED_PROVIDER_mylwl = "myhello"
PREFERRED_VERSION_mylwl = "1.0"

PREFERRED_VERSION_python = "2.7.3"
PREFERRED_VERSION_linux-yocto = "4.12%"
'%'는 매치 애니 캐릭터

PREFERRED_

PREFERRED_* 변수는 ~~레시피가 아닌~~
- ${TOPDIR}/conf/local.conf
- poky/meta-yocto-bsp/conf/machine/＜MACHINE＞.conf
  등 설정 파일에서 사용
PREFERRED_PROVIDER_'혼돈되는PROVIDES'='고정'
PREFERRED_VERSION_'component'='고정버전'

스펠링 정말 헷갈리니 주의.. preferred -> PREFERRED

PREFERRED_PROVIDER_

PREFERRED_PROVIDER_'혼돈되는PROVIDES'='고정'
- 1)myhello.bb, 2)yourhello.bb 두 레시피에서 PROVIDES = "dhyang"을 사용한다면, bitbake에 혼돈이 온다.
- ${TOPDIR}/conf/local.conf 에 PREFERRED_PROVIDER_dhyang="myhello" 지정 시,
  내 bitbake build 환경에서는 dhyang은 곧 myhello 임

PREFERRED_VERSION_

PREFERRED_VERSION_component=verision
- bitbake는 component에 대해 항상 최신 버전 것을 빌드하려함
- ${TOPDIR}/conf/local.conf 에 PREFERRED_VERSION_dhyang="0.7" 지정 시,
  내 bitbake build 환경에서는 dhyang은 0.7만 사용