• 프로젝트 루트 디렉토리
  • 소스코드 디렉토리
  • Thirdparty 디렉토리
    • OpenCV 디렉토리
      • CMakeLists.txt
    • Pangolin 디렉토리
      • CMakeLists.txt
    • eigen 디렉토리
      • CMakeLists.txt
    • ORB_SLAM2 디렉토리
      • CMakeLists.txt
      • Thirdparty 디렉토리
        • g2o 디렉토리
          • CMakeLists.txt
        • DBow 디렉토리
          • CMakeLists.txt
  • CMakeLists.txt

어떤 cpp 프로젝트의 스캐폴드가 위와 같다고 해 보자. 구조에서 드러나듯, 이 프로젝트는 OpenCV, Pangolin, ORB_SLAM2 프로젝트에 의존하고 있음을 알 수 있다. 여기서 g2o/CMakeLists.txt 에 eigen 의존성이 있고, Pangolin/CMakeLists.txt 에도 eigen 의존성이 있고, 루트 레벨의 CMakeLists.txt 에도 eigen 의존성이 있다면 어떻게 프로젝트 루트의 CMakeLists.txt를 구성해야 할까? 정답은 eigen 을 시스템 디렉토리에 설치하는 것이다. 모든 CMakeLists.txt 를 순회하며 수정할 심산이 아니라면..!

여기에 복잡성을 더해서 DBow 에 OpenCV 의존성이 있다고 해보자. 어느 세월에 모든 CMakeLists.txt 의 find_package 에 경로를 명시하고 있겠는가. 그리고 이 구조는 유연하지 못하다는 문제도 있다. 각각의 패키지의 CMakeLists.txt 가 수정된다면, 해당 프로젝트 스캐폴드 내에서만 유효한 패키지가 된다는 문제가 생긴다. 환경을 적절히 격리하려다가 일을 귀찮게 만들게 생겼다(ref1).

이런 문제를 해결하기 위해 시스템 자원의 격리가 가능한 도커가 유용하게 사용될 수 있다.

parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료을 보관해 두는 영역입니다.

1. None

from : 과거의 어떤 원자적 생각이 이 생각을 만들었는지 연결하고 설명합니다.

1. bb2. title: CMake와 같은 높은 추상의 도구들이 나타나기 전에는, 빌드관계를 정의하고 간단한 변수를 선언할 수 있는 스크립트 수준의 간단명료한 Makefile이 있었다.
   • Make를 보완하기 위해 만들어진 CMake도 여전히 해결하지 못하는 부분들이 있다.
2. [bb2.1_1.1_1. title: 굳이 소스코드를 묶기 위해 Makefile을 쓸 필요는 없다. Makefile이 코드형 인프라(Infrastructure as Code (IaC))의 표준인 것은 아니다.](https://janghoo.notion.site/bb2-1_1-1_1-title-Makefile-Makefile-493d6c5ff5e842739e55f677da6a1a5a)
   • Make가 IaC의 영역이라고 할 수 없듯, CMake도 IaC의 영역까지 커버하기 위한 기술은 아니다.
3. bc2_1.1_1. title: 도커는 컨테이너 엔진을 쉽게 다룰 수 있도록 만든 도구의 일종이다.
   • 도커는 도구이지 본질이 아니다.
4. ‣
   • 시스템 경로에 설치된다는 것이 무엇인지는 앞의 글을 참고하라.

supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는지 연결합니다.

1. None

opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는지 연결합니다.

1. None