CMake 문서를 처음 열었을 때만 해도 별 느낌이 없었는데, 대충 읽어보고 FireBreath를 빌드하면서 깨달은 게 있었죠. 아 이거 쥐약이구나.
CMake는 멀티플랫폼 빌드를 지원하기 위해 플랫폼에 맞춰 빌드 파일을 생성해주는 도구이고, 이 빌드 파일을 돌려서 실제 빌드를 수행하는데요. 이 과정에서 모든 경로를 절대경로로 생성합니다. 이게 당시 개발팀의(그리고 아마도 대부분의 Windows 개발자들의) 개발환경과는 맞지가 않아요. 당시에 제가 있던 개발팀이 그러하듯 모든 사용자가 각자 마음대로 시스템을 구성하고 각자 편한 위치에 소스를 내려 받아서 개발하기 위해서는 소스코드 저장소에 절대경로가 없어야 하는데, CMake를 사용하려면 필연적으로 빌드 환경에 절대경로가 박혀버려요. 이거 아주 지저분하죠.
CMake 공홈에 나와있는 FAQ에는 이렇게 설명하고 있습니다.
Why does CMake use full paths, or can I copy my build tree?
CMake uses full paths because:
- configured header files may have full paths in them, and moving those files without re-configuring would cause upredictable behavior.
- because cmake supports out of source builds, if custom commands used relative paths to the source tree, they would not work when they are run in the build tree because the current directory would be incorrect.
- on Unix systems rpaths might be built into executables so they can find shared libraries at run time. If the build tree is moved old executables may use the old shared libraries, and not the new ones.
Can the build tree be copied or moved?
The short answer is NO. The reason is because full paths are used in CMake, see above. The main problem is that cmake would need to detect when the binary tree has been moved and rerun. Often when people want to move a binary tree it is so that they can distribute it to other users who may not have cmake in which case this would not work even if cmake would detect the move.
The workaround is to create a new build tree without copying or moving the old one.
그러니까 얘네의 의도는, 빌드 환경은 CMake를 이용하여 각자 셋업하고, 소스 저장소에는 순수하게 소스만 넣어두라는 거겠죠. 이런 정책이 마음에 드는 분들도 계실지도 모르지만, 일부 라이브러리는 CMake를 이용하고 일부 라이브러리는 CMake를 이용하지 않는 시나리오에서는 빌드 환경을 구성하기 위한 관리의 복잡도가 매우! 상승하게 됩니다. 그리고 Windows에서 개발하게 되면 아마도 대부분 저런 경우에 해당하게 될 거에요. 저는 이게 아주 마음에 안 들어요.
제가 개인적으로 진행하는 프로젝트에 사용하던 GLFW라는 라이브러리가 있는데, 이게 메이저 버전업을 하면서 CMake를 사용하도록 바뀌었군요. 이걸 CMake 없이 빌드 하도록 수동으로 풀어줘야 할 것 같은데, 이게 뭐하는 짓인가 싶네요.
댓글 없음:
댓글 쓰기