Vscode-cmake-tools: Using Clang kit, headers are not found for Intellisense, despite cmake-tools being set as the Configuration Provider

[danielmrussell]

Brief Issue Summary

When switching to the "Clang 8.0.0 for MSVC with Visual Studio Tools 2019 (amd64)" kit, all standard headers fail to be found and create a bevy of squiggles and terrible advice about setting includePath, something that feels really wrong and unmaintable.

My Configuration Provider in cpptools is "vector-of-bool.cmake-tools" as per the instructions right there in their extension.

Cpptools' Windows SDK version setting is set to "10.0.18362.0", which is installed on my system.

Code was run from the x64 Developer Command line, to ensure all MSVC environment variables were properly set. This did not help.

Expected:

1. Switching to Clang kit should have no deleterious effect on Intellisense's ability to find standard headers, which are known to be the same on Windows (the ones that cl.exe uses) since clang does not have its own on Windows.
2. Intellisense should be able to find the Windows SDK headers, (without manually pasting in include paths.)

Apparent Behavior:

Switching to Clang kit makes Intellisense in cpptools unable to find standard headers.

Platform and Versions

• Operating System: Windows
• CMake Version: 3.15
• VSCode Version: 1.37.1 etc.
• CMake Tools Extension Version: 1.1.3
• Cpptools: 0.25.1
• Compiler/Toolchain: Clang 8.0.0.0 for MSVC with Visual Studio Tools 2019 (amd64) kit

[esynr3z]

I've also been suffering this issue recently.

When I set up configuration provider to "vector-of-bool.cmake-tools", Intellisense creates many "#include errors" and suggests me to update "includePath". But my includePath is OK, and all works fine if I set configuration provider to "none".

My "c_cpp_properties.json":

{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "/usr/lib/gcc/x86_64-redhat-linux/8/include",
                "${workspaceFolder}/**"
            ],
            "defines": [],
            "compilerPath": "/usr/bin/gcc",
            "cStandard": "c11",
            "cppStandard": "c++17",
            "intelliSenseMode": "gcc-x64",
            "configurationProvider": "vector-of-bool.cmake-tools"
        }
    ],
    "version": 4
}

Operating System: Linux Fedora 28
CMake Version: 3.14.4
VSCode Version: 1.38.1
CMake Tools Extension Version: 1.1.3
Cpptools: 0.25.1
Compiler/Toolchain: gcc version 8.3.1 20190223 (Red Hat 8.3.1-2) (GCC)

[bobbrow]

@esynr3z this issue is about the Clang integration with Visual Studio and is Windows-specific. If you are having trouble with Linux, please open a new issue with additional details. Thank you!

[danielmrussell]

Actually, the solution was the same for me on Windows. The integration is broken pretty badly. Any chance these two extensions will be integrated or made to work smoothly with each other?

In the meantime, my solution was to set the Configuration Provider to blank as well, and to simply ignore the (apparently erroneous) messages upon starting VS Code of includePath needing to be set (these errors continue even after the workaround).

[wuyuanyi135]

+1.
I switched to VS2015 and the header problem is gone.

[thomthom]

In the meantime, my solution was to set the Configuration Provider to blank as well,

How do you then setup all the C++ settings, if it's not coming from CMakeTools?

I am running into this myself. I had my project set up to use MSVC at first - but switched to Clang on Windows as well to be able to use libFuzzer.

[andreeis]

Until this integration issue is fixed, try to hook the compile_commands.json (which is generated by CMake Tools even if configuration provider is blank) into c_cpp_properties.json. Let us know if that doesn't work for you.

[thomthom]

I'm not sure how exactly one would do that. Some key in c_cpp_properties.json that needs to point to compile_commands.json? Or the content of compile_commands.json needs to be copied into c_cpp_properties.json?

[andreeis]

https://code.visualstudio.com/docs/cpp/c-cpp-properties-schema-reference
Let us know if that doesn't help or if it doesn't work properly for you.

[shogerr]

The following does not work with any of the Clang MSVC 2019 kits when used in workspace settings, including both the community and enterprise releases. CL works fine.

{
    "C_Cpp.default.configurationProvider": "vector-of-bool.cmake-tools",
    "C_Cpp.default.compileCommands": "build/compile_commands.json"
}

The file is found, but completion does not work.

[thomthom]

https://code.visualstudio.com/docs/cpp/c-cpp-properties-schema-reference
Let us know if that doesn't help or if it doesn't work properly for you.

It's still not clear to me what I would need to change. Is it what shogerr is suggesting (which apparently isn't working?)

[shogerr]

Yeah, I came here with the same problem @thomthom. The only solution I've found is to use cl.exe, not clang. Furthermore, this extension has problems finding headers for CMake projects that use Vcpkg. As it stands, we won't be using intellisense at all for a while.

[danielmrussell]

I think part of the frustration with this whole experience is the fact that
we've passed a complexity threshold that's unmanageable. There are far too
moving part that influence each other in a mysterious voodoo way, so
tracking down these bugs is incredibly difficult and disheartening. A lot
of times, you'll get it working... for five minutes. Or the squiggly lines
will disappear, but you do something (like wait a few seconds) and it all
falls apart again. (Was it really failing to find that file? or just a slow
UI update?).

There's some kind of vastly complicated magic happening in CMake land as
well, so things like options passed to your compiler influence header
visibility, and that means if you don't have perfect CMakeLists.txt et al.,
you're gonna maybe get screwed by the include problems. And this is sort of
the default, because it takes real sweat, blood, and tears to build up your
CMake project enough to have all those things set correctly.

I'm not sure what the solution is, but I feel like we need some visual ways
to track things down and tell where the issues might be coming from.
There's far too much black magic right now.

On Mon, May 25, 2020 at 11:50 PM shogerr [e-mail] wrote:

Yeah, I came here with the same problem @thomthom
https://github.com/thomthom. The only solution I've found is to use
cl.exe, not clang. Furthermore, this extension has problems finding headers
for CMake projects that use Vcpkg. As it stands, we won't be using
intellisense at all for a while.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-cmake-tools/issues/770#issuecomment-633839870,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ52TEV3HAFB62ZKJF27ZMLRTNRCZANCNFSM4IWM72AA
.

[thomthom]

What might help is to have more examples of configurations. There is a lot of options available for each tool being used in this setup, and it's not immediately obvious what works and what doesn't.
For those scenarios where a setup worked it would be nice to have that demoed.

Perhaps a wiki to collaborate over? Or even another repository with small example projects?

[GreatBlambo]

Just commenting to say that I have a similar issue, but it seems to fail to find all headers in my project, not just standard ones, using the "Clang 10.0.0 for MSVC with Visual Studio Community 2019" kit. I've included the headers for the target in my CMakeLists.txt, used the configuration provider, switched to compile_commands.json, etc, still there's include errors and squiggles for names that should be found.

I also switched to the VS 2017 kit, and observed no such behavior.

[danielmrussell]

Coming back here, having forgotten this after a while not working with C++ and just swimming in a sea of Intellisense frustration.

It's really bad. This whole situation of intellisense fragility in vs code.

[andreeis]

@danielmrussell, while I'm looking at this issue, can you confirm that the "C_Cpp.default.configurationProvider" is set to "ms-vscode.cmake-tools" and not to "vector-of-bool.cmake-tools"? I kept seeing that earlier in the history of this report, even long time after we made the name change.

[andreeis]

I just want to note that IntelliSense works fine for me, with a simple project (created via the command "CMake: Quick Start" and the kit "Clang 10.0.0.0 (MSVC CLI) (Visual Studio Enterprise 2019 Release - amd64".
Verify again that the configurationProvider is "ms-vscode" and not "vector-of-bool", rescan your kits (eventually delete before all clang ones that are written there), reselect your clang kit, clean configure.... and let us know whether IntelliSense works.

[danielmrussell]

Yeah I did all that.

Nothing helped. I have many many kits for Clang that it scans. None of them work.

Where is your clang installed?
I have this: C:Program Files (x86)Microsoft Visual Studio2019BuildToolsVCToolsLlvmx64binclang.exe also, clang-cl.exe et al.

As well as C:Program FilesLLVMbinclang.exe.

I've tried various configurations, aligning clang.exe or clang-cl.exe with the configurations for GCC or Cl.exe style arguments etc. Still, nothing works. Except WSL.

I just remembered that I had to use WSL Clang instead to ever get this working.

For those encountering these issues:

Update your Windows as much as you can, Install WSL 2, then, from a WSL command prompt,
cd /mnt/<whatever your development path is from the pov of WSL> code .

This will launch code from Linux on Windows. Then, once launched, CTRL-SHIFT-P, C++Select a Configuration, and make sure it's set to 'Clang via WSL.'

Intellisense will work.

Congratulations, you are now a Linux developer.

Works for us open-source cross-platform types ok since we need to force ourselves to make our code work everywhere, even on Linux inside Windows. Graphics is still a p.i.t.a. though because getting X for windows is not fun. See: VcXsrv and https://wiki.ubuntu.com/WSL

[andreeis]

Are you able to share a windows repro with us? Or, if you create a small one from scratch (using the Quick Start command) and set it up the same as for your other project, do you still have IntelliSense problems? We'd like to fix this for windows so that you don't have to use WSL in order to get IntelliSense working.

[danielmrussell]

After HOURS of debugging, including attempting your repro and then confused about why I couldn't get my larger project to behave like that, I FINALLY though sheer luck noticed this:

It seems some rogue settings that never worked (as far as I can recall) but from another time have broken this. Removing these lines fixes the problem. I have no idea what those settings mean(t) and whether they are obsoleted, or just disallowed with clang, or whatever.

I believe those lines were autogenerated.
VERY confusing. So anyway, I deleted them. This seemed to fix the problem mostly.

EXCEPT that for the nlohmann_json library in particular, the squiggles CAME BACK after 5 minutes. It wasn't REALLY fixed.

In the repro I did, a very simple cmake project from scratch as you recommended, I copied over this subdir and it works fine. But in my larger project it just refuses to work.

I'm combing through everything trying to debug this. At this point, my C++ configurations file looks the same between the two, and so does everything else. So I'm completely stuck. I have NO IDEA why these random bugs just keep popping up each time and it takes days or even weeks to figure it all out. Again, FAR too many moving parts. It seems like tens or hundreds of things could affect it. I'm sure it's more like 30 things. But that's 26 or 27 things too much.

I'll continue to pull my hair out until I can find the source of the problem.

At the moment, I'm fresh out of ideas. I've copied over the EXACT clang configuration from my c_cpp_properties.json file in the simple repro project into the bigger real project: no luck.

I've made sure that I am on the same CMake kits in both projects: no luck.

This is truly odd.

[andreeis]

Regarding the auto-generated mysterious properties: if you ever see them show up again, open an issue on GitHub for the CppTools extension. It's never supposed to write stuff into c_cpp_properties.json, only the user.

Also, if you set "C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools", then the c_cpp_properties.json (and compile_commands.json) will be ignored by the CppTools extension (unless a source file is not recognized by CMake Tools and it doesn't know what information to create for it, only then c_cpp_properties.json is read from).

For both projects, set "cmake.loggingLevel": "Debug", open the same source file (which triggers squiggles in the bad project and doesn't in the good project), run the "C/C++: Log Diagnostics" command from the palette and send us the content of the "C/C++" and "C/C++ Diagnostics" output channels. All this for both projects.

[danielmrussell]

-------- Diagnostics - 3/3/2021, 11:37:36 AM
Version: 1.2.2
Current Configuration:
{
"name": "Clang on Windows x64",
"includePath": [
"${workspaceFolder}/"
],
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE"
],
"windowsSdkVersion": "10.0.18362.0",
"compilerPath": "C:/Program Files/LLVM/bin/clang.exe",
"intelliSenseMode": "windows-clang-x64",
"cppStandard": "c++20",
"cStandard": "c17",
"configurationProvider": "ms-vscode.cmake-tools",
"compilerArgs": [],
"intelliSenseModeIsExplicit": true,
"cStandardIsExplicit": true,
"cppStandardIsExplicit": true,
"compilerPathIsExplicit": true,
"browse": {
"path": [
"${workspaceFolder}/"
],
"limitSymbolsToIncludedHeaders": true
}
}
Custom browse configuration:
{
"browsePath": [
"f:/projects/waveweaver/extern/tuvok/include",
"f:/projects/waveweaver/extern/vulkanmemoryallocator/src",
"f:/projects/waveweaver/extern/vulkanheaders/include",
"f:/projects/waveweaver/extern/glfw/include",
"f:/projects/waveweaver/extern/fmt/include",
"f:/projects/waveweaver/extern/range-v3/include",
"f:/projects/waveweaver/extern/unifex/include",
"f:/projects/waveweaver/out/build/debug/visual studio build tools 2019 release - amd64/extern/unifex/include",
"f:/projects/waveweaver/waveweaver/src",
"f:/projects/waveweaver/extern/tuvok/include/tuvok",
"f:/projects/waveweaver/out/build/debug/visual studio build tools 2019 release - amd64/extern/vulkanheaders/cmakefiles",
"f:/projects/waveweaver/out/build/debug/visual studio build tools 2019 release - amd64/extern/vulkanloader/cmakefiles",
"f:/projects/waveweaver/extern/vulkanloader/loader",
"f:/projects/waveweaver/extern/vulkanloader/loader/generated",
"f:/projects/waveweaver/out/build/debug/visual studio build tools 2019 release - amd64/extern/vulkanloader/loader",
"c:/program files (x86)/windows kits/10/include/10.0.18362.0/km",
"c:/program files (x86)/windows kits/10/include/10.0.18362.0/shared",
"f:/projects/waveweaver/out/build/debug/visual studio build tools 2019 release - amd64/extern/vulkanloader/loader/cmakefiles",
"f:/projects/waveweaver/out/build/debug/visual studio build tools 2019 release - amd64/extern/vulkanloader/loader/cmakefiles/loader-opt.dir",
"f:/projects/waveweaver/out/build/debug/visual studio build tools 2019 release - amd64/extern/vulkanloader/loader/cmakefiles/loader-norm.dir",
"f:/projects/waveweaver/out/build/debug/visual studio build tools 2019 release - amd64/extern/vulkanloader/loader/cmakefiles/loader-unknown-chain.dir",
"f:/projects/waveweaver/extern/unifex/source",
"f:/projects/waveweaver/extern/glfw/src",
"f:/projects/waveweaver/out/build/debug/visual studio build tools 2019 release - amd64/extern/glfw/src",
"f:/projects/waveweaver/extern/glfw/include/glfw",
"f:/projects/waveweaver/extern/range-v3/include/concepts",
"f:/projects/waveweaver/extern/range-v3/include/meta",
"f:/projects/waveweaver/extern/range-v3/include/range/v3",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/action",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/algorithm",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/algorithm/aux_",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/detail",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/experimental/utility",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/experimental/view",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/functional",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/iterator",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/numeric",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/range",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/utility",
"f:/projects/waveweaver/extern/range-v3/include/range/v3/view",
"f:/projects/waveweaver/extern/range-v3/include/std/detail",
"f:/projects/waveweaver/extern/fmt/src",
"f:/projects/waveweaver/extern/fmt/include/fmt",
"f:/projects/waveweaver/extern/fmt",
"f:/projects/waveweaver/extern/catch/single_include",
"f:/projects/waveweaver/extern/nlohmann_json/single_include",
"f:/projects/waveweaver/extern/tuvok/tests",
"f:/projects/waveweaver/extern/nlohmann_json",
"f:/projects/waveweaver/extern/spdlog/include/spdlog",
"f:/projects/waveweaver/extern/spdlog/include/spdlog/contrib/sinks",
"f:/projects/waveweaver/extern/spdlog/include/spdlog/details",
"f:/projects/waveweaver/extern/spdlog/include/spdlog/fmt/bundled",
"f:/projects/waveweaver/extern/spdlog/include/spdlog/fmt",
"f:/projects/waveweaver/extern/spdlog/include/spdlog/sinks"
],
"standard": "c++17",
"compilerPath": "c:/program files (x86)/microsoft visual studio/2019/buildtools/vc/tools/msvc/14.23.28105/bin/hostx64/x64/cl.exe",
"compilerArgs": []
}
Translation Unit Mappings:
Translation Unit Configurations:
Memory Usage: 26 MB
Compiler Path: C:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools/VC/Tools/MSVC/14.28.29910/bin/Hostx64/x64/cl.exe
Includes:
C:PROGRAM FILES (X86)MICROSOFT VISUAL STUDIO2019BUILDTOOLSVCTOOLSMSVC14.28.29910INCLUDE
C:PROGRAM FILES (X86)WINDOWS KITS10INCLUDE10.0.18362.0UM
C:PROGRAM FILES (X86)WINDOWS KITS10INCLUDE10.0.18362.0UCRT
C:PROGRAM FILES (X86)WINDOWS KITS10INCLUDE10.0.18362.0SHARED
C:PROGRAM FILES (X86)WINDOWS KITS10INCLUDE10.0.18362.0WINRT
C:PROGRAM FILES (X86)WINDOWS KITS10INCLUDE10.0.18362.0CPPWINRT
Standard Version: ms_c++17
IntelliSense Mode: windows-msvc-x64
Other Flags:
--header_only_fallback
Total Memory Usage: 26 MB

------- Workspace parsing diagnostics -------
Number of folders and files enumerated: 11905
Number of files discovered (not excluded): 8005

I see tons of problems with this. I don't know how to fix them. Where are all these settings????? in c_cpp_properties.json, there is a CppStandard setting, and it's set to c++20, yet multiple settings when I ran Log Diagnostics report C++17 and other wrong information. Where is all of this???? how do I clear/reset it? Where are these settings coming from????

Where is Custom browse configuration coming from??? I have none of those set in my c_cpp_properties.json file whatsoever.

======================================================
Here's the good simple project:

-------- Diagnostics - 3/3/2021, 11:54:23 AM
Version: 1.2.2
Current Configuration:
{
"name": "Clang on Windows x64",
"includePath": [
"${workspaceFolder}/"
],
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE"
],
"windowsSdkVersion": "10.0.18362.0",
"compilerPath": "C:/Program Files/LLVM/bin/clang.exe",
"intelliSenseMode": "windows-clang-x64",
"cppStandard": "c++20",
"cStandard": "c17",
"configurationProvider": "ms-vscode.cmake-tools",
"compilerArgs": [],
"intelliSenseModeIsExplicit": true,
"cStandardIsExplicit": true,
"cppStandardIsExplicit": true,
"compilerPathIsExplicit": true,
"browse": {
"path": [
"${workspaceFolder}/"
],
"limitSymbolsToIncludedHeaders": true
}
}
Translation Unit Mappings:
Translation Unit Configurations:
Memory Usage: 23 MB
Compiler Path: C:/Program Files/LLVM/bin/clang.exe
Includes:
C:PROGRAM FILESLLVMLIBCLANG11.0.1INCLUDE
C:PROGRAM FILES (X86)MICROSOFT VISUAL STUDIO2019BUILDTOOLSVCTOOLSMSVC14.28.29910INCLUDE
C:PROGRAM FILES (X86)WINDOWS KITS10INCLUDE10.0.18362.0UCRT
C:PROGRAM FILES (X86)WINDOWS KITS10INCLUDE10.0.18362.0SHARED
C:PROGRAM FILES (X86)WINDOWS KITS10INCLUDE10.0.18362.0UM
C:PROGRAM FILES (X86)WINDOWS KITS10INCLUDE10.0.18362.0WINRT
F:PROJECTSWTFNLOHMANN_JSONINCLUDE
Defines:
_DEBUG
UNICODE
_UNICODE
Standard Version: c++20
IntelliSense Mode: windows-clang-x64
Other Flags:
--ms_extensions
--clang
--clang_version=110001
--header_only_fallback
Total Memory Usage: 23 MB

------- Workspace parsing diagnostics -------
Number of folders and files enumerated: 7765
Number of files discovered (not excluded): 5861

I also deleted my entire build directory just to see if any temporary files were screwing me up. Problem persists.

WHERE are these coming from truly? I'm searching everywhere and can't find them! Where are these settings??? Very very very frustrating. If I've deleted my entire build folder of temporary files, that seems to leave just User and Workspace settings in VSCode, but searching them turns up absolutely none of this junk.

[bobbrow]

The 4 weird settings showing up in your c_cpp_properties.json in the earlier screenshot is a cpptools bug. I just had the team open an issue for that. You can safely ignore them. The fact they show up in the log is a hint for us when debugging user issues, so please don't be alarmed by that.

This looks like a header-only library? https://github.com/nlohmann/json/
If the headers are not mentioned in your CMakeLists.txt then cpptools won't know how to configure them because CMake Tools won't get any information about them from CMake. As a result the IntelliSense configuration comes from the backup settings in your c_cpp_properties.json (e.g. includePath/defines/compilerPath).

[danielmrussell]

They're mentioned by the nlohmann project itself.

In the simple repro project all I did was add_subdirectory, which then allowed nlohmann to add its library targets including its headers.

My simple repro CmakeLists.txt. Works.

cmake_minimum_required(VERSION 3.0.0)


project(WTF VERSION 0.1.0)

include(CTest)
enable_testing()

add_executable(WTF main.cpp)

set(CPACK_PROJECT_NAME ${PROJECT_NAME})
set(CPACK_PROJECT_VERSION ${PROJECT_VERSION})
include(CPack)

add_subdirectory(nlohmann_json)

Snippets from nlohmann_json's CMakeLists.txt

# 1
if (JSON_MultipleHeaders)
    set(NLOHMANN_JSON_INCLUDE_BUILD_DIR "${PROJECT_SOURCE_DIR}/include/")
    message(STATUS "Using the multi-header code from ${NLOHMANN_JSON_INCLUDE_BUILD_DIR}")
else()
    set(NLOHMANN_JSON_INCLUDE_BUILD_DIR "${PROJECT_SOURCE_DIR}/single_include/")
    message(STATUS "Using the single-header code from ${NLOHMANN_JSON_INCLUDE_BUILD_DIR}")
endif()

##
## TARGET
## create target and add include path
##
# 2 
add_library(${NLOHMANN_JSON_TARGET_NAME} INTERFACE)
add_library(${PROJECT_NAME}::${NLOHMANN_JSON_TARGET_NAME} ALIAS ${NLOHMANN_JSON_TARGET_NAME})
if (${CMAKE_VERSION} VERSION_LESS "3.8.0")
    target_compile_features(${NLOHMANN_JSON_TARGET_NAME} INTERFACE cxx_range_for)
else()
    target_compile_features(${NLOHMANN_JSON_TARGET_NAME} INTERFACE cxx_std_11)
endif()

# 3
target_include_directories(
    ${NLOHMANN_JSON_TARGET_NAME}
    INTERFACE
    $<BUILD_INTERFACE:${NLOHMANN_JSON_INCLUDE_BUILD_DIR}>
    $<INSTALL_INTERFACE:include>
)

1) Selects include directory based on whether you configure for a single header result or not.

2) Creates an INTERFACE header only library and aliases it. The variable names are weird here. They both are the same, from $PROJECT_NAME (and assigned earlier). They are the same because nlohmann calls the project() command locally at the beginning of its CMakeLists.txt. I confirmed they resolve correctly to nlohmann_json::nlohmann_json. I also messaged out the include paths that are computed. They are all resolving perfectly to the real directories on the hard drive.

3) Specifies headers part of this INTERFACE library and this should transfer to all other things that link to it. But this problem is happening within nlohmann_json itself. It's not just that other parts of my project can't see the its headers. IT can't see IT'S OWN headers despite that it correctly resolved its include directories and added them using target_include_directories.

Just to make sure, I messaged out and even hardcoded these values. To no avail. Only on Clang on Windows. It doesn't seem to matter the kit, etc. And Clang that's not WSL will fail here, while the rest will work.

In my real project it's a little more complicated because it's in a subdirectory called extern/ off the main project. But at any rate, all the legwork is doing by the library's own CMakeLists.txt file. That file already adds a library and the headers are part of that, and should be inherited to the rest of the project that depends on nlohmann_json.

What could be causing this divergence? I'm really at the end of my wit's here.

Thanks for your help.

[bobbrow]

What I meant when I said you need to "mention" the headers in your CMakeLists.txt was you need to do something like this to guarantee that CMake provides a config for your headers:

add_executable(WTF header1.h header2.h main.cpp)

cpptools will do its best to try to link headers back to a c/cpp file that references them to try to borrow that configuration, but it doesn't always work.

[danielmrussell]

That's particularly strange because 1) it doesn't affect any thing else. I have lots of header only libraries on here. 2) Isn't the point of add_library() for INTERFACE libraries to make it so we DON'T do this? Isn't that old style? I thought that was the entire point of CMake INTERFACE libraries. I'm very confused. 3) The squiggles are happening in nlohmann_json ITSELF. It's own files can't even find its own headers.

[bobbrow]

I can't comment much on what is the best way to author your cmake scripts but what I do know is that if CMake doesn't tell us what the configuration is for the files, we can't pass those configurations on to cpptools. Listing the header files has helped people in the past.

Again, cpptools will do a best effort to build an include graph and map headers back to a source file (which CMake will always give us a configuration for), but this doesn't always work 100%. The way you can tell is that you'll see --header_only_fallback in the Configuration Log. I don't see waveweaver on GitHub, so I don't know if this is a project we can clone to take a closer look at. I did clone nlohmann's json project and the IntelliSense worked for me there because there was a source file in the CMakeLists.txt that included the json.hpp (which seems to include basically everything else) and cpptools' include graph mapping managed to sort out the dependencies for the headers as I opened them.