CMake는 여전히 자신의 임무를 모른다.

CMake는 점점 더 C++에 대한 나쁜 솔루션이라고 느껴진다. C++ 개발자의 요구에 부응하지 못할 뿐만아니라, 일관성 없는 언어로 매우 불분명하고 구조화되지 않은 방식으로 makefile을 빌드하는 암흑기에 머무르게 한다.

문제

C++ 빌드 세계에는 두 가지 유형의 문제가 있다.

1. 기존 프로젝트가 스스로 만든 문제 (역주: 이미 존재하는 커다란 프로젝트를 빌드하는 문제)
2. C++에서 새 프로젝트를 선택할 때 겪는 문제

CMake는 첫 번째 문제를 해결하려고 노력하며, 두 번째 문제는 전혀 해결하지 못한다. 하지만 이러한 문제를 해결하려 하지 않기 때문에 덜 유용한 도구가 되고있다.

CMake는 프로젝트 정의를 빌드 시스템으로 번역하는 번역자가 되고 싶어하며, 이 부분에서 심하게 실패했다. 나쁜 프로젝트 정의 언어이며, 일관성이 없고 직관적이지 않다.

C++ 커뮤니티의 모두는 이제 Rust의 도구들에 대해 이야기한다. Cargo는 대부분의 개발자가 필요하다고 생각하는것을 실제로 수행하기 때문이다. Cargo는 인터넷에서 종속성을 다운로드하여 격리된 툴킷을 만들고(나쁜 생각이지만), 정적으로 링크된 라이브러리를 제공한다(역시 나쁜생각이지만). 사람들은 엄청난 속도로 보안 구멍을 추가하는 도구를 필요로 하진 않지만(역주: 저자는 Cargo의 인터넷에서 자동으로 코드를 받아와 링크하는 방식이 보안 측면에서 공급망 공격과 같은 취약점이 된다고 주장합니다. I Hate Rust 참조.), Cargo가 실제로 제공하는것은 필요하다:

1. 매우 엄격한 프로젝트 구조
2. 라이브러리가 어디에 있는지에 대한 문제를 해결하기 위해 외부 서버에 의존하는 매우 간단한 구성 시스템
3. 단 하나 의 도구집합.

사람들은 실제로 작업에 집중할 수 있도록 더 작은 자유가 필요하고, 컴파일러를 가장 완벽한 방식으로 호출하는 데 능숙하지 않다.

해결책

아직 해결책은 없다. 여가 시간에 klb를 작성하고 있지만, 지금은 해결책이 아니다. (시간과 돈이 필요하다.)

하지만 사람들이 필요로 하는것이 무엇인지는 분명하다. 더 많은 옵션이 아니라 더 적은 옵션이다. 옵션이 적다는 것은 프로젝트 컴파일을 망칠 수 있는 방법이 적다는 것을 의미한다.

CMake는 지금 C++ 세계에서 여전히 최고의 옵션이지만, 지난 20년 동안 C++에 일어난 최악의 일이기도 하다. 다른 모든 것은 개선되고 있지만 빌드 시스템만 악화되고 있다.