CMake vs. the others, round 1
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 Blog updates
Dealing with Makefile Projects in CLion: Status Update
Update: Makefile projects support is now public in CLion 2020.2. What request in our tracker has more than 1000 votes, 370 comments, and 800 watchers? You guessed it: Support Makefile projects. This has been a story of interesting findings, semi-automatic workarounds, and a long battle that we st…
We at JetBrains know about dogfooding. We practice it daily to close the distance to our users, so we can understand their needs, feel their pains and problems. IntelliJ IDEA has been dogfooded ever since JetBrains existed. WebStorm and its web development technologies are being used by our web t…
CLion in 2015: A Review of Feature Usage
Hi everyone, CLion IDE was released to the public in April 2015, and now may be a good time to look back and see how things have developed (no pun intended). We published a similar overview within six weeks of the launch of the first public CLion EAP (Early Access Program). At that time we wer…
Applying Genetic Algorithms to Automatic Code Formatting
Our traditional JetBrains Hackathon was held this summer at our St. Petersburg and Munich locations. Earlier we shared the first impressions and quick overview of the winning projects in our company blog. Today we’d like to tell you about one of the projects that came in third in more detail. Why do…