GOOD to GREAT

Android Build system은 그 어떤 전통적인 Build System과도 닮아 있지 않다.

이렇게 거대한 Open source Project는 존재하지 않았기 때문이다.

make는 사용하지 않는다.

Linux kernel 컴파일시 항상 보았던, menu-config도 없다. 

따라서 이해를 위해서 기존의 임베디드 개발에 익숙한 사람들도 시간을 좀 들여야 한다.

Android Build System은 Android.mk 파일에 의해서 어떻게 동작할지가 기술 된다.

이것들의 갯수는 아래와 같다.

2.3.7 Gingerbread, 1,143

4.2 Jelly Bean 2,037

5.1.0_r3 Lollipop 3849

기존 커널 빌딩은

정적이지만, 안드로이드는 동적이다. envsetup.sh 와 lunch를 통해서 동적으로 사용자와 반응 하게된다.

그리고 조정가능한 요소들이 매우 제한적이다.

Build system은 Objet 파일을 만들어 내지 않는다.

중간 결과 따위가 없다.

대신 out/ 디렉터리에 중간 결과물들이 있다. 이것은 .o 파일 따위가 아니다.

마지막으로 아주 심하게 GNU-make 기능에 의존적이다. 다시말하면 정확히 3.81 version에 의존적이다.

3.82는 패치 없이는 동작하지 않는다.

즉, define, include, ifndef 같은 것들이다.

왜 구글이 Recursive Make를 안쓰는지는

"Recursive Make Considered Harmful", Peter Miller를 확인하자.

여기서 single global makefile 이 왜 좋은지를 알 수 있다.

구글은 module-provided .mk file을 가지고 단일 makefile로 컴파일을 한다.

Architecture

<그림 안드로이드 빌드 시스템의 구조>

build/core 디렉터리에서 main.mk를 찾을 수 있다.

각각의 mk 파일들이 모여서 엄청나게 거대한 단일 makefile로 만들어 지며, 이것은 각각의 작은 프로젝트들을 모두 컴파일 한다.

다시한번 말하지만 여러개의 makefile이 재귀적으로 호출되는 구조가 아니다.

Android system을 make해보면

어느정도 긴시간을 아무것도 출력하지 않는것을 알 수 있다.

도대체 그 시간에 무엇을 하고 있는 것일까?

그 시간에 Android.mk들이 서로 조합되는 시간일 것이다. 이것을 실제로 보고 싶은 경우

build/core/main.mk를 수정 하면 된다.

Configuration

빌드를 configure하는 방법은

envsetup.sh 과 lunch cmmand를 이요하는 것이다.

buildspec.mk 파일은 가능한 요건들을 출력 한다.

TARGET_PRODUCT

generic: 기본적인 것

full: 대부분의 앱들이 가능한 버전이다.

full_crespo: full과 같지만, crespo (nexus S)를 위한것

full_grouper: full과 같지만, grouper (nexus 7)을 위한것

sim: simulator를 위한것 하지만 2.3 (gingerbread)에서만 가능 했다.

sdk: 

TARGET_BUILD_VARIANT

eng: user, debug, eng를 포함한다.

userdebug: user, debug를 포함한다.

user: user를 포함한다.

TARGET_BUILD_TYPE

release 아니면 debug 

TARGET_TOOLS_PREFIX

기본적으로 prebuild에 있는 cross development toolchain을 사용 한다.

다른 toolchain을 사용하고 싶으면 새로 설정하면 된다.

OUT_DIR

모든 결과물을 out 디렉터리에 넣는다.

다른 디렉터리를 설정하면 다르게 할 수 있다.

BUILD_ENV_SEQUENCE_NUMBER

Output

host와 target을 위해서 각각 컴파일을 진행