21.2.3.1. boards/ 디렉토리 하위의 default.px4board 파싱(Parsing) 과정
과거 PX4 소스 코드를 뒤져본 적이 있는 개발자라면, CMake의 고전적인 방식대로 루트(Root)의 CMakeLists.txt 파일 맨 아래에 십수 개의 add_subdirectory(src/modules/...) 구문들이 무식하게 나열되어 있던 시절을 기억할 것이다. 하지만 최신 PX4 아키텍처의 루트 CMakeLists.txt를 열어보면 그런 정직한 하드코딩 구문은 온데간데없이 사라졌고, 오직 기하학적이고 난해한 파이썬(Python) 파싱 스크립트 호출문만이 남아있을 뿐이다.
이러한 급격한 변화의 중심에는 바로 타겟 보드 구성 파일(.px4board)의 동적 파싱 아키텍처가 존재한다.
1. 보드 설정 파일의 트리(Tree) 구조 이식
PX4는 하나의 소스 코드로 수십 가지 종류의 비행 칩셋(NuttX, Linux, RPi 브로드컴 칩 등)을 지원하는 어마어마한 레퍼지토리이다. 이 복잡도를 감당하기 위해, 물리적 보드에 대한 하드웨어 정의와 모듈 탑재 목록을 boards/ 라는 최상위 디렉터리 아래에 브랜드별, 보드별, 목적별로 체계적으로 분류해 놓았다.
가령 make px4_fmu-v6x_default 명령어를 실행하면, 빌드 시스템은 가장 먼저 boards/px4/fmu-v6x/ 폴더를 찾아가 그 안에 있는 default.px4board 텍스트 파일을 읽어 들이는 파싱(Parsing) 스크립트를 가동한다.
1.1 파싱의 핵심: Kconfig 도구 체인 주입
단순해 보이는 이 텍스트 읽기 작업은 사실 매우 정교하게 구성된 **Kconfig 도구 체인(Toolchain)**에 의해 이루어진다.
- 순수 텍스트 추출: 파이썬 스크립트(주로
kconfiglib기반 도구)가default.px4board내부의 텍스트 라인들을 한 줄씩 읽어 들인다. - Kconfig 무결성 검증: 읽어 들인 텍스트가
CONFIG_MODULES_CUSTOM_APP=y라면, 스크립트는 이 이름이 단순히 텍스트 오타가 아닌지 확인하기 위해 21.2.1 단원에서 우리가 만들었던 소스 트리의 진짜Kconfig파일들을 싹 다 뒤져서(Sweep) 대조한다.
만약.px4board파일에는켜짐(y)이라고 적었는데 실제Kconfig에 그런 메뉴가 없다면 즉각 파싱 에러를 뱉어낸다. - CMake 변수 렌더링(Rendering): 무결성 검증을 통과한 수백 개의
CONFIG_...=y리스트들을 긁어모아, CMake가 모국어로 읽을 수 있는 C++ 스타일의 CMake 캐시 파일 형태(CMakeCache.txt또는px4_board_config.cmake)로 변환하여 아웃오브트리(Out-of-tree) 빌드 폴더 어딘가에 조용히 저장한다.
2. 왜 이렇게 복잡하게 꼬아놓았는가?
이 파싱 파이프라인 덕분에, PX4 코어 메인테이너들은 새로운 비행 제어기 보드(예: Pixhawk 7)가 세상에 출시되었을 때 C++ 소스 코드나 수천 줄의 CMakeLists.txt를 단 한 줄도 건드릴 필요가 없어졌다. 오직 boards/px4/fmu-v7/default.px4board 텍스트 파일 하나만 생성해서 Kconfig 스위치 리스트만 나열해 주면, 빌드 시스템이 파싱 스크립트를 통해 알아서 펌웨어 바이너리를 재단해 주기 때문이다.
이러한 우아한 파싱 과정을 거쳐 생성된 Kconfig 스위치 파일이, 구체적으로 어떻게 CMake의 add_subdirectory()라는 핵주먹을 날려 여러분의 모듈 디렉터리로 컴파일러를 윽박지르는지 그 트리거 로직을 다음 단원(21.2.3.1.1)에서 속 시원하게 분해해 보자.