새 빌드 머신 성능.. 최고는 아니어도 예전의 편안함은 가져오는 8700

Update 09/14 : Linux Native로 옮기고. 한번더
SSD : 72876 01:32:15 R Incremental 이정도면 밥먹고 오면 될정도.
HDD: 80827 03:01:20 S Incremental

i7-8700 에 Windows host – VirtualBox – 6thread 설정, SSD로 빌드시 2시간 정도에서 이전대비 반타작 빌드가 가능하네요. 100% 72876/72876 02:01:23. 속 시원하지 않아도, 이전의 숨막힘은 없어져서 좋습니다. 10 thread로 할당 늘려보고. 리눅스 native로 바꾸어서 해보면 더 나아지겠죠. 이전 PC방출로 고심되네요. 팔릴려나..

근데 요즘 계속 구글이나 페북이나, thinkStation P620 광고가 계속 눈에 들어옴… 얘들아 너네들 그러는거 아냐… 그러라고 광고개인화 허용해준거 아니다.. T.T

Android R official release r3 build

Update:2020-09-12
오늘 sync해보니 뭔가 바뀌어 있음.. manifest snapshot은 같은데.. 뭘까. –; 잠정적인 결론은… S master branch에서 빌드한 out가지고, R로 브랜치만 바꾼 뒤에 그냥 빌드 해서 인가봄.. -,.-;; clean 빌드 가동!

-> Clean build 결과,, Fail …했다가 성공.. 도합 11:01:31 –; 오늘 8700 32GB짜리 중고로 업어왔으니 이제 바꿔서 테스트합니다. 구형 리눅스 머신은 이제 작별해야겠네요..

다 와서. system.img 생성 실패 –;; 어..음..
lunch menu 2번 aosp_arm64-eng 에서 사용되는 BoardConfig는 아래 두개임을 확인함.
1. /build/target/product/aosp_arm64.mk
2. /build/target/board/generic_arm64/BoardConfig.mk
3. /build/make/target/board/BoardConfigGsiCommon.mk
4. /build/make/target/board/BoardConfigMainlineCommon.mk
5. /out/soong/Android-aosp_arm64.mk
3번 파일에서 SYSTEM_RESERVED를 늘리면, 전체이미지에서 여분으로 빼는 공간이 빠져서 마이너스 효과.
1번 파일이 메인 configuration
2번 파일에 수정을 가하면, mk파일 200여개를 새로 읽음.
5번파일이 합쳐진 Android.mk

BOARD_SYSTEMIMAGE_PARTITION_SIZE를 지정하면, 아래 오류…
build/make/core/config.mk:903: error: Should not define BOARD_SYSTEMIMAGE_PARTITION_SIZE and BOARD_SYSTEMIMAGE_PARTITION_RESERVED_SIZE together.

./make/tools/releasetools/test_verity_utils.py:175: DEFAULT_PARTITION_SIZE = 4096 * 1024
./make/target/board/BoardConfigEmuCommon.mk:37: BOARD_SUPER_PARTITION_SIZE := 3229614080

아래파일이 로그와 마찬가지로 기록됨
out/target/product/generic_arm64/obj/PACKAGING/systemimage_intermediates/system_image_info.txt
out/target/product/generic_arm64/misc_info.txt


아무래도 크기 계산은 그냥 맞아떨어지는 것 같은데 selinux때매 부가적으로 추정 로그 찍어주느것 같고.

범인은 아래 같은데, 파일 찾기가 더럽게 어려움. –;

오늘이 AOSP R버전 Release, Master Branch도 안정적

Update(9/10): 8550U Virtualbox 4 core설정으로 38637/69452 4:00:13 fail

Update: Master Branch와 싸움중.. 27881/30200 에서 4코어 프로세서에서 기본 m으로 들어가니 6~8정도로 쓰레드 도는것 같은데.. 1:49:05 만에 30 G메모리로 뻑났음.. –; 아래와 비슷한 상황.. 그래서 그냥 -j4옵션으로 실행중. 남은거 1775컴파일하고 있는데, 죽지는 않겠지.. 근데 시간은 더 오래걸리는 느낌 –; 1775/1775 에 51:39 –; SSD가 이럴진대… HDD로.. 옮겨서 또 걸어봅니다.
HDD빌드는 28910/29518 2:35:02 JDK 11.0.4+0-6508549 에서 크래시… 노트북에서 실행한 VirtualBox도 아예 크래시 –;; VirtualBox다시걸고, HDD쪽은 636/636 14:00 빌드완료가 되네요.
SSD 27881+1775 = 29656에 1:49:05+51:39 = 2:40:44
HDD 28910+636 = 29546에 2:35:02+14:00 = 2:59:02
대부분은 CPU Bound같습니다.. SSD에서 이득보는 부분이 그다지 크지는 않아보이네요
대략 전체 빌드에 10만~13만 정도 작업이 있었으니, 저 시간의 3배인 8~9시간 걸리는게 맞네요. 하아..

Old: R은 나올꺼고. S master를 보고 있는데, 여전히 Fail이네요. –; 활발해보입니다.