CLion 2018.2 EAP automatically treats included files as project files

Hi,

A new CLion 2018.2 EAP (build 182.3341.14) is now available! Download a fresh build from our site, or get it via a patch-update (will be available shortly in case you are using the previous EAP build). You can also update via Toolbox app or snap packages (in case of Ubuntu).

No license is required and the build is free to use, but it will expire within 30 days of the build date.

Download CLion 2018.2 EAP

CLion provides a full code insight (including the project-wide code analysis, a plenty of refactorings, an instant navigation) inside the project files, whereas non-project files are served with limited code insight. For a long time, from the v1.0 files not listed directly in the CMake files were not considered as project files. This caused some inconveniences as, for example, header files are rarely included this way, and in many cases it’s not required for successfully building the project.

Now, if you include the header or source file into any project file, CLion will automatically treat it as a project file as well, which means full code insight will work in there! (Mind, this works only if the file is located under the project root, so it won’t affect standard or 3rd party libraries located outside of the project)

auto_include

Note, there are still some cases where this doesn’t help like CPP-11340 and CPP-13351.

Full release notes are available by the link.

Your CLion Team
JetBrains
The Drive to Develop

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

9 Responses to CLion 2018.2 EAP automatically treats included files as project files

  1. Tano says:

    “Now, if you include the header or source file into any project file, CLion will automatically treat it as a project file as well, which means full code insight will work in there!”

    I thought that in CMake you are not forced to include headers in the SRCS, therefore it should be treated as “project file” by default.

    • Anastasia Kazakova says:

      You can compile w/o listing the header files as SRCS in CMake, that’s true. However, CMake won’t list them as project files if you ask. THat’s why we required to point to headers explicitly before this EAP. Now CLion can handle it automatically, if the header file was used via #include directive in one of the project file.

      • Tano says:

        Oki then, I will test this feature, because it sounds cool.
        Also I hope in the near future you can improve the debugger, only I opened like 7 bugs on debugger (5 this month), it really needs improvement. thanks

      • Tano says:

        Also CLion is impotent when dealing with big library includes like curl and openssl. See how “nice” is CPP-13461, I have a lot of problems with big includes, the only solution is to manually refresh CMake at 10 seconds.

        • Anastasia Kazakova says:

          What do you mean saying “refresh CMake”? Reload? Do you mean you make changes and do not reload CMake and then have such issues?
          Also will it be possible to get a sample project to reproduce?

          • Tano says:

            Very simple scenario: I declare a simple variable and 2-3 lines below that variable is not resolved.
            If I reload CMake project, it works.
            See my gifs in CPP-13356
            Sorry no sample project yet, but I think I can emulate it with any sample project conaning openssl and curl.

            I opened the 8th bug on debugger, I really hope that CPP-13480 is my fault…because it worked great in 2018.1.

            Thanks Anastasia.:)

          • Anastasia Kazakova says:

            I see. But I’m afraid w/o a sample to reproduce we can’t do anything about it. We failed to reproduce on our side. Maybe you can try to reproduce on some toy project that you can share? Not sure what’s going on there for you… Smth definitely goes wrong, but we have no idea how it happens.

  2. Vlad says:

    automatically treats included files as project files – Is this leads that reactoring will also refactor such files (refactoring of standard or 3-rd party libs is not cool )?

    • Anastasia Kazakova says:

      Maybe the text was not accurate, let me explain:
      1. If the file is located under the project root, then yes, it will be treated as project file and refactoring will work there.
      2. If not (and that’s the case for many standard/3rd party libraries), it won’t be included as a project file.
      If you still want to avoid refactoring in case 1, you can Mark Directory as Library files manually.

Leave a Reply

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