ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Yocto란?
    개발/기술 2016. 9. 16. 21:08


    임베디드 개발자라면 개발보다 환경세팅이 더 힘들다는 말에 공감할 것이다.


    가장 먼저 개발하는 보드의 아키텍처(ARM인지 x86인지)를 확인해야하고, 어떤 OS(대부분 Linux)를 사용하며 버전은 무엇인지 그리고 OS 이미지를 램에 올려줄 부트로더는 어떤걸 쓸건지 등등 선택해야 할 것들이 많다.


    또한 정한 것들을 빌드할 수 있는 환경을 구축하는데도 엄청난 시간이 소요된다. 사용할 컴파일러를 선정하고 다운 받는 것 뿐만 아니라 컴파일러가 사용하는 라이브러리까지 미리 설치해둬야 하는데 자료조사도 어려운데 중간에 뻑나면 개발 하기도 전에 벌써 지친다. 누군가 빌드스크립트로 딱 정리를 해두지 않은 한 정말 피곤한 일이다.


    여기서 더 나아가 한 프로젝트에서 여러 종류의 보드를 사용하고 다양한 리눅스 버전들을 올리는 프로젝트라면 개발자 자신의 환경을 구축하는것도 정리가 꼼꼼한 사람이 아니면 버겁다. 물론 위 모든 작업들의 빌드 환경이 로컬 컴퓨터에 세팅되어있고 항상 기억 할 수 있으면 문제가 없을 것이다. 하지만 이것들을 다른 개발자하고 공유해야하는 상황이면 골치 아파진다. 


    매번 어떤 패치가 나왔으니 메일로 공지하고 다운받으라고 하는데 개발자 각각이 자신의 폴더를 관리하는 것도 급급한 상황에서 남의 폴더까지 공유해주는것은 정신이 없고, 공유가 순조롭게 되어도 누군가는 내 패치가 빌드가 안되는 상황이 발생한다(분명 공유한 사람의 잘못은 아니지만 일단 자리에 가서 해결해줘야 한다) 이런 경우 문제의 원인을 찾는데만 오전/오후를 다보내게된다.


    이런 불필요한 삽질들을 사전에 방지해주는 형상관리 툴이 Yocto다.


    Yocto는 여러 개의 작업을 하나의 작업 경로 내에서 모두 처리 할 수 있는 간편한 빌드 시스템이다.


    예를 들어보자


    개발자가 보드에 부트로드, 운영체제(Linux 3.18, Linux 4.1 각각 따로) 그리고 시스템 이미지를 만드는 작업환경을 구축한다면



    부트로더, 리눅스 소스코드, 시스템이미지를 각각 git에서 받아오고 각각의 빌드 스크립트를 작성한 후 각각의 폴더에서 이미지 파일을 추출해내는 형태일 것이다(아마 이게 가장 깔끔한 형태의 환경일 것이다)


    하지만 yocto는 위 모든것을 하나의 경로내에서 해결 할 수 있도록 구현한다.



    빌드 결과물과 빌드에 필요한 빌드 툴등이 yocto내에서 모두 관리가 되기 때문에 개발자는 특정 이미지를 빌드하러 다른 경로로 이동하지 않아도 되고, yocto에서 다운 받은 컴파일러를 통해서 이미지들이 빌드 되기 때문에 개발자는 컴파일러를 설치하려고 찾아다닐 필요 없다. yocto환경 자체를 git에 올려두어버리면 컴파일 옵션이라던가 필요한 소스코드의 주소들을 다른 사람들과 쉽게 공유 할 수 있게 된다.


    Git에 저장된 코드에 새로운 커밋이 있는 경우 따로 개발자들이 fetch하고 받을 필요 없이, Yocto에서 새로운 패치가 적용된 것을 확인하고 업데이트 후 빌드한다. 개발자들은 출근해서 빌드 한 번 돌리면 새로 업데이트된 이미지를 받을 수 있다.


    빌드로 사용하는 명령어 또한 심플하다. 리눅스 커널 한 번 빌드하는데 make ARCH=x86_64 ... 이렇게 길게 입력하는데 Yocto에선 bitbake [target name] 한방으로 모든 바이너리를 만들어 낼 수 있다(Clean까지 가능하다!)


    물론 단점도 있다.


    용량을 무지 많이 잡아먹는다(적어도 50G는 필요하다고 yocto 홈페이지에서 나와있다)


    일단 yocto를 다운받으면 빌드에 필요한 코드가 하나도 없고 .bb파일들만 가득하다. 위 bb파일은 빌드에 필요한 소스코드를 받을 위치(대부분 git이다), make 옵션과 configure 방법 등등을 갖고 있는 일종의 스크립트이다. 빌드 명령어를 실행하면 yocto실행시 필요한 소스코드들을 모두 가져온다. 부트로더나 운영체제 코드는 기본적으로 가지고 와야하는 것이니 어쩔수 없다 손 치더라도 빌드에 필요한 크로스컴파일러, 라이브러리처럼 이미 시스템이 있을지도 모르는 파일들을 또 다운로드 받아야 한다(그래서 처음 빌드시에는 툴을 다운 받느라 시간도 무지 오래 걸린다)


    하지만 지금껏 삽질로 때운 시간들을 생각해보면 50G의 용량은 그리 아깝지가 않다. 오히려 이정도는 애교 수준이다. 


    새로운 문물을 받아들이는데 보수적인(?) 임베디드 개발자들이어서 그런지 사용법을 익히는데 오래걸린다.


    Yocto 스크립트에는 임베디드 개발자들에게 생소한 파이썬들이 널려 있고 낯선 이름의 선언자들이 줄기차게 널려있다. 어디선가 본 듯 하면서도 막상 사용하려면 어떻게 수정해야 할 까 망설여진다. 게다가 내가 조금만 수정했다고 Yocto는 스크립트 파싱 에러를 빨간줄로 쫙쫙 내놓아 기분 나쁘기 까지... 파이썬 문법도 모르는데 불친절한 Yocto 에러 메시지를 보니 수정할 의욕을 상실해버린다. 회사에서 처음 Yocto를 시작 했을 때 고참 개발자들도 고개를 절래 절래 했을 정도였다.


    하지만 간단한 파이썬 문법과 원리를 파악해보면 마냥 어려운 툴은 아니다.


    다음 포스트에서는 yocto 사용법에 대해서 정리하겠다.


    '개발 > 기술' 카테고리의 다른 글

    objdump 를 이용한 바이너리 깨보기  (0) 2018.05.29
    그래픽 소프트웨어, 라이브러리 정리  (0) 2018.05.06
    Yocto 내부 파일 분석  (1) 2016.10.02
    Yocto 작동방식  (0) 2016.10.01
    Yocto 튜토리얼  (2) 2016.10.01

    댓글

Designed by Tistory.