intellisense not working for project headers

[fvannee]

Please use the following bug reporting template to help produce actionable and reproducible issues:

• A brief description
  Intellisense fails to recognize .h includes. Suppose we have the following directory structure:
  a
  ...a1
  .......a1.h
  ........a1.cpp
  .......CMakeLists.txt
  ...a2
  ......a2.h
  .......a2.cpp
  .......CMakeLists.txt

a1 is a library, CMakeLists.txt in that directory specifies:
target_include_directories(a1 INTERFACE ..)

a2 is an executable. CMakeLists.txt in that directory specifies a dependency on a1 by target_link_libraries.
a2 includes a1.h by #include <a1/a1.h>.

• Expected results
  Intellisense recognizes the include file.

• Actual results (with build output window contents if applicable)
  Intellisense does not recognize the include file.
  It does however recognize include files like #include <a1.h> directly, without prefixing with the directory a1.
  CMake runs OK remotely. Build also OK.

• VC++ version, Linux system name and version, GCC/GDB/gdbserver version, CPU arch, etc. If you are using a specific version of Linux on an embedded board, we might need to know about it to get a repro on similar hardware
  VS2017.5 preview, ubuntu 17.04, GCC6, CMake 3.9

• Steps required to reproduce the error
  See above.

• Required packages and commands to install

[iwubcode]

I too am running into this issue, or a very similar issue with Visual Studio 2017 15.4. I have a single project (library) and specified all my file includes like #include <my/path/to/include> which does not show up in intellisense.

Additionally, other external libs I'm referencing includes from do not show up either.

I think 'CMake' should be added to the title.

---

EDIT: On further investigation, my bug makes sense. Since VSLinux doesn't have a way to pull includes from the remote box, includes don't work when targetting Linux.

However, if I change my cmake target to Windows, I'm able to view all includes. It'd be nice if we could somehow use the CppProperties to inherit the Linux includes from the Windows CMake build, then everything would work fine. For now, I can just switch between the two manually.

[robotdad]

Seems very related to our need to start syncing headers as described in #215 . @itodirel can you please take a look to make sure this behavior is expected in the current cmake implementation? It seems a bit weird.

[fvannee]

I'm still experiencing the same issue with the latest version - has there been any update on this?
Using "" or <> doesn't make a difference. It really seems to be related to the fact that Intellisense (target extraction) thinks the header files are on top-level (which is why #include <a1.h> works) rather than on subdirectory level. It seems to completely disregard the target_include_directories command, which tells it to look one directory up

[svenbieg]

I've found a workaround for this. You have to add $(SolutionDir) and $(ProjectDir) to $(IncludePath) Not $(AdditionalIncludeDirectories), then IntelliSense recognises the project-files! For the compiler You have to add '-iquote "projects/$(SolutionName)" -iquote "projects/$(SolutionName)/$(ProjectName)". Then You can include Your project-files using quotes "" and slashes /!

[fvannee]

It's not possible to change IncludePath directly for CMake projects, right? Because these only have the CMake files and one small CMakeSettings.json. Or is there another way to change this variable? I tried it with specifying a CppProperties.json but that one also seems to be completely ignored.

…

On Thu, Jan 3, 2019, 16:40 Sven Bieg ***@***.*** wrote: I've found a workaround for this. You have to add $(SolutionDir) and $(ProjectDir) to $(IncludePath) instead of $(AdditionalIncludeDirectories), then IntelliSense recognises the project-files! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#195 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNwxUKRCaM-6StVO3tdF4dt3pZaeLgFks5u_iRugaJpZM4P4GLP> .

[itodirel]

Hi, there was a bug in this that we just fixed, target_include_directories will absolutely work with the bug fix, it was a bug that it didn't work before, currently we are expecting a full remote path in there, could you tell me if you use relative paths?

[fvannee]

Yes, relative, as in the example from my first post - the target include directory includes .. - its parent directory. target_include_directories(a1 INTERFACE ..) So, that's why further includes to that library are done as a1/a1.h (dir name from the parent plus header file name)

…

-Floris

On Thu, Jan 3, 2019, 19:54 Ion Todirel ***@***.*** wrote: Hi, there was a bug in this that we just fixed, target_include_directories will absolutely work with the bug fix, it was a bug that it didn't work before, currently we are expecting a full remote path in there, could you tell me if you use relative paths? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#195 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNwxXHHT0E4sEjt0X1Ftidk_B2ptQPqks5u_lHJgaJpZM4P4GLP> .

[fvannee]

@itodirel Does 'just fixed' mean that it's in any (preview) release already or that it's still in testing?
In case it's useful - attached is a minimal example that shows the issue. For a local (Windows) config, Intellisense works fine. For a remote Linux config, the include in main.cpp is not recognized by Intellisense. It builds fine in either case.
CMakeProject1.zip

[fvannee]

@itodirel any update on when it'll be available?

[fvannee]

I just tried my previously attached example (CMakeProject1.zip) with the latest release of VS 2019 Preview 2.1. It has definitely not been fixed - the problem is exactly the same as with any other release of VS.

[fvannee]

@itodirel if not fixing the issue, can you at least remove the 'fixed' label from the issue on github, as it has not been fixed yet?

[danielmrussell]

I'm having similar issues but I am confused whether it's the same. I have done this:

`# Project Root Cmake
cmake_minimum_required(VERSION 3.12.1)
cmake_policy(
VERSION 3.12.1
)
project(
my_exec
VERSION 0.0.1.0
DESCRIPTION "Stuff"
LANGUAGES
"CXX"
)

add_subdirectory("my_interface_lib")
add_subdirectory("extern")
add_subdirectory("my_exec")
`

`# Interface Library Subdir Cmake
add_library(
my_interface_lib
INTERFACE
)

target_include_directories(
my_interface_lib
INTERFACE
include/
)`

Intellisense not working at all for #include < or " :(

[fvannee]

hi @danielmrussell - that's quite possibly the same. Microsoft abandoned this site for issue tracking though. Could you please upvote if you want to indicate to Microsoft that this is an issue?
https://developercommunity.visualstudio.com/content/problem/485138/intellisense-not-working-for-cmake-remote-linux-co.html
https://developercommunity.visualstudio.com/content/problem/392131/intellisense-fails-to-find-headers-outside-system.html

[itodirel]

This issue is being tracked with a feedback ticket, and it has been fixed.

We have retired this issue list, here on Github. We now adopted and are using the Developer Community (https://developercommunity.visualstudio.com/spaces/62/index.html), for Cross Plat and Linux experiences (and C++ all up generally), which we are actively monitoring. Please use the Developer Community, to report issues or suggestions for bugs or new experiences. Further discussions on this thread here on Github might be unmonitored. If there is further comments or context to this current issue, please create a new issue on the Developer Community, and provide the context there. For any existing issues, which we can or able to reproduce, or for anything that is actionable to us and understood, we will provide an update right here in this thread. Additionally, for new suggestions or new issues, which at this time are in our roadmap, or for which we believe and have evidence that broadly and/or significantly benefit everyone, we will open a suggestion ticket, and link it here. For anything else, we recommend to please open a ticket on the Developer Community. That isn't because we will not look at the problem, or not investigate it otherwise, but simply because we need additional information. And for features, we are tracking them on the Developer Community.