Notice
Recent Posts
Recent Comments
Link
반응형
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |
Tags
- CMAKE
- rospy.spin
- generic pointer
- gjk-epa
- UV
- 워크스페이스
- CONSTRAINTS
- gjk
- narrow-phase
- unittest
- Turtlesim
- remapping
- gradient accumulation
- separating axis theorem(sat)
- vscode
- Topic
- C++
- broad-phase
- rust
- convex
- roslaunch
- mock
- ROS
- Cargo
- cbindgen
- 비동기적
- plotjuggler
- 데이터분석
- corrosion
- subsribe
Archives
- Today
- Total
똑바른 날개
[Cmake] 외부라이브러리 연동 방식 정리(Fetch, Subdirectory, Vendor) 본문
반응형
개요
외부에서 받아온 패키지를 빌드하고 이를 프로젝트에 연동하는 방법에는 여러 가지가 있다. 이 글에서는 대표적인 세 가지 방식(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 환경 통일 가능 |
반응형
'프로그래밍' 카테고리의 다른 글
| 의존성 주입(Dependency Injection) 기법을 활용한 파이썬 코드 개선 방법 (0) | 2026.01.06 |
|---|---|
| 데이터 분석 Tool - PlotJuggler (0) | 2025.08.20 |