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