배포판 패키지 저장소의 cmake가 프로젝트가 요구하는 버전보다 낮을 때가 있다. 이럴 때 소스를 받아 직접 빌드하는 방법이 가장 먼저 떠오르지만, 실제로는 마지막 수단으로 남겨두는 게 낫다. 컴파일 시간이 걸리고, 시스템에 남은 옛 버전과 경로가 꼬이기 쉽기 때문이다. 먼저 더 쉬운 길이 있는지부터 확인한다.
소스 빌드 전에 볼 것
- 공식 바이너리: https://cmake.org/download/ 에서 리눅스용 셸 설치 스크립트(
.sh)와tar.gz압축 배포본을 바로 받을 수 있다. 컴파일 없이 압축만 풀면 되는 가장 빠른 경로다. - Kitware APT 저장소: 데비안·우분투 계열이면 https://apt.kitware.com/ 에 안내된 저장소를 추가해 배포판 기본 저장소보다 최신인 cmake 패키지를 받을 수 있다. 다만 이 저장소는 Kitware가 스스로 “서드파티 APT 저장소”라고 표기하며, CI 환경에서의 사용은 권장하지 않는다고 명시한다.
- pip:
pip install cmake로도 설치할 수 있다. PyPI의cmake패키지는 미리 컴파일된 바이너리를 휠로 배포하며, 파이썬 가상환경 안에서 프로젝트별로 버전을 격리하고 싶을 때 특히 편하다.
위 세 경로가 모두 막힌 환경—오프라인, 특수 아키텍처, 배포판 저장소에 pip·apt 접근이 안 되는 경우 등—에서만 소스 빌드로 넘어간다.
소스로 빌드하기
cmake 소스를 받아 압축을 풀고 해당 디렉터리에서 부트스트랩 스크립트를 실행한다.
./bootstrap --prefix=/usr/local --parallel=$(nproc)
make -j$(nproc)
sudo make install--prefix는 설치 위치를 지정한다(기본값이 /usr/local이라 이 값을 쓸 거면 생략해도 된다). --parallel은 부트스트랩 단계에서 쓰는 미니 cmake를 컴파일할 때의 병렬 작업 수이고, 실제 cmake 전체 빌드의 병렬도는 뒤이은 make -j 값이 결정한다. 두 값 모두 숫자를 박아넣지 말고 $(nproc)로 넘기면 어떤 머신에서 실행하든 코어 수에 맞춰 알아서 조절된다.
/usr/local 설치와 PATH 충돌
소스 빌드로 설치한 cmake는 보통 /usr/local/bin에 들어가는데, 배포판 패키지로 이미 설치돼 있던 cmake는 /usr/bin에 그대로 남아 있다. PATH에서 /usr/local/bin이 /usr/bin보다 뒤에 있으면 which cmake가 여전히 옛 버전을 가리킨다.
설치 직후 버전이 안 바뀌었다면 셸이 예전 경로를 캐시하고 있는 건 아닌지부터 의심한다. bash는 한 번 찾은 실행 파일 경로를 세션 동안 기억하므로, 같은 이름의 cmake가 다른 경로에 새로 생기면 hash -r로 캐시를 지워야 새 경로를 다시 찾는다. 그래도 안 바뀐다면 echo $PATH로 순서를 확인하고, /usr/local/bin이 /usr/bin보다 앞에 오도록 셸 설정 파일에서 순서를 조정한다.
참고
- CMake Download — 리눅스용 공식 셸 설치 스크립트와 tar.gz 바이너리 배포를 확인했다.
- Kitware APT Repository — 데비안·우분투용 Kitware 저장소가 스스로를 서드파티 APT 저장소로 표기하고 CI 사용을 권장하지 않는다는 안내를 확인했다.
- cmake · PyPI — pip으로 배포되는 cmake 패키지가 사전 컴파일된 바이너리 휠임을 확인했다.
- Kitware/CMake bootstrap 스크립트 —
--prefix,--parallel옵션의 실제 도움말 문자열을 확인했다.