CLion fails to find some of my headers. Where does it search for them?

CLion searches through the same places CMake does. Set the include_directories variable in CMake to provide the headers path to the IDE. More details on CMake configuration can be found in our Quick CMake Tutorial.

Since CLion 1.5 EAP there is also a new feature ‘Mark Directory As’ that allows to mark directories as:

  • Excluded
  • Libraries
  • Project sources and headers

Read more about use cases and details in our blog.

 

 

21 comments
Comment actions Permalink

I hope this helps.

cmake_minimum_required(VERSION 3.6)
project(untitled)

set(CMAKE_CXX_STANDARD 11)

#Set your directories. The dot representes the root application folder.
#Thus my the path to my domain folder:
set(APP_DOMAIN ./domain)
set(APP_CALC ./calc)

#Include the directories and now your cpp files will recognize your headers
include_directories(${APP_DOMAIN})
include_directories(${APP_CALC})

set(
SOURCE_FILES
main.cpp
${APP_DOMAIN}/person.h
${APP_DOMAIN}/person.cpp
${APP_CALC}/add.h
${APP_CALC}/add.cpp
)
add_executable(untitled ${SOURCE_FILES})

#CHEARS!
2
Comment actions Permalink

In my CMakeLists.txt I tried 

include_directories( ./src )

But still the line

#include <module.h>

is grayed out and GoTo Definition / Declaration doesn't work. When I change that to 

#include "module.h"

it does work as the .cpp file is in the same folder as the header. But I'm not allowed to use "". How do I make CLion find my headers included with #include <> ? Any help would be greatly appreciated.

0
Comment actions Permalink

I have the same issue: my header files are included as #include <xxx.h> and they are not recognised and all my struct definitions are red

I have included 

include_directories( ./src/include )
which is where my header files are
0
Comment actions Permalink

We can't reproduce the problem on our side. Could you please file a bug report and attach an isolated sample project?

Thanks in advance.

0
Comment actions Permalink

I have a project which builds inside an "SDK" in chroot environment. Project CMake build system is designed to be used from inside the SDK. I managed to build the project by specifying CMake from inside the SDK in CLion->Settings->Build,->Toolchains.

Problem is that build is working now, but proper indexing is not. CMake cache contains paths to includes relative to the SDK root. It makes make happy, but CLion can't resolve them.

Question is if there is any CLion configuration file where I can specify include paths for indexing?

0
Comment actions Permalink

V Krikun, could you please describe your configuration (and if possible, attach the generated cmake files) in CPP-2519?

 

0
Comment actions Permalink

In the case of opening an existing codebase, it would have been nice to mention here to use File > Import Project and follow the dialogs to have CLion automatically build the CMakeLists.txt.  Then magically I have a 6 page CMakeLists.txt that I never would have figured out on my own.  

0
Comment actions Permalink

I had a similar issue. My header files included with #include <...> were not recognized. I tried

include_directories(./lib)

but with no luck. After some hours of research, I found a post with a hint to try the SYSTEM flag in include_directories. This solved my problem:

include_directories(SYSTEM ./lib)

Until then, all headers were recognized.

4
Comment actions Permalink

I'd just like to add something; I was having this issue on a project copied from a different machine (same OS, Ubuntu 18.04) even though my include directories were correct. To fix it, I added the SYSTEM tag as above. However, removing the SYSTEM tag afterwards has no effect; everything still works. So clearly, CLion or CMake is caching something somewhere, and adding the SYSTEM tag causes that cache to be reset and regenerated.

0
Comment actions Permalink

I just had a similar phenomenon using CLion 2019.1.2

I had added cpp files to a pure c project. That caused inspections on the file not to work correctly.

Thus, two bugs that lead to the phenomenon:

* it defaults to adding cpp instead of c files in pure c projects

* the inspections don't really get that the cpp files need to be ignored, as cmake does.

That's it, the include mechanism and the inspections for proper c files all work just fine, these two together create the inspection issue.

Cheers!

0
Comment actions Permalink

Right click on the project, select `Reload Cmake Project` fixed my problem

1
Comment actions Permalink

If you use the remote mode, try Resync header search paths (https://www.jetbrains.com/help/clion/remote-projects-support.html#resync )

2
Comment actions Permalink

Adding

include_directories(SYSTEM ./src)

solved the problem for me. Pretty weird I've to say.

0
Comment actions Permalink

The above was for CMake. I have a Makefile C++ project with the same problem - unable to tell CLion where to look for the header files.

How can I do that?

0
Comment actions Permalink

For Makefile, `-I<dir>` should work

0
Comment actions Permalink

`-I<dir>` works splendidly in the Makefile itself. So, actions like `make all` and such work fine.

But CLion remains ignorant of that, and fails to locate the headers. Which, of course, interferes with editing, static analysis, etc.

0
Comment actions Permalink

Uri Blumenthal, some Makefile projects explicitly set `MAKEFLAGS` (or, alternatively, `GNUMAKEFLAGS`), overriding the default values. In this case, whatever Make flags CLion requests from the command line are ignored, so whenever we run `make -wnk` in order to analyse the project structure, we don't receive the expected output.

Once notable example are Kbuild projects (Linux kernel, Qemu, etc.), which need to be analysed with verbose flag set (`make -wnk V=1`).

If yours is not a Kbuild project, you can try and add `-e` (`--environment-overrides`, give variables taken from the environment precedence over variables from makefiles) to your command-line Make flags (`make -ewnk`).

Alternatively, you can share your project with us, and we'll try to locate the issue ourselves.

As a bare minimum, please clean your project (`make clean`), run `make -wnk` in the project directory and save and share its output (`make -wnk >make.log`).

Edited by Andrey Shcheglov
0
Comment actions Permalink

> some Makefile projects explicitly set `MAKEFLAGS` (or, alternatively, `GNUMAKEFLAGS`), overriding the default values

Nothing like that in this case.

Just a small C++ Makefile project, with two .cpp files and two executables built from each of them. One of those C++ files requires `pistache` package that is currently missing. Both require `openabe` package that is present. My complaint is about inability to locate headers for `openabe` that reside in `/opt/local/include`.

```

$ make clean

Package libpistache was not found in the pkg-config search path.

Perhaps you should add the directory containing `libpistache.pc'

to the PKG_CONFIG_PATH environment variable

No package 'libpistache' found

Package libpistache was not found in the pkg-config search path.

Perhaps you should add the directory containing `libpistache.pc'

to the PKG_CONFIG_PATH environment variable

No package 'libpistache' found

rm -rf *.o *.dSYM test_api attributeAuthority

$ make -wnk

make: Entering directory '/Users/ur20980/src/security'

Package libpistache was not found in the pkg-config search path.

Perhaps you should add the directory containing `libpistache.pc'

to the PKG_CONFIG_PATH environment variable

No package 'libpistache' found

Package libpistache was not found in the pkg-config search path.

Perhaps you should add the directory containing `libpistache.pc'

to the PKG_CONFIG_PATH environment variable

No package 'libpistache' found

clang++ -I/opt/local/include -march=native -pthread -Wall -g -O2 -DSSL_LIB_INIT -I/opt/local/include -std=c++14   -c -o test_api.o test_api.cpp

clang++ -o test_api test_api.cpp -I/opt/local/include -march=native -pthread -Wall -g -O2 -DSSL_LIB_INIT -I/opt/local/include -std=c++14 -L/opt/local/lib -lcrypto -lrelic -lrelic_ec -lopenabe

clang++ -I/opt/local/include -march=native -pthread -Wall -g -O2 -DSSL_LIB_INIT -I/opt/local/include -std=c++14   -c -o attributeAuthority.o attributeAuthority.cpp

clang++ -o attributeAuthority attributeAuthority.cpp -I/opt/local/include -march=native -pthread -Wall -g -O2 -DSSL_LIB_INIT -I/opt/local/include -std=c++14 -L/opt/local/lib -lcrypto -lrelic -lrelic_ec -lopenabe

make: Leaving directory '/Users/ur20980/src/security'

$

$ cat Makefile

#include Makefile.common

 

.PHONY: all

 

INCDIR ?= /opt/local/include

LIBDIR ?= /opt/local/lib

 

CXXFLAGS := $(CXX11FLAGS) $(OS_CXXFLAGS) -pthread -Wall -g -O2 -DSSL_LIB_INIT -I$(INCDIR) -std=c++14

#LDFLAGS := -L/usr/local/lib -Wl,-rpath='/usr/local/lib64',-rpath='/usr/local/lib'

LDFLAGS := -L$(LIBDIR)

LIBS := -lcrypto -lrelic -lrelic_ec -lopenabe

 

CXXFLAGS += $(shell pkg-config --cflags libpistache)

LDFLAGS += $(shell pkg-config --libs libpistache)

 

all: test_api attributeAuthority

 

test_api: test_api.o

$(CXX) -o test_api test_api.cpp $(CXXFLAGS) $(LDFLAGS) $(LIBS)

 

attributeAuthority: attributeAuthority.o

$(CXX) -o attributeAuthority attributeAuthority.cpp $(CXXFLAGS) $(LDFLAGS) $(LIBS)

 

clean:

rm -rf *.o *.dSYM test_api attributeAuthority

$ exa

attributeAuthority.cpp  compile_commands.json  include   Makefile.common  README.md  test_api.cpp

client.py               deps                   Makefile  rapidjson        root       

$ 

```

0
Comment actions Permalink

Uri Blumenthal, I've re-created your project (using dummy OpenABE headers in /opt/local/include) and CLion opened the project w/o a single warning, with the headers being fully resolvable.

BTW, there's an issue with your Makefile: each source file gets compiled twice, so you probably should either

  • stop listing test_api.o and attributeAuthority.o as target pre-requisites (since you're manually compiling them anyway), or
  • compile using the implicit rules and only link explicitly:
    ```
    test_api: test_api.o
            $(CXX) -o $@ $< $(LDFLAGS) $(LIBS)
    ```
  • or, finally, compile and link implicitly (rename LIBS to LDLIBS):
    ```
    test_api: test_api.o
    ```

Anyway, none of the above would prevent CLion from opening your project.

Four questions:

  1. Is /opt/local/include readable and does it indeed contain OpenABE headers?
  2. If you #include any of the standard headers into your source files (stdio.h, stdint.h, etc.) -- can you navigate to those standard headers from a Makefile project opened in CLion?
  3. Can you share the output of Show Compiler Info action for each of your source files?
  4. Finally, can you open the project as a compilation database project in CLion (open compile_commands.json instead of the Makefile)? Are you experiencing the same problems then?

In order to facilitate communication, may I suggest that you proceed to our bug tracker, file and issue and assign it to me? We'll continue from where we left off then.

Edited by Andrey Shcheglov
0
Comment actions Permalink
  1. Yes, of course.
  2. This is a C++ project, but CLion navigated fine to <string> standard header file.
  3. If CLion was kind enough to offer Show Compiler Info option anywhere, I'd be happy to share it's output. As it is, however, CLion is not that cooperative.
  4. No, closing the Makefile project and opening compile_commands.json "as a project" seems to enable finding the header files.

Re. creating a bug entry in the tracker - sure.

Re. assigning it to you - no such luck (see the attached screenshot).

Here it is: https://youtrack.jetbrains.com/issue/CPP-22519 

0

Please sign in to leave a comment.

Have more questions?

Submit a request