CMake vs. the others, round 1
Hey everyone,
Yesterday we’ve published a new EAP build that allows opening non-CMake projects automatically; although this functionality is very basic and isn’t intended to recreate the full project description, it will help some of you try CLion on existing projects.
Today, we would like to share our thoughts on CMake with you and explain why we opted for it as a main project format.
When we were only planning a C++ IDE we had two options: either to invent our own build system or to reuse an existing one. For us the choice was obvious, since we wanted the IDE to be easily used with existing projects, we chose to go with some existing project format – a new one would inevitably hinder adoption; it would also require so much more work and definitely delay the release.
Having this in mind we looked for possible candidates for a build system; the criteria were popularity, maturity, availability on various platforms, ease of automation/integration in the IDE. I bet you can guess what the options were: make, Autotools, CMake, qmake.
Our brief research showed that CMake and ‘make’ were the most popular cross-platform tools, having ~30% of users each, while both Autotools and qmake had less than 7% of users. So we ended up with CMake and make; and at that point the ease of integration played the major role. If we chose ‘make’, we would have to write our own interpreter or devise smart tricks to get necessary project information from it. With CMake it proved pretty simple to get all we want, since during generation CMake produces lots of easily-parseable internal files containing vital info. Another advantage of CMake was its platform-independence – almost everything we needed is described in universal terms in CMake.
Yet another benefit, is that CMake is not a build system in the general meaning and doesn’t lock its users on one particular build system: users are free to use make/Ninja/etc to actually build the products; and that’s a huge advantage since neither build tool is suitable in all situations. Having projects description in CMake also allows the users to easily switch between IDEs.
Don’t get us wrong here, we are not trying to say that CMake is the best and the only tool and everyone should use it. These are, rather, our considerations that explain the choice. As we wrote earlier, we do plan to extend build tools support in future, but not very soon – it requires significant time, since every tool has its hidden peculiarities and challenges. For now we will focus on improving CMake support.
Meanwhile, take a look at the ‘Import Project from Sources’ feature and if you have suggestions, we are always here for a discussion.
Till next time,
The CLion Team
Subscribe to CLion Blog updates
