How can I specify additional include files?

Thank you, I will try it.

Same issue here.

AppCode will build correctly, but can't seem to find the include directory:

Richard, is it possible for you to attach the project so that we can investigate the issue? You can send directly to clion-support at jetbrains.com

Project is too big, unfortunately.

I wonder how can the IDE build my project, but symbols can't be found...

I'll try to open in xcode to see if it works there.

Ah! confirmed.
Open project is xcode and is fine:

Richard,

> I wonder how can the IDE build my project, but symbols can't be found...
These things are unrelated. Project is being built by the compiler. And parser by CLion's parser.

However, I'm afraid to investigate the issue we need some sample to reproduce. Maybe you can build a smaller sample demonstrating the issue?

I have a feeling that xcode fixes our generated cmake projects, where as AppCode just loads it up untouched.
This is probably a cmake issue, not AppCode issue.

You can close this.

Hm, do you mean AppCode or CLion? AppCode doesn't support CMake project model at all... I thought it was CLion.

AppCode.

We generate the xcode project using cmake.

Xcode can load that xcode project because it can fix issues

AppCode will load, but won't fix the issues. Includes are not found and the BaseSDK is not set properly.
I think this is a cmake issue regardless.

Hm. I'm not sure how it works. AppCode treat xcode project in the same way as Xcode. Maybe worth reporting the bug to https://youtrack.jetbrains.com/issues/OC, attaching the xcode project you generate from CMake.

Have you also tried opening initial CMake project in CLion? C++ support is the same in CLion/AppCode.

Good idea. I'll give that a shot.

Hm. 

CLion does not seem to understand this construct:

set(DEPS_PREFIX ${CMAKE_BINARY_DIR}/deps)
include_directories(${DEPS_PREFIX}/include/)

CMake builds it correctly, CLion complains about missing headers.

Hi Victor!

A cmake-build-* folder (${CMAKE_BINARY_DIR}) is marked as excluded by default and therefore is not indexed by CLion.

@Anastasia Kazakova, @Anna Falevskaya,

You can reproduce the issue being discussed if you try to build the clang C++ compiler from source.
It builds without errors, but CLion's parser cannot find certain include files. Please take a look at the attached screenshot to see an example.

Hi Mykola!

The thing is that such values as, for example, clang::driver::options::OPT_nostdinc are defined in the Options.inc file which is generated during the build and is included in the Options.h file. But the Options.inc file is generated in the generation folder (cmake-build-*) which is marked as excluded by default and therefore is not indexed by CLion.

If you close the project, copy the Options.inc file from cmake-build-*/tools/clang/include/clang/Driver to, for example, tools/clang/include/clang/Driver and open the project, everything will be ok:

Hello Anna!

Thank you for the response. The explanation makes sense.

While copying generated files makes the parsing errors go away, to me it doesn't really seem to be a practical work-around. Here's why.

1) There are three folders which contain files generated during the build: cmake-build-*/tools/clang/tools/driver, cmake-build-*/tools/clang/include, cmake-build-*/include
There are folders with the same names in the source tree and copying the generated folders in the source tree will mix generated files with normal files and create a mess.

2) I'm not sure if there's a way to include cmake-build-* folder for indexing. But even if there is, just including all these folders isn't good enough -- only the cmake-build-* folder corresponding to the active profile should be included.

I believe, at the end of the day, whatever is configured in CMakeLists.txt should take precedence over any defaults.
Seems like a bug in CLion. Would you agree? If so, should I file an issue? Alternatively, could you please file an issue?

Thank you.
Mykola.

Mykola,

>I believe, at the end of the day, whatever is configured in CMakeLists.txt should take precedence over any defaults.

What do you mean by that? What behavior do you expect from CLion? 

There's a no way to include cmake-build-* folder for indexing. But I believe there is a way to configure the LLVM building process so that files are generated to other folders. I think this is not a question for CLion, it is a question for the project configuration.

Anna,

First, I think a little disclaimer is in order: I'm not an expert on neither clang nor CMake. So I may very well be wrong in my reasoning.
But for what it's worth, here it goes.

>>I believe, at the end of the day, whatever is configured in CMakeLists.txt should take precedence over any defaults.

>What do you mean by that? What behavior do you expect from CLion?

So, my point is: as far as I can tell, CMakeLists.txt specifically adds cmake-build-*/tools/clang/tools/driver, cmake-build-*/tools/clang/include, cmake-build-*/include to the include directories.
For example, take a look at these lines from CMakeLists.txt

307: set(LLVM_INCLUDE_DIR ${CMAKE_CURRENT_BINARY_DIR}/include)
795: include_directories( ${LLVM_INCLUDE_DIR} ${LLVM_MAIN_INCLUDE_DIR})

(Please notice, ${CMAKE_CURRENT_BINARY_DIR}/include is added to the include directories. Where, I believe, CMAKE_CURRENT_BINARY_DIR corresponds to one of the cmake-build-* folders depending on the active profile)

So, given the config snippet above, IMO, cmake-build-*/include should be indexed in spite of the cmake-build-* folder being excluded by default.

>But I believe there is a way to configure the LLVM building process so that files are generated to other folders.

Could you please elaborate on this a little?
If I reconfigure it to generate files into minsizerel instead of cmake-build-minsizerel is the minsizerel folder going to get indexed?

Thank you.

Hi Mykola,

sorry for the confusion. Your scenario should work out of the box, without additional actions.

It looks like an incorrect profile might be picked by the code highlighter (not the one that was built and has headers generated), but I can't reproduce it locally with a similar setup. We'll investigate the problem a bit more internally, and come back to you.

In the meantime, could you please see if changing the CMake profile checkmark under the run configuration changes something (click on "Clang | MinSizeRel" and select another one, wait for re-highlighting of the file, then change it back).

Hi Dmitry,

Thank you for the response.

Yesterday, after reading you can't reproduce the problem, I downloaded a fresh copy of llvm and clang source archives.
Unpacked them and tried to build from CLion. The build passed successfully but the problem with headers was still present.

I tried a number of thing including your suggestions. But what I think eventually made the problem go away was me invoking the "Reload CMake project" action.
Reloading took some time and once it was complete, CLion was able to resolve all the headers and symbols which were previously marked red.

To reiterate, if I want to build clang from a fresh copy of the sources, I should
1) Open the folder in CLion and build the project
2) Once the build is finished, manually trigger the "Reload CMake project" action
3) Once the project reloading is complete, CLion can resolve all the headers and symbols in the code that were previously marked red

Maybe these points deserve to be mentioned in FAQ somewhere.
Anyway, for me personally triggering "Reload CMake project" manually is really no big deal -- figuring out it's necessary took a bit of effort, of course :) But now my issue is solved.

I'll post CLion's about text at the bottom of this comment, just for the record.
In case you're interested in investigating this further and need any additional info, please let me know.

Thank you!

---

CLion 2019.1.4
Build #CL-191.7479.33, built on May 30, 2019
Licensed to CLion Evaluator
Expiration date: August 14, 2019
JRE: 1.8.0_202-release-1483-b53 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

Mykola,

Once again sorry for misleading. And thank you for sharing the results with us!

Unfortunately, I'm not able to reproduce the issue on my side anymore (tried to do everything from the beginning, twice, no luck). If you would like to investigate the situation further and are ready to help, please do the following: reproduce the issue, open the file in which the headers are not found (Options.h, for example), make sure the editor with the file is focused, do Help | Find Action and select Show Compiler Info action there. And send the result to clion-support at jetbrains.com.

Hi JB!

Sorry to resurrect this thread again, but I'm having the same problem with CUDA includes.

I can compile my code, but include files are shown in red.

To reproduce this you can create small cuda program and in *.cu file include <cuda_runtime_api.h>

It will be shown with red underline.

Interesting fact, if I specify full path, it works:

#include </usr/local/cuda-10.1/targets/x86_64-linux/include/cuda_runtime_api.h>

Also I tried to add this path to: include_directories, target_include_directories, CUDA_NVCC_FLAGS, CMAKE_CXX_FLAGS.

I'm ok with any workaround for now.

Andrei,

I just tried with CLion 2019.3 on my Ubuntu 18.04 with CUDA 10.2 (installed as recommended here https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#cross-platform) and includes like <cuda_runtime_api.h> are resolved fine in my *.cu file if I add the following line

include_directories("/usr/local/cuda/include")

Could you please try the same?

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

Thank you. Apparently I haven’t notice the first answer, but eventually it got resolved when CLion started to support cuda. I’m happy now. ^^