From Autotools to CMake

Jun 21, 2021 · 2 minute read

Since my paper on GPU benchmarking was published, every once in a while, I got emails asking me why Altis doesn’t build on their platforms. It almost always has something to do a small script which is responsible for finding CUDA dependencies. This script is invoked every single time make is executed. For some reason, the regular expression in the script sometimes breaks randomly, depending on the Linux distro, the kernel version, the host architecture, or even the CUDA version. After enough requests piled up in my inbox, I decided enough is enough and it’s time to ditch the autotools shenanigans for CMake.

When I started this project, it already had a skeleton build system based on autotools. The old build system generates automake and autoconf files. It worked fine for me on the server I used so I never bothered to make big adjustments. However, the problem soon arises when I upgrade some packages or switched to another server in our lab.

Because our servers are constantly being used for GPU research, the execution environment is constantly changing. Sometimes the benchmark suite would build in the morning and stop working in the afternoon because of a CUDA downgrade. My directories were filed with strange files like configure.ac, Makefile.am, Makefile.in, … It also uses a helper script called M4 which I still don’t quite understand. Hand-made shell scripts are everywhere. automake has a million versions and you’ll never know why it doesn’t build on someone else’s OS. Getting OptiX to work is like having a constipation because the LD flag doesn’t get placed in the right location.

Switching to CMake was a lot smoother than I anticipated. I took about two days to rewrite the entire build system from scratch. Contrary to autotools, CMake’s syntax is easier to learn. The terminal output is easier to read by default, instead of throwing every single detail to my face. And, it’s colored! Debugging build issues no longer takes multiple hours.

Perhaps the best part is, since CMake 3.8, CUDA is natively supported. Compiling .cu files is as easy as adding CUDA as the project’s LANGUAGES. That alone should be the reason to use CMake if there’s anything CUDA related. The only caveat is there’s a small difference between how CMake handle CUDA architecture flags in different versions. Since CMake 3.16, CMAKE_CUDA_ARCHITECTURES is introduced. Older versions still requires find_package(CUDA) to set CUDA compilation flags though.