Dogfooding CLion

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 team all the time. TeamCity, YouTrack, etc. And starting recently, we’ve been seeing CLion users inside the company!

JetBrains Toolbox app – what’s that?

JetBrains Toolbox app helps you manage all your developer tools from JetBrains, taking care of installing new versions, cleaning up old ones, getting updates, or rolling back. You can follow release-only channels or participate in EAPs as you prefer.

The app is especially helpful if you use several IDEs from JetBrains, or if you participate in Early Access Programs and installing EAP builds side by side with stable versions of some of our IDEs. It simplifies the update process by getting updates silently in just one click, so you don’t waste any time on the installation/patching process. JetBrains Toolbox can also aggregate all your projects and select an IDE that suits each of your projects for you.
toolbox_ides toolbox_prj

The JetBrains Toolbox Google Chrome extension also makes is possible to open GitHub projects inside a JetBrains tool in a single click:
chrome_extension

Technologies behind JetBrains Toolbox app

On the client side, JetBrains Toolbox app is a native Qt-based application, which includes an embedded browser (Qt WebEngine based on Blink) to show you a web page and keeps a tray icon. The UI in the browser is done with React/Redux and ES6, while Webpack is used to pack all this functionality.

Native App at client side

The native application is written in C++ (C++11) and uses the Qt platform. CMake was selected as the build system for this cross-platform app. As many other C++ cross-platform developers, the Toolbox team chose CMake as a universal build tool. Some reasons why they chose CMake:

  • They use CPack for building some installers.
  • CMake provides built-in options for Qt (resources generation, AUTOMOC, and others).
  • The choice made it possible to use CLion for the development.
  • On Windows, those who prefer MSVC compiler can use it as well with Visual Studio (and ReSharper C++).
  • There are macOS parts done in Objective-C/C++ too.

For testing, the team was initially using QTest provided by Qt, but later moved to Google Test. This was done for several reasons.

  • The first being the ability to skip test method declarations. In Google Test, you just implement the test body and that’s it, no need to list the tests in some special class that is later provided to the runner.
  • Another reason was the rich set of assertions available in Google Test.
  • There is also a first-class TeamCity support for Google Test.
  • And last but not least was, obviously, integration with CLion and ReSharper C++.

Server side

All information on available releases for Toolbox is available as a set of files on a static HTTP server. There is no server-side application running for Toolbox app at all. Initially a bare JSON files were used, but soon they added XZ compression and digital signatures.

Finally, there is an application in Kotlin that collects all the data about releases and product builds. The application generates files that are uploaded to a HTTP server that is used by Toolbox.

CLion for Toolbox: the story of effective collaboration

We took this chance to work together and thus improve CLion and want to share here the story of this collaboration.

Introduction: You just open and start

The overall impression we got from the Toolbox team was positive. Without a broad experience in C++, CMake or Qt, they were quite happy with the easy start that CLion gave them. “You just open it and go!” they said. That was really a promising description.

Another benefit was that many of the technologies they were going to use were supported in CLion out of the box. Apart from C++ itself, the CMake project model and the Qt libraries, they found support for Client Side JavaScript helpful. The ability to work with everything you need in one tool always makes you more productive, as you don’t need to switch all the time.

The indexing of the project took several minutes, but when the index was ready, CLion started quickly.

There was some negative feedback as well. And that’s a good thing. I mean, who could be fairer and more straightforward than your own colleagues? We have their open and constructive feedback to thank for collecting and fixing a number of important issues in CLion.

First story: Qt connect & variadic templates

The Toolbox team used Qt and especially Qt C++11 connect calls widely, which made their code red and full of warnings before we implemented variadic templates. Starting from v2016.1, CLion can handle the following code correctly:
variadics

The implementation took some time and affected lots of code all around the parser. At that stage we were really scared of the idea of putting all the changes to the upcoming release and even EAP build. So we first provided the Toolbox team with a private build that they were evaluated for about a week. That let us work on implementation performance and regressions introduced there. Only after that did we make the changes available to all, inside the public EAP build. Some additional problems were found, but the major performance issues were eliminated at the first stage.

Speaking of performance, in addition to the variadic implementation testing and some debugger issues investigations (the latter were helpful when working on GDB/LLDB drivers changes introduced in 2016.2), Toolbox developers faced high CPU usage problems which are still under investigation.

Second story: digging in compiler and CMake output

There were some complaints about the compiler and CMake output in CLion. When you are new to the technology, excessive logging may confuse, especially when it’s not well-structured.

Some users want to have colored output, some on the contrary prefer to keep away from so many colors. CLion can provide a solution for both sides. The coloring control is implemented via the original CMake/compiler options:

  • CMake coloring can be disabled by setting CMAKE_COLOR_MAKEFILE to OFF,
  • for Clang, add -fno-color-diagnostics compiler flag,
  • and for GCC, add -fno-diagnostics-color flag.

Almost all of our users (and Toolbox team is not an exception here) want to see CMake output when (re)loading the project. We understand the importance of that and we did have feature planned for 2016.2. Unfortunately, we were unable to deliver it in the July release, but it will become available soon in one of 2016.2.x updates.

Third story: Darcula perfectionism

Another issue was noticed by the Darcula-theme fans. Some colors and icons look bad, as not polished. Here we were actually quite lucky, since the problems were caught by the developer who introduced Darcula to IntelliJ Platform. With his help, we came up with a much more accurate and nice-looking theme.

Ask for more

Our tracker is always open for any feature requests our users have in mind. The Toolbox team addressed some interesting cases in their feedback. Check them out and upvote if you miss them too!

Google Test

After moving to Google Test from QTest, the Toobox team started using CLion’s integration and made lots of interesting suggestions. Some of them came from their experience in the Java world and using IntelliJ IDEA. A prime example would be gutter icons for tests, like it’s done for JUnit. We are going to consider this, as well as other Google-Test-related reports from the Toolbox team.

Swift & Objective-C/C++

Toolbox app got some Objective-C/C++ code in addition to C++, and Swift is being considered as a possible addition. Of course, they may generate Xcode project from CMake and open it in AppCode, but that didn’t look good to them (especially since the project is cross-platform).

The team was excited to learn the news about the Swift plugin for CLion. As for Objective-C, there is a feature request placed in our tracker (and even some interesting hack from one of our users). But in general, this makes us think again that Objective-C/C++ can be a useful addition to the world of cross-platform C/C++ development. So, if you would like to see Objective-C/C++ support in CLion, do let us know in the corresponding ticket.

Visual C++ compiler

MSVC support on Windows: I’m afraid we have little to comment a lot here. We are thinking about adding it, but we lack the resources to do it at this time.

Who’s next?

We hope that more teams will adopt CLion and share their feedback with us. Recently, we’ve helped our UI team that is customizing the JDK for our IntelliJ-based IDEs, and now they can also try CLion for their development. If you’ve ever wanted to use CLion for OpenJDK dev, please check this patch (intended for Linux environment only).

We’ll be glad to hear your feedback as well! Give CLion a try and let us know what you think.

Your CLion Team

JetBrains
The Drive to Develop

This entry was posted in Backstage and tagged , . Bookmark the permalink.

5 Responses to Dogfooding CLion

  1. A Dev says:

    That is a nice app, and nice idea to test your IDE in a real project rather than just unit tests

    It shows you what it is lacking, or what feature to add

    Congrats!

  2. Даниил Водопьян says:

    Why wasn’t ToolBox build with Java? Was it because it must not require JRE to run?

  3. Tom - Henry Coursow says:

    +1 Vote for Visual C++ compiler :)

Leave a Reply to Anastasia Kazakova Cancel reply

Your email address will not be published. Required fields are marked *