# 1. 빌드 시스템의 코어: CMake, Ninja, 메이크파일 제너레이션 아키텍처

앞서 단편적으로 언급하였던 PX4의 빌드 심장부, 메타 빌드 생성기(Meta-Build Generator)들의 관계와 사슬 구조를 이 장에서 하나의 거대한 다이어그램(Diagram) 관점으로 통일하여 분석한다. 이들의 작동 원리는 펌웨어를 만들어내는 역할을 넘어, 코드가 어떤 계층적 순서로 조립되는지 알려주는 내비게이터(Navigator)와 같다.

CMake: 우주 제너레이터의 설계자
CMake는 그 자체로 어떠한 문법이나 C++ 코드를 기계어로 번역(Compile)할 능력이 단 1%도 없는 순수한 텍스트 처리 프로그램이다. 오직 CMakeLists.txt 에 적힌 매크로 함수들을 디코딩하여 수만 개의 소스 파일 리스트와 컴파일 옵션 깃발(Flag)들을 엮는 작업만 담당한다.

graph TD
    A[CMakeLists.txt 로드] --> B{호스트/타겟 환경 감지}
    B --> C[보드 Kconfig 명세서 스캔]
    C --> D[Python 스크립트 트리거]
    D -.->|Jinja2/empy| E[C++ 코드 동적 생성]
    D --> F[의존성 그래프 연산]
    F --> G(Ninja 빌드 스크립트 출력)

이 설계 로직이 빛을 발하는 곳은 **모듈화(Modularity)**의 마법이다. src/modules/ 아래에 수백 개의 폴더가 존재해도, 보드 타겟 설정에서 +modules/landing_target_estimator 와 같이 해당 모듈 스위치를 ON 시키지 않으면, CMake는 잔혹하게 해당 폴더 전체를 종속 트리에 넣지 않고 잘라버린다. 이로 인해 작은 펌웨어 크기를 유지해야 하는 마이크로 하드웨어들의 생존이 가능해진다.

Ninja: 피도 눈물도 없는 다중 타격 폭격기
CMake가 남기고 간 텅 빈 도면, 단 하나의 build.ninja 메타파일을 물려받는 것은 철저한 실행자 Ninja 엔진이다.
과거 Make는 순차 트리 구조에 갇혀 A가 만들어진 후 폴더 B로 진입하라는 순차적 강박에 시달렸으나, Ninja는 방향성 비순환 그래프(DAG, Directed Acyclic Graph) 이론을 채택하여 타겟과 타겟 간에 의존 화살표가 없는 객체 방(Room) 수백 개를 동시에 걷어차고(Spawn) 다수의 arm-none-eabi-gcc 파동을 일으킨다.
만약 make clang-tidy 코드 포맷 컨벤션이 발포되면, 닌자는 수천 개의 파일을 단 몇 초 만에 병렬 스캐닝하여 띄어쓰기 규격이 어긋난 위치를 화면 한가득 피바람(Error log)으로 도배해 버리는 무시무시한 효율성을 자랑한다.

결과적으로 개발자의 두뇌 \rightarrow CMake (작전 구성기) \rightarrow Ninja (다중 실행기) \rightarrow GCC (기계어 번역기) \rightarrow Pixhawk 메모리 덤프로 이어지는 4단계 수자원 댐 방류 구조를 완벽하게 인지하라. 한 곳의 수문만 막혀도 빌드 라인은 영원히 멈추게 된다.