### 0.0.1 CMake 및 Build System Generator (Ninja vs GNU Make) 컴파일 속도 비교

PX4 소스 코드를 온전히 컴파일하는 데는 수십~수백만 레코드의 전처리가 요구된다. 이 막대한 트래픽 패턴을 어떤 빌더(Builder)가 주도하여 이끌고 가느냐에 따라 개발자의 퇴근 시간이 결정된다. PX4 빌드 생태계는 과거 전통적인 GNU Make 기반에서 최신 Ninja 기반으로 표준 제너레이터를 완전히 뜯어고쳤다. 이 둘 간의 구조적 컴파일 속도 차이를 수치와 아키텍처 관점에서 해부한다.

재귀적 늪(Recursive Make)의 한계
과거 임베디드 리눅스의 바이블로 숭배받던 GNU Make는 하위 폴더별로 Makefile을 연쇄적으로 호출하는 재귀적 트리를 구성한다(Recursive Make).
문제는 PX4 안에 존재하는 수많은 드라이버 모듈 폴더 하나를 들어갈 때마다, Make가 자식 프로세스(Child Process)를 소환하고 의존성 트리(Dependency Tree)를 매번 새로 디코딩해야 한다는 점이다. 만약 개발자가 파일 딱 한 줄을 고치고 다시 make를 누르면, 수정된 파일을 찾기 위해 make 알고리즘은 전체 서브 트리 구석구석을 순회(Traversing)하며 무의미하게 파일 타임스탬프를 대조하는 데만 $10 \sim 15$ 초의 ‘No-op(아무것도 안 함) 빌드 지연시간’ 을 소모한다.

그래프 기반 동시 융단폭격기: Ninja Build
반면, 크롬(Chromium) 브라우저 컴파일을 위해 개발된 Ninja는 단 하나의 초거대 단일 종속성 그래프(build.ninja) 파일만을 읽어들인다.

순회 없음, 즉각 타격: 코드가 수정되었을 때 Ninja는 단일 파일과 의존성이 연결된 타겟 노드(Node)만을 메모리 그래프에서 단숨에 O(1) 해시로 끄집어내어 즉각 번역에 들어간다. 수십 초가 소요되던 No-op 대기 시간이 $1$ 초 미만으로 압축된다.
극한의 병렬 스케줄링: Make -j$N 옵션은 자식 프로세스 포크에 의한 병목 현상이 발생하지만, Ninja는 호스트 PC의 CPU 스레드를 극한으로 장악하여, 철저하게 선행 의존성이 없는 수백 개의 .cpp 파일을 비동기적(Asynchronous)으로 동시에 쏘아버린다.

결과적으로, PX4 클린 빌드(Clean Build) 기준 Make로 $5$ 분이 걸리던 랩타임이 Ninja 제너레이터 체제하에서는 단 $1$ 분 $30$ 초 이내로 단축되는 기염을 토한다. 이 구조적 승리 덕분에 PX4 CMake 파이프라인의 기본(Default) 옵션은 오직 Ninja로만 종속 고정되어 있다.