“We found that CMake was the tool that better fit our needs: It created project files for all development environments we used, was easily extensible with its own scripting language, provided cross-platform commands to copy and delete files and directories, and was easy to deploy on our Jenkins nodes…CMake, CTest, and CDash have proven to be invaluable tools for us to build multiplatform code, track changes, run tests, and improve code quality by performing code coverage and memory leak analysis.”


The HDF Group

“In the past, we used a combination of Microsoft Visual Studio project files and custom scripts to build and test the HDF libraries and tools on Windows. With the growing demand for HDF software on Windows, it became clear that we could not support our software with the variety of compilers and configurations our users requested. Sharing and examining daily regression test results on Windows was another problem we had to resolve. CMake, CTest, and CDash were the tools that we desperately needed. With the help of our user community, we added the CMake build system for all HDF products. We rely on CMake for HDF software being successfully built and tested on platforms that range from supercomputers to Windows desktops and tablets. The flexibility built into CTest and CDash enables us to build and test HDF products with GNU Autotools – another build system we support. Cross-platform Make will be part of cross-platform HDF for many years to come!”



“I am thankful for CMake’s shadow builds feature. For a project like SOFA, which has many optional features and possible option combinations, being able to quickly test a modification on several typical setups on my machine before pushing a significant change to the repository is a very valuable security. This is especially true for a complex project like ours.”



“In the C/C++ ecosystem, the best tool for project configuration is CMake. CMake allows [you] to specify the build of a project in files named CmakeLists.txt with a simple syntax (it is simpler than writing Makefiles). From those files it can generate projects for the most popular IDEs and build systems in different OS. It is a must have tool. It is the de-facto standard in the industry for the C/C++ multiplatform and even for single OS development. We love it. We have used it for a long time in our own projects, and, as professors, we have taught it from the first day in our Software Engineering courses at university.”



Users since 2011

“ReactOS went through a number of different build systems in its history starting with plain makefiles before rolling an inhouse solution called RBuild. Eventually however the project outgrew RBuild and in early 2010 a decision was made to look for a third party solution instead of continuing to expend time and effort maintaining RBuild. CMake was an early favorite and while the transition was not without its bumps, it has allowed the project to not only increase the number of compilers that could be used to build ReactOS, it also set the stage for significantly decreasing build times, making development faster and easier.”



Users since 2006

“Our working relationship aside, CMake has greatly improved the process of building KDE. Projects using CMake take less time to get started, since there is less time spent fighting with the build system. One KDE developer says, “CMake doesn’t make you want to shoot yourself with a nailgun when building your project anymore.”


Apache QPid

Users since 2009

Maintaining multiple build inputs is a royal pain. And at least one of them is always out of step. Keeping Visual Studio projects and autotools-based files updated is very error-prone. Even the subset of developers that have ready access to both can get it wrong…We looked at a number of alternatives and settled on CMake. Read more on why and how Apache QPid switched to CMake.


Second Life

Users since 2008

“A great technology choice that our community helped us make was moving to CMake, a cross-platform build tool, which makes it much simpler to maintain makefiles for many different platforms.”


Australian Centre for Field Robotics

Users since 2000

These tools provide us with the ability to manage a development environment that is cross-platform, supports code reuse, and is responsive to change.



Users since 2006

Good integration with the popular IDEs (Visual Studio, Xcode, Eclipse CDT, KDevelop). Developing in an IDE makes the development process more enjoyable, and potentially it lowers the barrier for external contributors. Of course, CMake can generate traditional Unix Makefiles, which appear to be are superior to the ones generated by GNU autotools (for example, they have progress indicators, colored output and working dependencies). Read more.



Users since 2006

The first CMakeLists.txt file entered one of our repositories in April 2006 with the commit message “CMake, for easier Windows distribution” (this was clearly the perspective of a Linux developer tired of dealing with Windows). After some experimentation, doubts, and dabbling with alternatives, it became clear that CMake was a huge win. It gave a first-class experience to MSVC users when compiling projects developed by Linux users, and vice versa. Most of the time, developers could now forget about any development environment other than their own, and our community became a lot less “balkanized”.


ASPEED Software

Users since 2006

“ASPEED’s SDK supports a wide range of platforms and languages, and CMake fit the bill perfectly for our build and release cycle. It works for Visual Studio IDE development, and it works from the command line under either Windows (nmake) or Linux. It works for FORTRAN as well as C++. It’s an enormous time-saver, allowing us to quickly develop applications for multiple platforms. This in turn has allowed us to build, test and release software more frequently, giving us a market advantage.” (Mike Dalessio, Head of Development, ASPEED Software)



BusinessWeek — June 17, 2009

“I started to develop on a project on Linux OS in C++ language on 3 January 2005, and I had never written from scratch any files, nor used autoconf tools seriously before. So since one of my task was to create the building process for the whole project, I had 2 choices: learn and use autoconf, or search in Internet for an alternative. The one day research ended up in, which is an easy but very powerful tool, which allowed me to achieve all I wanted to do (debug/release/profile compilations, compilation based on the developer name, easily maintainable and customizable compilation of many shared/static libraries and applications), and which has a very fast learning curve, exactly what a projet need to achieve its aim in short time.” (Luca Cappa)