New CLion 1.1 EAP: project scopes, CMake targets and other changes

The new Early Access build for CLion 1.1 (141.2309) is now available for trying. You can download it and install side-by-side with CLion 1.0. An update from the previous EAP build is also available (not for Windows this time, sorry for that).

The most important changes addressed by this build are project scopes. When you open a project in CLion now, you can notice a couple of changes in project view:

  • All files under your project root are considered by the IDE as project files.
  • Files located under include_directories are the only exception, considered to be library files highlighted with yellow now. They are not considered as files with your project code, so refactorings and other smart features are not applicable there.
    However marking the directory with -iquote makes CLion consider these files as project files. Unfortunately, it’s not supported by CMake for now, and can be propagated through the compiler flags only.

From the practical point it means that Go To Symbol/Class/File navigation actions search symbol/class/file names through the project files by default:
and if you need to include files from libraries (i.e. include_directories paths) into this search, include non-project symbols as well:

In Find in Path dialog you can select a custom scope and switch between Project files, Project and Libraries, etc. and to search through the selected scope.

Other changes include:

  • After massive parser overhaul introduced in the first 1.1 EAP build, we’ve continued our work in that direction, fixing many resolve issues. That leeds to more accurate completion, navigation and refactorings (CPP-3983, CPP-3982, CPP-3981).
  • This build improves the way in which CLion updates CMake targets while creating a new class or file. You can now add files not only to the direct calls of add_executable and others commands like this, but to the appropriate CMake variables as well:
  • A plugin for YAML, famous data serialization standard, was bundled and is on by default in CLion.

Find a full list of fixes in our tracker. Download the EAP build now and give it a try!

Sincerely yours,
The CLion Team

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

34 Responses to New CLion 1.1 EAP: project scopes, CMake targets and other changes

  1. Marcus says:

    New “everything is now in the project” option is a complete bust for me.

    “Search Everywhere” now includes resources, object files, documentation files, libraries for other build types, and a whole host of other stuff. A sea of irrelevant files!

    I guess if scopes worked it wouldn’t be so bad – but at the moment it’s a complete pain.

    • Anastasia Kazakova says:

      Go to Symbol/Class/File, search through the project files by default.
      With Search Everywhere – we’ll check, maybe smth appears there because of some bug. Please, add some sample which files appear there by error here: Please, describe which sections in Search Everywhere you see the irrelevant files in, or add some screenshot for example.

      If you don’t want to login to tracker, share screenshot with us through some dropbox or smth. I’ll attach to the ticket in our tracker.

  2. Anton says:

    Files located under include_directories are the only exception, considered to be library files highlighted with yellow now.
    As far as I understand it, only system include directories (-isystem) should be considered as containing the library (non-project) files. To declare system include directory in CMake one can use include_directories(SYSTEM ) command. Please corect me if I’m wrong.

    • Anastasia Kazakova says:

      There are actually three types of files: system files, libraries, user/project files. If you include Boost headers in your project, for example, it’s libraries files, not system one of course. But you don’t wanna change/refactor your Boost headers at all in the IDE, that’s why libraries are not treated as project files in CLion. They are highlighted with yellow now so that you can separate them easily in the project view and various navigation dialogs, and use these scopes in navigation actions correctly.

      • Anton says:

        And how does CLion decide which file is a “library file”? I’m sorry, but I don’t fully understand your point.
        From my point of view there are two types of header files: system headers and project headers. System headers consists of platform headers and headers from installed libraries (which may include headers of CMake subproject libraries). While project headers are all other headers.
        – System include directories passed to the compiler via the “-isystem path” parameter. On Linux it’s usually the /usr/include directory and several others. One can add additional system include paths (for example to headers of a library, included as a subproject) using “include_directories(SYSTEM path)” as CMake command. Theese headers must be interpreted as read-only and mustn’t be modified by refactoring of course.
        – Project include directories passed to the compiler via “-I path” parameter. All project headers must be writable and included in refactorings.
        The logic is simple: if you want to protect some foreign headers from modification, pass them as system headers. For example, if you have just copied some headers from boost directly to your project files, then it’s your fault if they will be modified by refactoring. To protect foreign headers they should be placed in a dedicated directory, which is passed as a system include directory.

        • Anton Makeev says:

          Not sure if this will make the change appear less dramatic, but keep in mind, that from the beginning CLion treated include_directories as library files. The only thing that have changed is the color in the project view that clarifies how CLion sees the project.

          Answering the question about system/user files:
          currently, the only way for CLion to automatically distinguish project files from non-project files is to rely on the compiler option. CLion follows GCC rules, where -I are system/library headers and -iquote are user headers.
          -isystem is a completely different story.

          It’s completely understandable, that the current scheme doesn’t support all possible project layouts, and we do plan to add some control over how CLion treats specific directories.

          For now, we decided to make things more clear for the developers (coloring header search paths in the project view), so they could at least understand, why some files are treated differently than the others.

          If you have any specific layout that doesn’t work for you and could be improved, an example in the issue tracker will help us better understand it.

  3. KB says:

    Because I use a single repository for all of my source code, I have a large number of third-party C++ source trees under my project root. These are mixed with non-third-party, project source. It would be nice if these were not treated as project files.

    • KB says:

      Also, if a CMakeLists.txt file contains multiple targets, and some depend on others, those targets will be erroneously marked as library files when those projects’ paths are also the include directories of parent projects.

      • Anton Makeev says:

        KB, thanks for the cases, could you please file tickets in the tracker so we could discuss the problems in details?

  4. Sidney Just says:

    The all files are considered project files is terrible. Please add an option to turn that off, my workspace is cluttered with temp files and unrelated options that I simply don’t want to have considered when searching all files. Plus, I have projects with multiple targets that depend on each other so they naturally have include paths set to each other and now half of the project is considered a header search path only. What were you guys thinking?!

    • Sidney Just says:

      *Unrelated resource files, not options, sorry. I don’t want to come off as an ass, sorry, I really like CLion, especially the previous EAP. But this EAP is a huge step back in usability for me and I really hope this becomes optional soon.

    • Anastasia Kazakova says:

      As Anton mentioned above, we are planning to add some control over how CLion treats specific directories. Also any specific resource file type can be excluded from the project once and for all in Settings | Editor | File Types | Ignore Files and Folders.

      Moreover CLion treated include_directories as library files from very beginning. We just made it clear in the editor now, cleaning things up. However we understand it may look inconvenient for now, especially in some cases like yours. We’ll see what we can do here. Thanks for the feedback.

  5. Olof says:

    I have experimented with the -iquote option but I am unable to get my project includes to be considered project directories. I might be doing it entirely wrongly and in the wrong place.

    The actual source files are somehow figured out to be project files but since the directories are yellow I feel it is misleading and I would like to get that sorted out.

    • Anastasia Kazakova says:

      Could you please show some sample how you were using it and your prj structure or any sample prj?

      • Olof says:

        Our project structure has a reponame/src and a reponame/test directory in the root.

        Under those we have our source folder hierarchy and our unit test source hierarchy respectively. All our includes assume that our own include files are located in either root/reponame/src or root/reponame/test and we have those two directories in include_directories.

        That might not be the right way. I’m not a cmake expert.

        Thanks a bunch for the help.

        • Anastasia Kazakova says:

          And how do you use the -iquote?
          You see the problem is that CMake doesn’t support the option, so you probably are using it as some compiler flag.

          • Olof says:

            I tried using it as a compiler flag and in the include_directories similar to how one uses SYSTEM hoping cmake would pass it through since it didn’t recognize it. But I’m really just flailing.

            If you have examples it might help me figure it out. Googling for -iquote and cmake for examples of workarounds yields little.

          • Anastasia Kazakova says:

            You actually need to remove your include_directories and change them to smth like:
            set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} -iquote ${PROJECT_SOURCE_DIR}/headers_dir”)

            You’ll be able to use includes from this dir then.

          • Olof says:

            OK, that’s great. Thank you very much.

          • Olof says:

            It appears that my problem is with the -iquote command line option. I ran make with VERBOSE=1 and that gives me the exact command line used. If I manually edit that command line and replace the -isystem with -iquote my header files are no longer found.

            I am also able to now use cmake to produce the right build options after your tip, so thanks for that. But if there is an issue with my gcc (4.7.2) itself that makes the -iquote not work then I still have a problem. Maybe I’m doing something wrong. Will look into it a bit more.

          • Anastasia Kazakova says:

            Ok I see, let us know the results.

          • Olof says:

            Problem identified. We had some of our own header files included using


            instead of



        • Olof says:

          After a short while we discovered that when we use the -iquote workaround above changes to our header files aren’t always picked up. This may be due to something in our environment, but the work-around I’m having to use is to set the highlight color to white (it didn’t seem to work to remove the color entry as it came back after a restart).

          • Anastasia Kazakova says:

            Do you save a copy of the color scheme and save it for future usage? Do you mean it’s not applied after the restart?

  6. Olof says:

    I’ve used it both as a flag to gcc and in the include_directories similar to SYSTEM in the hope that it would just be passed through since it wasn’t recognized.

    As part of the gcc flags I just used it as -iquote reponame/src -iquote reponame/test
    But maybe I need a ${CMAKE_SOURCE_DIR} or something like that.

    I’m really just flailing.

    • Anastasia Kazakova says:

      First, -iqoute needs a full path, not a relative one. Second, -iqoute is not supported in CMake, so no way to pass to include_directories, only with the GCC flags, and since you’ve marked your code with include_directories, CLion recognizes them as library files.

      However, looks like you are mixing the terms a bit. All the files under the project root are project files. Except for the directories marked and include_directories – they are libraries and marked with yellow. If you don’t include them with include_directories and just use -iqoute, they’ll be simply greyed out, not yellow, so project files (because located under the project root) and not libraries. Is it what you want?

  7. Werner Dittmann says:

    Just testing CLion and tried to change the build output directory. This seems to work if I select “Run” to run an executable, for example a test program. CLion seem to ignore this setting if I just select ‘Build’. In this case all output goes to some CLion config sub-directory.

    That’s annoying if the project is a library project that does not build executables, only shared or static libs. Any idea about how to change this? I already changes CMakeFiles.txt to include ‘set(CMAKE_RUNTIME_OUTPUT_DIRECTORY “my_dir”)’, however didn’t help.

    • Anastasia Kazakova says:

      You can set the build output directory in Settings > Build, Execution, Deployment > CMake > Build output path. CMake command will still be run in the internal directory, but the final artefacts will be copied to the directory you’ve set.

      If you need to change where the built binaries will be located, you can also use CMAKE_RUNTIME_OUTPUT_DIRECTORY, and CLion will not ignore that. However, it is not possible to change the actual directory used during build (where scripts and intermediate object files are located), as I’ve said before. The last thing is discussed here:

      • Werner Dittmann says:

        Thanks for clarifying this. I missed the issue that CLion copies it into the “Debug” or “Release” sub-folder inside the actual “build” folder. Now I just need to find a way that CLion copies the artefacts directly to the ‘build’ folder or I need to change my supporting shell scripts.

        • Anastasia Kazakova says:

          I’m afraid it’s not possible now to copy directly to the build folder.

          • Werner Dittmann says:

            No big issue – need to change a few scripts, that’s it mainly :-) .

            Otherwise IMHO CLion is just as nice as IDEA and makes C++ programming much easier. Currently I’m using KDevelop which is OK, however CLion is a real leap forward.

            Thanks for your support.

          • Anastasia Kazakova says:

            You are welcome and really glad to hear such feedback!

Leave a Reply

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