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:
What versions of CMake, MSVC, and Visual Studio are involved here?
Microsoft Visual Studio 16.11.30
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?
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:
_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 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.