Imported projects don't resolve include paths in intellisense

When I create an imported project and generate for MSVC, the include paths are specified with additional options <AdditionalOptions>/external:I "/path/to/my/external/"</AdditionalOptions>, which then doesn’t allow intellisense to find the imported headers. On the contrary, interface targets generate <AdditionalIncludeDirectories>path/to/my/external/</AdditionalIncludeDirectories>, which do work with intellisense.

Is there a way to achieve an imported target that specifies AdditionalIncludeDirectories instead, so that our intellisense can work?

PS - Editing MSVC.cmake and removing the lines about CMAKE_INCLUDE_SYSTEM_FLAG_ have exactly the effect I’m looking for. I wonder if it should also be conditional on a policy? Using CMake 3.24.0.

PPS - the following solved my problem near the top of my CMakeLists.txt file:
unset(CMAKE_INCLUDE_SYSTEM_FLAG_CXX)
unset(_CMAKE_INCLUDE_SYSTEM_FLAG_CXX_WARNING)

What versions of CMake, MSVC, and Visual Studio are involved here?

cmake 3.24.0
Microsoft Visual Studio 16.11.30
MSVC 19.29.30152.0

Hrm. It looks like this was added in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7238. I suspect that IntelliSense needs to learn about how to use these flags, but maybe an option could be added?

Cc: @brad.king

Yes, that sure looks the the right MR. I’ve been looking for some documentation from MS that relates to /external:I and the behavior of intellisense, but no luck. I presume MS’s intent was that that headers in external include paths don’t show up in intellisense? I’m still playing with visual studio settings to see if I can find a workaround on the MS side of the equation.

I’ve been through both project and IDE options lists with respect to external libraries and intellisense, and I can find no way to instruct intellisense that it should process external libraries.

There are two workarounds I’ve been able to succeed with:

  1. Unset CMAKE_INCLUDE_SYSTEM_FLAG_CXX and _CMAKE_INCLUDE_SYSTEM_FLAG_CXX_WARNING near the top of my CMakeLists.txt, which effectively negates MR 7238 cited above, or
  2. Add the same path that appears in /external:I again in the normal include paths via /I.

I can see use cases for MR 7238, but being unconditionally railroaded into that new behavior is a breaking change for my project. I’d like to see the ability to turn it off either wholesale, or for specific imported projects. In the meantime, I have these workarounds.

FWIW, tooling around the compiler is not generally considered when implementing features. For example, clang-cl did not understand -external:I when first added, so clangd-based tooling choked on the flag when we first implemented the MSVC support and the flags showed up in the compile_commands.json files. Note that there might be some leeway here given how tightly integrated IntelliSense is to Visual Studio, but I think the core problem is that IntelliSense doesn’t understand the flags that the target compiler supports. I suggest at least contacting Microsoft to handle this regardless of how CMake ends up resolving this.

I tried the Microsoft documentation project here: Impacts on intellisense/autocomplete? · Issue #4769 · MicrosoftDocs/cpp-docs · GitHub, but your prompting caused me to look one more time and I found what looks like a fix from MS: Developer Community. I intend to give it a shot and let you know how it turns out.

As advertised in the link above, Microsoft fixed this problem in VS 2022. I also confirmed that its not fixed in VS 2019 (Version 17.6.4) , nor do I suspect they will go back and fix VS 2019.