Ping 14/Aug/2020

Meson-ABC 갖고 놀아본 코드

아주 예전에 commercially 성공적이었었던 C++ 프로젝트를 홀로 기획, 설계, 개발했었었다.

처음에는 GNU Makefile으로 간단히 시작했었었다. 타겟 플랫폼이 뻔하게 윈도였기 때문이다.

그 이전에는 ANSI C으로 작성한 SDL 조합형 비트맵 출력 오픈소스 라이브러리 같은 것들을 작업할 때는 그냥 GNU Autotools 을 쓰거나 했었었다.

하지만 그렇게 configure 하거나 할 부분도 없고 처음 혼자 시작하며 다른 신경 쓸 것도 무지하게 많았었던 프로젝트였고 더욱이 기간도 한정적이었었다.¹

그리고 SCons 같은 것을 조금 쓰다가, 결국 더 간단히 Rake으로 빌드를 작성해 한동안 썼었다.

어차피 루비 스크립트였기 때문에 자유도도 높고 Configure 같은 기능들도 그냥 스크립트으로 작성해버리면 그만이었을테니까.

그러다가 몇 년 정도 그 프로젝트가 성장하고 하면서 CMake으로 빌드를 다시 작성하고 재밌는 경험이었었다. 처음 CMake을 배워서 진지하게 적용했었었다.

그 이후로 C++을 할 일은 별로 없었지만 개인적으로 작성할 때마다 CMake은 좋은 도구였다. 그리고 Conan, CPM, ExternalProject 같은 외부 의존성을 가져오고 빌드하는 등의 확장들도 많아서 C/C++ 특유의 문화를 살리면서 프로젝트를 만들어가기 좋은 것 같았다.

하지만 잡다한 부분도 많고 튜링완전하기 때문에 자유롭지만 이상한 부분도 있었었다. 정신을 조금 차려보면 이해하기 어려운 cmake 스크립트가 쌓여가는 것을 볼 수 있었었다. 어차피 빌드스크립트야 어느 시점이 넘어가면 그런 것들을 먹고 가주는 역할이 필요하기는 하지만 가끔은 너무 번거로운 것은 아닌가 싶었다.

그에 비해서 Meson을 익히고, 작은 프로젝트를 납득할만한 수준으로 작성하면서 만들어봤다. 딱 좋은 도구라는 생각이 들었다.

WrapDB 같은 것을 통해서 기존에 Meson으로 작성되지 않은 프로젝트들도 의존성으로 쉽게 사용할 수 있고 일관된 방법으로 의존성들을 간단히 관리하는 것이 좋았다.

특히 "Modern CMake" 혹은 "CMake Best Practices" 같은 것들이 이야기하고 빌다시피하며 지켜주길 바라는 것들을 그냥 자연스럽게 그 자체로서 구현해놓아서 굳이 그걸 깨뜨릴 이유가 없는 시스템이어서 좋았다.

그리고 제한적이지만 원하는 configure 같은 것들을 다 수용할만한 정도여서 고민되지는 않았다.

다른 언어들을 쓰면서 cargo, go get 같은 것들이 부럽기도 하고 했지만 C/C++은 그 나름을 유지하면서 이런 좋은 도구들이 실은 알아가면 더 즐겁게 해주는 것 같다.

그리고 내가 좋아하는 방식으로 일하고 쌓아가는데 적합한 도구가 되어서 좋다. 다른 최근에 적용한 도구 중에 이렇게 프로젝트를 관리하는 방식이 나는 좋은 것 같다.