CLion 2016.3 EAP: CMake changes and overload resolution

Hi,

Release time is quickly approaching, but we still have lots of goodies to show you. At this stage your feedback is very important and highly appreciated. Share with us in the comments below and/or our tracker. Having said that, we are glad to announce that new CLion 2016.3 EAP, build 163.6957.27, is available now. A patch update will be rolled out shortly for those using the previous EAP (build 163.6512.7).


Download CLion 2016.3 EAP

The most valuable improvements include:

CMake workflow changes

There were lots of discussions around our approach to CMake and how CLion deals with the CMake generation. After considering all the use cases carefully, we’ve decided to reorganize it and incorporate our users’ suggestions. This new approach seems to be more flexible and fits more workflows. The main changes are as follows:

Select generation directory

Previously, users were only allowed to change the directory where the final build artifacts are stored, while the CMake generation directory was set internally by CLion. Now users can provide the path to the preferred generation directory in CMake settings:
generation_folder
By default, if nothing is set, the cmake-build-debug folder will be created in the source tree.

Open project from an existing CMake-generated folder

These changes made it possible to save time on opening projects, for which CMake generation was called already. In addition, it makes possible workflows with switching between building in the shell and building in CLion. You just need to point CLion to the folder that contains CMakeCache.txt, or open CMakeCache.txt file as a project:
open_project

A few things worth noticing here:

  • CLion will suggest opening the corresponding source directory and mark the directory with CMakeCache.txt file as a build directory.
  • If you already opened the corresponding source directory in CLion, project settings (generation folder and selected build configuration) will be updated.
  • At this stage CLion is not able to work with non-Makefiles generator output, so in this case the files will be generated from scratch (for example, if you were using Ninja generator).

Also please note that for now CLion cannot find an existing generation folder on its own.

One configuration at a time

With this EAP, CLion allows only one configuration at a time. So you can select from Debug, Release, RelWithDebInfo, MinSizeRel or any custom configuration in the CMake settings. That makes it impossible to quickly switch between these configurations in the editor to resolve the code in the selected context. However, this approach is aligned with the most popular use case when work is done in Debug mode and Release is used to make final builds. Also, having fewer configurations saves time and memory, which can be quite noticeable for big projects.
configuration

We want to note here that we are still considering a solution that would allow building as many configurations as the user needs, but it’s not going to be ready soon, and not likely before the release of 2016.3. Do share your concerns if you prefer previous approach.

CMake toolwindow and CMake Cache

Finally, CMake tool window was reworked. All tabs are now joined in one, which is easier to use. And if you want to edit CMake Cache, open the file directly in the editor or click the corresponding button in the CMake tool window:
cmake_cache
This removes the limitation on adding CMake Cache variables. Edit the CMakeCache.txt file the way you want  and CLion will catch up on changes.

Overload resolution improvements

Overload resolution is a technique used by C++ compiler to select a candidate for a function or operator to actually call among all the overloaded options. From the IDE perspective, selection of the correct candidate affects code navigation, parameter info, code analysis, refactorings, and more. Previously a lot of false-positives in the code analysis in CLion were caused by errors in overload resolution. Today we are happy to share the results of a big overhaul in CLion in this area. CLion has become smarter and now picks the correct function and operator usages, even in code with templates:
ovr_templates

It also made it possible to introduce two new code inspections:

  • Ambiguous call:
    ambig
  • No matching function to call:
    no_match

This work addresses a huge list of issues from the tracker and most likely a lot of problem not yet even reported to us. Thus we kindly ask you to check the update and log any new problem (with red-code or false analysis) introduced by this build.

CLion and Python

With Python support introduced, there are lots of mixed C/C++/Python projects now being developed in CLion. One of the use cases is Python C extension modules. However, debug used to fail in such case because the PYTHONPATH environment variable was being overwritten by the IDE. Besides, it caused problems in other cases when working with Python in CLion.

Today we are glad to share that this problem has been fixed!

Full release notes are available by the link.


Download CLion 2016.3 EAP

Your CLion Team

JetBrains
The Drive to Develop

This entry was posted in Early Access Preview and tagged , , , , . Bookmark the permalink.

23 Responses to CLion 2016.3 EAP: CMake changes and overload resolution

  1. andrew somerville says:

    It looks like the detailed change log my be for pycharm rather than clion.

    None of the changes mentioned in this blog post show up there, and several from python functionality do show.

  2. Mikhail Evdokimov says:

    Thank you very much for removing those strange things like “putting build dir aside” and “maintaining many build simultaneously”.
    Now CLion works much much faster! And now it is configurable much more easier!

    Now the only missing things:
    * modules as in PyCharm (not as in IDEA, but as in PyCharm) that would allow to load several projects (actually workaround with parent CmakeLists.txt with subdir works, but a little bit inconvenient by forcing all modules be in
    same root dir)
    * ability to specify PYTHONPATH inside Python plugin. Else we are force to run CLion from multiple batch files instead of just link.
    * Remote debugger for Windows.

  3. marco says:

    Thanks a lot for the cmake improvements! Deeply appreciated!

  4. I just checked it on a Windows 10 x64. Works like a charm! – Congratulation and thanks for your work.

  5. Rich Eakin says:

    Thanks for the great cmake advancements! So far it is working quite well. I do like that now it only loads one configuration rather than all, although at the same time a batch build of multiple configurations would be very useful (I’m thinking about Visual Studio’s Batch Build here).

    Wondering a couple things: 1) is it possible to globally set the Generation path for all projects (or at least set the default)? And 2) What is the best way now to reload the CMakeCache.txt back to the defaults?

  6. Alexey Rozhkov says:

    Looks like I’m one of the few ones that don’t appreciate updates regarding CMake. My previous workflow involved frequent switching between debug and release builds, but now it is problematic. Can you give some examples of time and memory savings that new “single configuration” model offers?

    Also, previously I was able to specify CMAKE_RUNTIME_OUTPUT_DIRECTORY_* and CMAKE_LIBRARY_OUTPUT_DIRECTORY_* to make artifact placement consistent between builds from IDE and from terminal, now I have to specify them independently, which can be more error-prone. Is there any way to prevent CLion from overriding build directories?

    • Anastasia Kazakova says:

      Thanks for the feedback.

      Previous workflow includes building all four CMake configurations (Debug, Release, RelWithDebInfo, MinSizeRel) so that you can later quickly switch between them in editor. However, the drawback is that CMake command had to be called 4 times (which was time) and all four configurations were created and stored (which was memory). We’ve got lots of complains on that flow and so decided to rework it since it seemed to us the typical flow our user expect is different. However, we agree that in case of frequent switch current workflow may be problematic.
      Anyway, we’ll consider how to make it possible to get debug and release (so both) at the same time in CLion when user really needs it (like in your case).

      Not sure, I got what changed in behaviour for CMAKE_RUNTIME_OUTPUT_DIRECTORY_* and CMAKE_LIBRARY_OUTPUT_DIRECTORY_* for you. Where were you specifying these parameters?
      Also maybe this request will help you: https://youtrack.jetbrains.com/issue/CPP-7943

    • Matthias Gabriel says:

      Honestly, I see things the same way as you – my workflow involved switching between Release and Debug. While I deeply appreciate the in-tree builds, this is rather limiting. I understand the concerns of memory and time issues.

      Why not pulling out the “build-type selector” next to the “Run/Debug Configuration” on the top-right corner? This way people would be able to switch on the fly. Of course, changing the build type (and therefore the build folder) is expensive in terms of memory and time, but its only for those who need it. I’m sure, users would benefit from such a toolbar button…

  7. Dean Moldovan says:

    I really enjoyed the old CMake workflow since I frequently switch between Debug and Release. There is a need to evaluate performance during development, not just debug. Switching configurations is a bit of a pain now.

    Would it be possible to make this a bit more flexible? If the user could choose how many and which configurations they need, that would be amazing. I imagine the performance and memory requirements would scale with the number of configurations. Having this user-configurable would be a win all around.

    I also really liked that the old system managed the build directory automatically, out of sight. I don’t like the build dir cluttering up my source tree, especially if I need to juggle multiple configuration directories.

    • Anastasia Kazakova says:

      Yes, we are considering making it more flexible with user’s choices which configurations to build. Not sure what are the estimations for it now. However the related request to track is here https://youtrack.jetbrains.com/issue/CPP-3159

      And I agree about in-source build by default. We’ll consider various solutions. Thanks for the input.

  8. Pavel Moravec says:

    I just paid for a new version of CLion and updated to 2016.3. What a surprise that all Run configurations are broken now! When I found the INTENTIONAL change in CMake configurations handling, honestly I was shocked. This change is straight downgrade of the IDE’s functionality, and totally unnecessary too.

    CMake projects can define multiple targets. They can have very different characteristics. This is cool if you have more standalone components for example. Or multiple test sets defined for running with different settings, some performance critical parts etc. It is very common that different build configurations run totally different code because the compiler has different options.

    Then the tool allows its users to create any number of Run Configurations with a possibility to define a tuple (build target, CMake configuration, + some other settings). Again, very useful to allow the combinations – it is handy to just switch run configuration and not to change CMake configuration for any run configuration at all!

    But surprise surprise, one cannot use different CMake configurations in different Run configurations. One has to always select one and only one or have the run configurations broken. Why is the CMake configuration option there in the first place then?? Yes, it was there for a good reason, because is very useful as explained before. Or at least it was useful, when it worked in 2016.2.

    I can understand your motivation. If the product is slow, make it faster, but this is not the way to go. It seem like there’s no one in your company actually using the product for non-trivial stuff because otherwise I cannot imagine how this change could get into the public build.

    What you could do instead is to allow users do disable some CMake modes which are NOT USED by them (not to force them to use just one global). So that you could save your space and time on slow computers or for any other reason.

    Or you could be even more cleaver. The IDE knows all run configurations defined in the project, so it can easily collect all possibly needed CMake configuration. Then it can disable performing ANY actions related to the unused CMake configurations. This can be done even without letting the user know! Plain win for all + no UI changes needed. Or even better you can combine the two approaches and let user constrain the modes manually (if they need it) and then apply the automatic disabling logic.

    Or another improvement. Be more lazy with all the computations and perform actions only for the mode used by the current run configuration. On user change (when run configuration changes), compute what is needed if different CMake mode is needed after the switch. Let the previous CMake configuration be computed for some time too to allow users to switch between run configurations freely without a re-computation penalty. Etc, there is so many better options how to practically disable most of the computations and still don’t interfere with user’s intentions.

    Right now, you’re forcing ALL users to follow some (nicely said) questionable usage pattern. Please, think about it. And ideally, please, please, fix it and make the IDE usable for non-trivial projects again. Thank you.

    • Anastasia Kazakova says:

      Thank you for the feedback. First of all, let me say that we understand your disappointment and really sorry to make you feel that way.

      Yes, we were trying to decrease the CMake running time and solve memory issues removing unnecessary configurations, since many users asked us about this. But looks like the workflow you are describing is critical and so we are planning to update behaviour and add an ability to create additional configurations. To track the progress follow this: https://youtrack.jetbrains.com/issue/CPP-3159

  9. Jonathan says:

    I bought 2016.3, and I can’t find how to revert to building out-of-source to keep the source tree clean without specifying paths for every configuration.

    Is it possible?

    • Anastasia Kazakova says:

      Sure, go to settings (Settings/Preferences | Build, Execution, Deployment | CMake) and configure the generation path there.

  10. Frost Red says:

    I cannot use redirection operator in Program arguments.


    #include
    #include
    using std::ifstream;

    #include

    int main(int argc, char* argv[]) {
    ifstream in(argv[1]);
    std::string line;
    in >> line;

    std::cout << line <> line;
    std::cout << line << std::endl;

    return 0;
    }

    and Program arguments is 1.txt < 2.txt. It cannot print the content of 2.txt.

Leave a Reply

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