18.2.1.1 msg/CMakeLists.txt 내 px4_generate_messages 타겟의 동작 트리거 조건

PX4 소스 트리(Source Tree)의 최상위 루트 디렉토리 안에 존재하는 msg/ 서브 디렉토리는 그 자체로 하나의 독립적인 CMake 서브 프로젝트처럼 동작한다. 이곳에 위치한 CMakeLists.txt 파일의 핵심 역할은 수많은 .msg 파일들을 모아 px4_generate_messages라는 이름의 사용자 정의 타겟(Custom Target) 을 구축하는 것이다.

단순히 C/C++ 소스 파일을 컴파일하는 것이 아니라 파이썬 스크립트를 구동하여 파일을 ’창조’해 내야 하기 때문에, CMake 내장 함수인 add_custom_command()와 add_custom_target()의 정교한 조합이 요구된다.

1. 사용자 정의 명령(Custom Command)의 조건부 실행

cmake 커맨드를 처음 실행하여 빌드 환경을 구성하거나 make 커맨드를 쳐서 빌드를 시작할 때, px4_generate_messages 타겟은 무조건 파이썬 스크립트를 실행(Trigger)하지 않는다. 이 파이프라인이 구동되는 트리거 조건(Trigger Condition)은 철저히 파일의 타임스탬프(Timestamp) 및 존재 유무에 기반한다.

CMake 로직 내부에서 스크립트 실행이 촉발되는 명확한 3가지 조건은 다음과 같다.

1.1 출력 파일(Output Files)의 부재 (최초 빌드)

add_custom_command()의 OUTPUT 속성으로 지정된 [토픽명].h 또는 [토픽명].cpp 파일들이 빌드 디렉토리(예: build/px4_fmu-v.../uORB/topics/) 안에 아예 존재하지 않을 때 트리거된다. 이는 운영체제를 새로 스크래치(Scratch)부터 빌드하는 최초 빌드(Clean Build) 시점에 해당한다.

1.2 소스 파일(.msg)의 타임스탬프 역전 (메시지 수정)

가장 빈번하게 작동하는 트리거 조건이다. DEPENDS 속성에 리스트로 연결된 원본 .msg 파일들의 ’최종 수정 시간(Modification Time)’이, 이전에 생성되어 있던 출력물(.h, .cpp)의 생성 시간보다 최신(Newer)일 경우에만 재실행(Re-generation)된다.

• 만약 개발자가 msg/vehicle_status.msg 파일의 주석 단 한 줄만 수정하고 저장하더라도, OS는 해당 파일의 타임스탬프를 갱신하게 되고, CMake 툴은 이를 정확히 감지하여 낡은 헤더 파일을 삭제하고 새롭게 스크립트를 구동한다.

1.3 생성기 엔진(Python/Jinja 스크립트) 자체의 변경

PX4 개발팀은 지능적인 의존성 로직을 추가해 두었다. 토픽을 정의한 텍스트 리스트뿐만 아니라, 코드를 찍어내는 주체인 px4_generate_messages.py 스크립트 파일이나 템플릿 파일(msg.h.jinja 등) 자체의 경로도 DEPENDS 리스트에 하드코딩으로 박혀있다.

• 이로 인해 코어 레벨 개발자가 템플릿 로직이나 파이썬 파싱 스크립트를 업그레이드할 경우, 모든 .msg 파일이 건드려지지 않았더라도 이전 버전에 의해 만들어진 모든 헤더가 “유효하지 다“고 판정받아 전면적인 전체 재생성(Full Re-generation)이 촉발된다.

2. 빌드 지연(Build Latency)의 최소화

이러한 지능적인 트리거(Trigger) 조건 설정은 컴파일 시간 단축에 지대한 공헌을 한다. PX4-Autopilot 안에는 100개가 넘는 메인 .msg 파일들이 존재하며, 매번 make를 칠 때마다 이 모든 헤더를 다시 만들고, 이 헤더를 include 하고 있는 전체 수백 개의 C++ 파일들을 다시 컴파일한다면 로컬 빌드 주기는 한 번에 수십 분씩 소요될 것이다.

msg/CMakeLists.txt 내부에 구현된 이 촘촘한 의존성 감지망(Dependency Graph) 덕분에, 개발자는 커스텀 메세지 1~2개를 수정하더라도 딱 그 파일에 의존하는 C++ 모듈들만 수 초 내외로 즉시 재컴파일(Incremental Build)되는 쾌적한 개발 경험(DX)을 누릴 수 있다.