21.2.1.1. `src/modules/custom_app/Kconfig` 파일의 구문론적 설계

21.2.1.1. src/modules/custom_app/Kconfig 파일의 구문론적 설계

PX4 빌드 시스템에 여러분의 모듈을 정식으로 입적시키기 위한 첫 번째 관문은 바로 src/modules/custom_app/Kconfig 파일을 올바른 문법으로 작성하는 것이다. 이 파일은 단순한 소스 코드가 아니라, PX4 빌드 도구(menuconfig)가 파싱(Parsing)하여 읽어 들이는 ’메타데이터 명세서’이다.

리눅스의 Kconfig 언어 표준을 그대로 따르고 있는 이 파일은 크게 ’정의부’와 ’의존성 선언부’로 나뉘며, 여기서 단 한 자의 오타만 발생해도 빌드 메뉴 창이 통째로 붕괴되거나 CMake 단계에서 타겟을 찾을 수 없다는 기괴한 에러를 마주하게 된다.

1. Kconfig 기본 뼈대 (Boilerplate)

여러분의 custom_app 디렉터리 안에 생성해야 할 Kconfig 파일의 가장 전형적이고 모범적인 텍스트 구조는 다음과 같다.

menuconfig MODULES_CUSTOM_APP
    bool "Custom Application (My First App)"
    default n
    ---help---
        This is a custom application that reads barometer 
        and controls payload drop relay.

if MODULES_CUSTOM_APP
    # 여기에 커스텀 앱 내부의 세부 옵션들이 들어갈 수 있다.
endif

블록별로 Kconfig 파서가 이것을 어떻게 해석하는지 구문론적(Syntactical)으로 해부해보자.

1.1 심볼(Symbol) 선언: menuconfig vs config

  • menuconfig MODULES_CUSTOM_APP: 가장 뼈대가 되는 식별자(Identifier)이다. menuconfig 지시어를 사용하면, 이 항목이 GCS 보드 설정 창이나 빌드 터미널 메뉴에서 하위 메뉴를 거느릴 수 있는 하나의 ’폴더 형태 체크박스’로 랜더링된다. (단순히 config를 쓰면 하위 메뉴를 열 수 없는 단일 체크박스가 된다.)
  • 작명 규칙(Naming Convention): 앞부분의 MODULES_ 접두어(Prefix)는 여러분의 모듈이 속한 시스템 대분류를 나타내며, CUSTOM_APP은 여러분의 폴더 이름과 일치시키는 것이 PX4 소스 트리의 불문율이다.
  • 주의점: Kconfig에서 정의한 이 식별자 이름 앞에 빌드 도구가 자동으로 CONFIG_라는 접두어 텍스트를 붙여버린다. 즉, 최종적으로 C++ 코드와 CMake가 바라보게 되는 매크로 이름은 **CONFIG_MODULES_CUSTOM_APP**이 된다는 사실을 절대 잊어서는 안 된다.

1.2 가시성과 타입: bool "명칭"

  • bool "Custom Application (My First App)": 이 속성은 두 가지 역할을 동시에 수행한다.
    첫째, 이 모듈의 상태가 켜짐(y) 아니면 꺼짐(n) 상태만 가질 수 있는 불리언(Boolean) 타입임을 선언한다.
    둘째, 따옴표 안에 적힌 문자열을 빌드 UI 화면에 텍스트 트리 버추얼 네임(Virtual Name)으로 표시하여 사용자가 읽을 수 있게 해 준다.

1.3 초기화 상태: default n

  • default n: 보드 설정 파일(.px4board)에서 이 모듈을 명시적으로 강제로 켜지 않는 이상, 기본적으로 이 모듈을 오프(Off) 상태로 두겠다는 뜻이다.
  • 만약 여러분이 짠 모듈이 픽스호크 펌웨어 전체 용량의 핵심을 차지하는 필수 기능이 아니라면, 무조건 default n을 주어 다른 최적화 보드 빌드 시 펌웨어 용량이 폭발하는 민폐를 끼치지 말아야 한다.

1.4 문서화: ---help---

  • ---help--- (또는 help): 모듈에 대한 상세 설명을 주석으로 다는 공간이다. 이 아래 줄부터 적힌 텍스트들은 사용자가 빌드 메뉴에서 ? 단축키를 눌러 도움말을 요청할 때 화면에 출력된다.
  • 들여쓰기(Indentation) 규칙: help 아래의 설명문 텍스트들은 반드시 Kconfig 파서가 계층을 인식할 수 있도록 일정한 간격(보통 공백 4칸이나 탭 1칸)으로 들여쓰기를 해야만 문법 에러가 나지 않는다.

이렇게 Kconfig 구문 구조의 기초 뼈대를 튼튼하게 잡았다면, 이제 가장 중요한 ‘의존성(Dependency) 주입’ 작업이 남았다. 내 모듈이 STM32 칩셋에서만 돌아가야 하는지, 아니면 uORB가 반드시 켜져 있어야 하는지를 정의하는 depends on 지시어의 마법에 대해서는 다음 단원(21.2.1.1.2)에서 심층적으로 분해해 본다.