21.2.1.1.2. `depends on` 지시어를 활용한 하드웨어 아키텍처(예: `ARCH_CHIP_STM32H7`) 및 타 모듈 의존성 검증

21.2.1.1.2. depends on 지시어를 활용한 하드웨어 아키텍처(예: ARCH_CHIP_STM32H7) 및 타 모듈 의존성 검증

menuconfig 블록을 만들어서 빌드 UI 메뉴에 여러분의 커스텀 앱(Custom App)을 당당하게 띄워놓았다고 가정해 보자. 신이 난 다른 협업 개발자가 구형 픽스호크 v2 (STM32F427 칩셋, 램 256KB) 보드를 빌드 타겟으로 잡고 메뉴에 들어가서 이 커스텀 앱의 체크박스를 켰다.

그런데 이 앱이 내부적으로 이미지 처리(Image Processing)를 위해 무려 1MB의 거대한 정적 배열 버퍼(Buffer)를 사용하도록 C++ 로직이 짜여 있다면? 빌드 버튼을 누르는 순간 링커(Linker)는 메모리 초과 에러를 뿜으며 뻗어버릴 것이고, 협업 개발자의 입에서는 육두문자가 터져 나올 것이다.

이러한 ‘하드웨어 피지컬의 불일치’ 또는 **‘필수 선행 모듈 누락’**으로 인한 끔찍한 빌드 실패를 원천 차단하는 우아한 안전장치가 바로 Kconfig의 depends on 지시어이다.

1. depends on: 모듈 활성화의 절대 조건

depends on 지시어는 해당 모듈이 빌드 시스템 메뉴 화면에 체크박스로 아예 활성화(가시화)될 수 있는 극복 불가능한 ’전제 조건’을 명시한다. 만약 이 조건이 거짓(False)이라면, 사용자가 아무리 Kconfig 메뉴를 뒤져도 그 모듈의 이름 자체가 아예 숨김 처리되어 보이지 않는다.

1.1 하드웨어 아키텍처 의존성 검증

가장 흔한 용도는 칩셋의 성능이나 특정 주변장치(Peripherals)의 물리적 존재 유무를 필터링하는 것이다.

menuconfig MODULES_IMAGE_PROCESSOR
    bool "Heavy Image Processing Module"
    default n
    # 오직 H7 계열의 고성능 프로세서에서만 이 모듈을 켤 수 있다.
    depends on ARCH_CHIP_STM32H7
    ---help---
        This module requires huge SRAM and 400MHz+ Core Clock.

위와 같이 코드를 작성하면, 빌드 스크립트가 타겟을 px4_fmu-v2_default (F4 계열)로 파싱 할 때는 ARCH_CHIP_STM32F4 변수가 y가 되므로 이 Kconfig 블록은 평가 과정에서 깔끔하게 무시되고 사라진다. 반면 px4_fmu-v6x_default (H7 계열) 타겟을 빌드할 때 비로소 웅장하게 메뉴에 나타난다.

이는 개발자가 수동으로 지원 여부를 문서에 적어두고 비는 것이 아니라, 빌드 시스템 자체가 하드웨어 스펙을 검증하는 자동 필터로 작동하게 만든다는 점에서 매우 강력한 아키텍처 설계술이다.

1.2 컴포넌트 간 소프트웨어 의존성 주입

depends on은 하드웨어뿐만 아니라, 다른 PX4 시스템 모듈과의 선후 관계를 엮을 때도 빛을 발한다.

menuconfig MODULES_PAYLOAD_DROPPER
    bool "Custom Payload Drop Module"
    default n
    # 이 모듈은 uORB와 PWM 출력 드라이버가 켜져 있어야만 정상 동작한다.
    depends on MODULES_UORB && DRIVERS_PWM_OUT

여러분의 모듈이 내부 C++ 코드에서 MAVLink 메시지를 쏘아 올려야 한다면, 논리적으로 MAVLink 스트리밍 서버 모듈(MODULES_MAVLINK)이 함께 컴파일되어 펌웨어에 존재해야만 런타임에 통신이 가능하다. 위와 같이 Kconfig에 족쇄를 채워두면, 누군가 MAVLink 모듈을 꺼두었을 때 여러분의 커스텀 앱도 연쇄적으로 비활성화되거나 최소한 켤 수 없게 만들어, 미연의 링크 에러나 런타임 크래시를 방지할 수 있다.

(참고로 depends on과 비슷하지만 반대로 작용하는 select MODULES_UORB 지시어도 있다. 내가 켜지면 uORB도 강제로 켜버린다는 뜻인데, 시스템의 필수 모듈을 함부로 강제하는 것은 디펜던시 지옥(Dependency Hell)을 유발하므로 커스텀 앱에서는 가급적 depends on을 통한 소극적 검증만을 사용하는 것이 권장된다.)

이렇게 Kconfig라는 ’문지기’를 통해 논리적 타당성 검사를 무사히 통과했다면, 이제 드디어 진짜 C++ 소스 코드를 컴파일하고 링커 테이블을 조립할 차례다. 이를 관장하는 CMake의 마법 주문, px4_add_module() 매크로의 뒷단에 숨겨진 비밀을 다음 장(21.2.2)에서 낱낱이 파헤쳐보자.