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

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!

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.

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

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.

Done: https://youtrack.jetbrains.com/issue/CPP-10620

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?

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

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.  

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.

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.

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!

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

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

Adding

include_directories(SYSTEM ./src)

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

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?

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

`-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.

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`).

> 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       

$ 

```

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.

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 

Similar here with a ns-3 project. 

Open as Makefile project: can successfully configure toolchain/compiling/building/execution/debugging, However, cannot recognize the header files.

Open as compilation database project: can successfully read the header files. But cannot find a way configuring the toolchain/building/debugging.

Current workaround: Open the project as two separate projects at the same time, one as Makefile project A, and another as Compilation database project B. Use project B to write the code and use project A to build, run, and debug. 

Same here with remote compile in a Debian Buster Docker container with Clang 11.

#include <sstream>

Always claims that the fail doens not exist, while the project compiles successfull. Other headers, like QString work.

Addint the location to CMakeList.txt did not help.

include_directories(SYSTEM inc/ shared/include /usr/include/c++/8/ )

I am having the exact same issue as Uri and Zirui using CLion 2021.3.2 (Build #CL-213.6461.75):

• I have a makefile project that uses the SFML libraries (headers located in `/usr/local/include`)
• Building and running the program work fine, as does manually running `make`
• Parsing any of the files does not work and the "Problems" tab has errors such as "SFML/Graphics.hpp not found"

My makefile is:

CFLAGS = -Wall -Wextra -std=c++17
LIBS = -lsfml-graphics -lsfml-window -lsfml-system -lsfml-audio
SRC_FILES = src/*.cpp

all: bin/myprogram

bin/myprogram: $(SRC_FILES)
   g++ $(SRC_FILES) $(CFLAGS) -Isrc $(LIBS) -o bin/myprogram

.PHONY: clean

clean:
   rm -rf bin/myprogram

I have tried the "Clean and Reload Makefile Project" action as well as restarting CLion, but the issue still occurs. At one point I got it to work correctly (no idea how) but after closing and re-opening CLion it stopped working again.

Also, the issue Uri created above (CPP-25519) does not appear to exist anymore.

The syntax highlighting in my above post gave me an idea and I managed to resolve the issue. The problem seems to be caused by CLion not understanding the wildcard in `SRC_FILES = src/*.cpp` (even though `make` understands it fine).

I replaced this line with `SRC_FILES = $(wildcard src/*.cpp)` and after performing a "Clean and Reload Makefile Project", everything worked as expected.

Perhaps there could be some sort of warning when CLion doesn't understand something in the Makefile?

Daniel Gibbs, thank you for your feedback. The issue you're talking about is CPP-22630.

We can't easily implement the fix as we don't evaluate shell commands, nor do we expand shell wildcards.

The workaround, just as you said, is to use the $(wildcard) function if that's possible. 

Feel free to file new issues at our bug tracker and share your projects (privately, if you prefer so).

CPP-25519 is not available to you as it's a private issue.