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.
Please sign in to leave a comment.
I hope this helps.
In my CMakeLists.txt I tried
But still the line
is grayed out and GoTo Definition / Declaration doesn't work. When I change that to
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
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
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:
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
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
```
test_api: test_api.o
$(CXX) -o $@ $< $(LDFLAGS) $(LIBS)
```
```
test_api: test_api.o
```
Anyway, none of the above would prevent CLion from opening your project.
Four questions:
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.
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.
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.
I am having the exact same issue as Uri and Zirui using CLion 2021.3.2 (Build #CL-213.6461.75):
My makefile is:
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.