do_configure()

• 이전, do_fetch() 까지 ${S}에 source, patch 등을 사용해 Sources를 받아왔다.
• 오픈소스는 autotools나 CMake로 configure 파일을 설정 후, Makefile을 생성한다.

• 오픈소스를 컴파일하기 전에 build디렉토리를 생성하고 Makefile을 생성하는 과정

• configure.ac: autotools 사용하여 configure파일을 생성. -> build 디렉토리에서 ../configure [CONFIGURE_FLAGS]를 실행시켜, Makefile 생성

• CMakeLists.txt: CMake를 사용하여 (inherit cmake) -> build 디렉토리에서 cmake .. [CMAKE_FLAGS] 실행해 Makefile 생성

• do_configure() 태스크의 기본 행동은 Makefile이 발견되면 oe_runmake clean을 동작시킨다.
  • Makefile에 target: clean을 지정하지 않았을 경우
    • OE 빌드 시스템은 make clean을 실행하지 않는다.
  • recipe에 CLEANBROKEN = "1" 명시하면 빌드 동안 make clean이 실행되지 않는다.

---

do_configure() 쉘

• ${S}에서 쉘이 실행된다.
  • pciutils 레시피의 예
    

---

1. configure만 수행하는 경우

EXTRA_OECONF

• ./configure --enable-something --prefix=/usr/bin와 같이 ./configure 에 들어갈 옵션은 EXTRA_OECONF에 지정하면 된다.

EXTRA_OECONF += "--enable-something --prefix=/usr/bin"

---

2. autotools + configure.ac로 configure 생성

• configure.ac 파일이 있다면, configure 파일을 autotools로 생성해야하는 오픈소스이다.
  • GNU/Hello 의 예

~/hello : $ aclocal <options> -I m4
~/hello : $ autoconf
~/hello : $ autoheader
~/hello : $ automake -a
~/hello : $ mkdir build && cd build
~/hello/build : $ ../configure ${EXTRA_OECONF}
Makefile 생성됨

• 대충 이러한 과정으로 1) autotools 로 2)configure 파일을 생성 후, configure를 수행해, Makefile을 생성하는 것이
  • inherit autotools
  • do_configure() 의 동작이다.

---

autotools 주의

• 위 처럼 inherit autotools를 사용해, configure를 생성하는 오픈소스 프로젝트 사용 시, 주의할 점이 있다.
  • yocto에선 기본적으로 B = S로 지정되어 있다.
  • inherit autotools는 기본적으로 B를 명시적으로 지정해야한다.
    • B = S
  • 이를 피하려면, inherit autotools-bokensep를 사용하자.

---

EXTRA_OECONF

• 

---

3. CMakeLists.txt가 있는 경우

• inherit cmake

---

do_compile()

• 이전의 do_configure() 에서 생성된 Makefile, CMakeLists.txt 혹은 autotools로 생되는 빌드 스크립트를 사용해 Compile한다고 생각하면 된다.

1. do_configure를 통해 해당 원본 소스 ${S}(Source)에서 compile을 위해 필요로하는 빌드 설정 파일들을 ${B}(Build)에 추출한다. (보통은 ${S} = ${B} )
2. do_compile를 통해 ${B}(Build)에서 compile을 수행한다.
   2.1.do_compile() 태스크의 기본 행동은 Makefile이 발견되면 oe_runmake function을 동작시킨다.

---

Makefile이 없는 경우

• 컴포넌트 레시피에서 do_compile()부분

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

• bitbake가 소스 파일을 컴파일하기 위해 크로스 컴파일러 호출
• output은 ${B} 변수가 가리키는 곳에 저장된다. (보통은 ${S}와 같음)

---

Makefile이 있는 경우

• do_compile() task의 default behaviour은 Makefile을 발견하면 oe_runmake을 동작키는 것이다.

---

oe_runmake 기본 동작

• do_compile() task에서 make를 직접 call하지 않아도 !! 알아서 bitbake가 do_compile() 할 때, oe_runmake에서 make 호출한다.
  그러니.. do_compile() task에서 직접 make 호출하지 말자!
• 걍 do_compile()에서 make call을 없애자.

---

• bitbake build

---

• 컴포넌트의 ${WORKDIR}/temp/run.do_compile 파일을 보면 해당 컴포넌트의 do_compile() Task 일 때, log 기록을 볼 수 있다.

---

• run.do_compile 로그를 보면 위 컴포넌트 레시피에서 do_compile() Task를 제거 했음에도 불구하고, 스스로 만들고 oe_runmake를 호출

---

• 알아서 '-j' 옵션 들도 넣으면서 make 호출한다.
  • 그러니까 명시적으로 do_compile()에서 make 호출하지말자..

---

EXTRA_OEMAKE

• make 명령 역할을 알아서 oe_runmake가 해준다 치면, makefile의 내부 변수 컨트롤 같은건 어떻게하나?
• 컴포넌트용 레시피에 EXTRA_OEMAKE += "Option"과 같은 형식을 주면 된다.

1. component용 Makefile에 다음과 같은 문장 선언
   

---

2. component의 소스 파일인 userprog.c에 전처리문을 사용하는 문장 추가
   

• 전처리문에 DEBUG 선언 시, line : 6가 반영된다.
• 반영 되기 위해선, 소스파일 어딘가에 #define DEBUG를 하거나
  컴파일할 때, gcc -DDEBUG userprog.c -o userprog 와 같이 compile time에 전처리문(CPPFLAGS)에 추가적인 option을 준다.

---

3. 그런데 레시피에선 어케 동적으로 makefile에 변수를 컨트롤 할까?

• EXTRA_OEMAKE 옵션을 사용한다.
  
  D=1할당하는 옵션을 준다.

• EXTRA_OEMAKE += "D=1"
  • Makefile 내부에 D변수를 설정하고 1을 대입한다.

---

• 이렇게하고, bitbake로 빌드하면..
  
  Component에서 반영된다.

---

• do_configure() task의 default behaviour는 Makefile을 발견하면 oe_runmake clean을 동작시키는 것이다.

---

Makefile 시, 주의사항

• Makefile에서, src, output file을 너무 specific 위치에 지정해버리면, do_install() 때 못알아 먹음
• Yocto가 알아서 컴파일 옵션을 넣어 줄 것이고, 다른 아키텍처에도 적용해야하는데,
  Makefile에서 너무 빡시게 CFLAGS = MYOPTION 같이 =으로 처리하면, 고정되므로 +=를 사용할 것

1. Makefile
   
2. do_install()
   

---

do_compile[network] = "1"

Go, rust 쪽에서 build compile 중에 서브 모듈을 git 으로 dynamic fetch 한다.
이는 Yocto에서, compile 중 network 사용을 막고 있으므로, yocto를 사용하지 않고 빌드 시, 잘되는데 yocto do_compile에서 안될 수 있다.

이를 방지하기 위해, go.bbclass, cargo.bbclass에서 do_compile[network] = "1"를 사용하면, do_compile 중에 network를 사용할 수 있다.

• 

---

-D in CMake

• CMake는 빌드하면서 -D 옵션으로 dynamic variable 지정할 수 있다.

$ mkdir build
$ cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/usr/bin ..

가령 이렇게 한다면 CMake는 CMakeLists.txt의 install 명령의 DESTINATION을 동적으로 /usr/bin으로 바꿔버린다.

---

Recipe for cmake

• 컴포넌트용 레시피가 CMake를 이용한다면!

1. SRC_URI
2. cmake class를 inherit한다.

• poky/meta-mylayer/recipes-example/myhello/myhello_0.4.bb
  • do_compile(), do_install() 따로 필요 없음 (CMakeLists.txt에서 명시해 뒀기 때문)

3. bitbake myhello로 빌드!
   

---

EXTRA_OECMAKE

• EXTRA_OEMAKE와 마찬가지로 CMake 변수를 동적으로 변경한다.
  • $ cmake -DCMAKE_INSTALL_PREFIX=/bin 과 같이 작동하는 것
•