똑바른 날개

[Cmake] 외부라이브러리 연동 방식 정리(Fetch, Subdirectory, Vendor) 본문

프로그래밍

[Cmake] 외부라이브러리 연동 방식 정리(Fetch, Subdirectory, Vendor)

Upright_wing 2025. 8. 20. 22:01
반응형

개요

외부에서 받아온 패키지를 빌드하고 이를 프로젝트에 연동하는 방법에는 여러 가지가 있다. 이 글에서는 대표적인 세 가지 방식(Git Fetch, Subdirectory, Vendor)을 정리하고, 각각의 장단점 및 적용 시 고려할 기술적인 포인트를 설명한다. 또한, 실제 사용 사례에 따라 어떤 방식을 선택해야 하는지도 함께 제안한다.

모든 예시는 corrosion패키지를 연동하는 방식에 대해서 설명하겠다.

연동 방법

1. Git Fetch 방식

include(FetchContent)
FetchContent_Declare(
  Corrosion
  GIT_REPOSITORY https://github.com/corrosion-rs/corrosion.git
  GIT_TAG        main
)
FetchContent_MakeAvailable(Corrosion)

Git 저장소에서 직접 소스를 가져와, 빌드 시점에 프로젝트에 통합하는 방식이다. 라이브러리를 외부로부터 가져오고 내부 프로젝트처럼 사용할 수 있도록 자동으로 설정해준다.

장점

  • 간단하고 깔끔한 연동 방식 (의존성 자동 다운로드).
  • 버전 고정(GIT_TAG) 및 업데이트 용이.
  • 프로젝트 외부에 의존성을 별도 관리하지 않아도 됨.

단점

  • 빌드할 때마다 외부 네트워크에 의존 → 느려질 수 있음.
  • 빌드 캐시가 없으면 반복 빌드 비용 증가.
  • FetchContent는 재사용 가능한 install 단계가 없음

2. Subdirectory 방식

add_subdirectory(Corrosion)

라이브러리 소스를 미리 내려받아 현재 프로젝트 디렉토리 내에 포함시킨 뒤, add_subdirectory()를 통해 하위 CMake 프로젝트로 포함시켜 함께 빌드하는 방식이다.

장점

  • 전체 프로젝트와 함께 하나의 빌드 트리로 관리 가능.
  • 외부 라이브러리의 CMake 설정을 직접 커스터마이징 가능.
  • 디버깅 시 연동이 명확하고 추적이 쉬움.

단점

  • 외부 소스를 레포에 포함해야 하므로 프로젝트 규모 증가.
  • 라이브러리 변경 시 로컬 수정 → upstream과 싱크 맞추기 어려움.
  • 버전 관리가 어려워질 수 있음.

3. Vendor 방식 (미리 빌드된 라이브러리 연동)

라이브러리를 외부에서 미리 빌드 및 install한 뒤, 해당 결과물을 프로젝트에 연동하는 방식이다. 이 경우, install 디렉토리를 CMAKE_PREFIX_PATH에 등록하여 CMake가 패키지를 찾을 수 있도록 한다.

 
set(CORROSION_INSTALL_DIR "${CMAKE_CURRENT_SOURCE_DIR}/corrosion/install")
# CMAKE_PREFIX_PATH에 Corrosion 설치 경로 추가
list(APPEND CMAKE_PREFIX_PATH "${CORROSION_INSTALL_DIR}")
# Corrosion 패키지 찾기
find_package(Corrosion REQUIRED)

이 방식은 프로젝트와 독립적으로 외부 패키지를 관리할 수 있고, 빌드 속도와 안정성을 확보할 수 있다는 장점이 있다.

장점

  • 반복 빌드 없이 속도 향상 (빌드-링크 분리).
  • 실제 배포와 동일한 방식으로 연동 가능 (real-world package 환경).
  • 라이브러리를 독립적으로 관리하거나 prebuilt binary 사용 가능.

단점

  • install 과정 필요(CMake install 지원 필수).
  • 라이브러리 ABI/API 호환성 주의 필요.
  • 빌드 환경이 다르면 link 에러 발생 가능(예: GCC 버전, 플랫폼).

추가적으로) 해당 방식은 install이 제대로 구현되어 있지 않은 패키지의 경우에는 find_package()를 사용할 수 없다.

시나리오

 
시나리오 추천방식 이유
개발 초기, 빠른 테스트 FetchContent 외부 의존성을 빠르게 끌어올 수 있음
내부 의존성 관리가 필요한 대규모 프로젝트 subdirectory 디버깅과 개발 통합에 유리함
상용 바이너리, ABI 안정성 필요 vendor (install + find_package) 외부 라이브러리와 release 환경 통일 가능

 

반응형