Webinar Recording: CLion Ask Me Anything Session

On May 7, we ran an exciting CLion Ask Me Anything session. 2 hours, 9 speakers, 7 demos, and 140+ questions – this was really inspiring and motivating for the team and hopefully useful for all attendees. The most frequent comment afterwards from the team members was, “Let’s do this again!”. We’d also like to say huge thanks for all your compliments and good wishes in the questions pane!

The recording of the webinar is now available on the JetBrainsTV YouTube channel. And here are some useful timestamps so you can instantly jump to any section:

  • C++ language support

    • 02:29 – The evolution of the language engines in CLion.
    • 05:16 – Handling preprocessor code.
    • 09:00 – Plans for Qt support.
    • 15:30 – Code analysis tools in CLion, how to add support for more, and if/when CLion will support the C++ Code Guidelines rules.
    • 18:57 – What are the plans for C++20 support?
    • 19:55 – Does the CLion team participate in the C++ Committee Meetings and what are your goals there?
  • 22:04 – CLion performance tips
  • Project model support
    • 27:08 – Makefiles prototype demo.
    • 34:36 – Other project models (Meson, Bazel). What are the plans? How to workaround via the compilation database?
  • Debugger
    • 42:24 – Debugger Tips & Tricks demo.
    • 52:13 – How to limit the debugger to “just my code”?
    • 56:22 – CLion plans for CUDA debugger, reverse debugging, and cross-language debug.
  • Remote development with CLion
    • 01:02:01 – Remote development with CLion – short demo.
    • 01:10:48 – Setting a project inside Docker container for remote development.
    • 01:20:18 – What are the plans for more native Docker support? What are the plans for optimizing performance of the remote development features in CLion?
  • Embedded development with CLion
    • 01:23:45 – A short demo of working with the Arduino boards in CLion.
    • 01:34:55 – What about improvements to debugging experience for the embedded targets, for example viewing the peripherals?
  • 01:38:25 – Working with CTest in CLion
  • 01:46:21 – General questions and final links.

Most interesting questions from the session

50+ questions were asked during registration, and 80+ came online. There were many duplicates, which made us realize that a few key topics required more attention from our side. We handled the questions during the webinar and followed up on some by email afterwards. Still, there are a few questions worth mentioning here, along with the answers.

Q: Template and generic programming debugging can be a pain compared to standard programming. Any tips to improve error/exception visibility and verbosity?
A: We can recommend a couple of tools here: Metashell and Templight. In the future, we plan to get some of these tools or some similar approaches integrated natively into CLion (CPP-4745).

Q: What would you recommend for improving CLion’s performance on my project?
A: Please check these Performance Tuning Tips from our webhelp. With any particular issue, please contact our support (clion-support@jetbrains.com) or file a detailed report in our tracker.

Q: Any plans for native support for Meson?
A: No clear plans for now (CPP-4926), but you can open Meson projects in CLion via compilation database (see this short instruction).

Q: What are your plans for more native Docker support? Not over ssh but just using Docker exec to perform Docker commands with mapped drives and no rsync.
A: First of all, there’s a feature request you can follow for updates and comments – CPP-13751. The great news is that we are considering making these improvements as soon as possible. However, there are lots of open questions and interesting implementation challenges.
For example when we build the project model and collect compiler information (header roots, defines, compiler features, all the stuff that’s needed for correct code assistance), we may run the compiler thousands of times. For docker exec this means that for each compiler call, we have to start the docker container, execute the command… and repeat it again and again (start, execute), thousands of times. So the question is, how does the performance of the direct ssh connection compare to docker exec? We still need to investigate this.
And while we agree that project files synchronization is not needed, it’s not clear what we should do with the header roots inside the docker container.
Finally, we’d like to say that some preliminary support might come to CLion as soon as in v2020.2 or v2020.3.

Q: What are your plans for improving the performance of remote development in CLion?
A: The performance of building the CMake model is the most painful step right now (CPP-14984). This happens because the "Reloading CMake Project" step does not just run remote CMake, but it also includes processing CMake output and collecting compiler information (tons of remote compiler calls). So the plan is to reduce the number of remote process calls while collection compiler information. Other fixes include:

  • Do not transfer unnecessary (binary) build artefacts to the local machine (CPP-15095).
  • Improvements to remote project file transfer speed (CPP-14365, CPP-15396).

Q: Do you have any plans to integrate CTest into CLion?
A: We do not plan to directly support CTest at this time. The reason is that CTest pretty much duplicates the functionality of CLion run configurations. This is how you can use CTest via CLion’s built-in Run/Debug configurations:

  1. Open Run | Edit Configurations…
  2. Create a new one using the CMake Application template. Rename it to CTest, for example.
  3. Select All Targets in the Target field.
  4. For the Executable, do Select Other and find ctest executable.
  5. Define Working directory as macro $CMakeCurrentBuildDir$.
  6. You are all set. Simply run the newly created configuration.

Please see the webinar recording for the demo (01:38:25).

Q: How do I set up reversible debugging in CLion?
A: CLion currently doesn’t provide this feature out of the box, but you can set up reversible debugging with the Undo plugin. Please read this blog post and watch this live webinar recording for the details.

Q: How are Conan / package managers supported in CLion?
A: While no native support exists for now, there is a nice plugin from JFrog to integrate some Conan workflow into CLion. Check out this blog post for a quick start.

Q: Is there a guide for getting started with CLion plugin development?
A: Sure: https://www.jetbrains.org/intellij/sdk/docs/intro/welcome.html. Feel free to direct to us any questions you might have.


Your CLion team
The Drive to Develop

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

21 Responses to Webinar Recording: CLion Ask Me Anything Session

  1. Taw says:

    Great article, great summary with timelines, thanks Anastasia.

  2. Jin Rui says:

    The GDB remote debug is good for use,but i want to use LLDB Remote Debug,is’t in your road map?

  3. Roman says:

    > We do not plan to directly support CTest at this time. The reason is that CTest pretty much duplicates the functionality of CLion run configurations.

    Do you propose to replace CTest with Clion run configurations, and run Clion in CI?

    Demonstrated solution makes no sense to me. Proper integration should allow to launch any test in debugger. (Currently I have to duplicate each CTest with a Clion run configuration manually.) However CTest does not have a large market share, so ROI for you is questionable…

    > How to limit the debugger to “just my code”?
    Demonstrated solution does not work with std::function :( What is really needed is something like this: https://devblogs.microsoft.com/cppblog/improving-the-debugging-experience-for-stdfunction/
    Hopefully, you can solve this with LLDB for Windows improvements.

    • Anastasia Kazakova says:

      Regarding CTest, we do not suggest replace the CTest completely with CLion, but while working on your machine in the IDE you can actually use run the tests via CTest using the workaround. I don’t say this is an ideal solution and some native integration would be better for sure, but for now, it’s not obvious for us how to integrate it properly.

    • Eldar Abusalimov says:

      Yeah, that wouldn’t work with std::function/invoke indeed, unfortunately. Thanks for the link, we should consider handling these as special cases.

      • Roman says:

        I was told that std:: function support is implemented in last macos. Can you check if this can be ported to Linux/windows?

        • Eldar Abusalimov says:

          Yeah, it’s implemented in LLDB for libc++, which is the default on macOS. It’s not available for GDB though. We’ll check if it’s possible to contribute that functionality to GDB, or to workaround that on the CLion side.

          • Roman says:

            I’m not very interested in gdb tbh, since its very slow. lldb for libstc++ is needed.

  4. Taw says:

    I watched parts of the seminar and I have some question:

    1. What are the languages used to create CLion (what parts and how much percent is java, c++, etc)

    2. Why is the CLion team so small? Everything seem “one man job”(ex: only Eldar on Debugger) and there are some areas with many bugs and needed features/improvements.
    For example, I love CLion, it’s very smart, but the Debugger is miles away from VS, especially on nice details. (some examples: CPP-14655 CPP-13954 IDEA-195290 IDEA-195289)


    • Anastasia Kazakova says:

      1. There are lot’s of languages used:
      IntelliJ Paltform which CLion is based on is Java and Kotlin.
      CLion own language engine is Java
      Clangd-based engine is C++
      Debugger has C++, Python, Java and Kotlin code used for the integration

      2. All teams in JB are that small) Mostly, because it’s really hard to hire new people. So if you know someone who would like to join the team, we’ll be glad to learn!

      BTW, Eldar is no longer alone on debugger 😉

      • Eldar Abusalimov says:

        Hi Taw,

        I’d say our team is relatively large, comparing to other IntelliJ-based IDEs. The only IntelliJ teams larger than ours are PyCharm (but that’s really 3 products) and IDEA, the boundaries of which are really blurred anyway.

        • Taw says:

          Thanks, maybe you can give some hints to the IDEA team to fix some embarrassing problems like IDEA-143972, after 5 years IDEA products cannot remember that setting. Is that hard to fix?


          • Anastasia Kazakova says:

            We understand your emotions here, but unfortunately, there are quite many “small” things like that, each of which requires some implementation, testing, reviewing, etc. I mean it anyway takes time, so we have to prioritize the queue. Thank you for pinging us in the ticket again, hope that helps to increase the priority.

          • Taw says:

            I understand, but I think that no simple bug(we both know that is just remembering a flag) should be 5 years old.

            Maybe JetBrains should stop adding new features and new products for a while. They said on Twitter that they released a new product(smth like Jira) but on the bug tracker I counted tens of thousands of bugs and requests…it’s like hiding the dirt under the carpet.

          • Anastasia Kazakova says:

            We are more focused on fixing issues now than adding new features. However, the lack of some features is sometimes even more critical than some bugs. It just depends on the case. As for the new products, it’s a completely different thing and team, not sure it has something in common with the process of fixing bugs in IntelliJ Platform.
            But the thing is that we definitely should check this bug, it’s true. We’ll do our best, thanks.

  5. Roman says:

    On performance side: As suggested, I use “mark directory as excluded” to make Clion usable. But it is still 3-4 minutes to open a project. By comparison : if I generate solution from same CMakeLists and open in in VS2019, VS starts in 4 seconds. So hopefully you have a goal to speedup opening projects 100x.

    • Anastasia Kazakova says:

      Do you have the latest snapshots for this submitted to our tracker? We’ll check the out

      • Roman says:

        Added to CPP-6621.
        I think first thing you need to do, is stop scanning files not included into CMakeLists.txt. I think this is where Visual Studio has most of advantage, it only scans files included in solution.

      • Roman says:

        In a “Building Symbols” stage, do you scan only included in CMakeLists?

Leave a Reply

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