Intellisense is not resolving MacOS frameworks in with CMake extension

[lucianthorr]

Brief Issue Summary

Hi. I have a C++ project that with multiple MacOS dependencies. The project all looked fine in VSCode using the c_cpp_properties.json settings where I could set the includePaths and MacFrameworkPaths.

I have now added CMake to the project and it all works and builds using

target_link_libraries(ProjectXYZ PUBLIC ${CoreFoundation})
target_link_libraries(ProjectXYZ PUBLIC ${Accelerate})
target_link_libraries(ProjectXYZ PUBLIC ${CoreAudio})
target_link_libraries(ProjectXYZ PUBLIC ${CoreMidi})

but now the intellisense is not able to resolve any of the #include statements that are pulling in MacOS frameworks and libraries

CMake Tools Diagnostics

{
  "os": "darwin",
  "vscodeVersion": "1.77.0",
  "cmtVersion": "1.13.45",
  "configurations": [
    {
      "folder": "/Users/lucianthorr/projectxyz",
      "cmakeVersion": "3.26.2",
      "configured": true,
      "generator": "Xcode",
      "usesPresets": false,
      "compilers": {
        "C": "/usr/bin/clang",
        "CXX": "/usr/bin/clang++"
      }
    }
  ],
  "cpptoolsIntegration": {
    "isReady": true,
    "hasCodeModel": true,
    "activeBuildType": "Debug",
    "buildTypesSeen": [
      "Debug",
      "Release",
      "MinSizeRel",
      "RelWithDebInfo"
    ],
    "requests": [
      "file:///Users/lucianthorr/projectxyz/code/Audio%20Engine/SoundDevice.h"
    ],
    "responses": [
      {
        "uri": "file:///Users/lucianthorr/projectxyz/code/Audio%20Engine/SoundDevice.h",
        "configuration": {
          "includePath": [
            "/users/lucianthorr/projectxyz/code",
            "/users/lucianthorr/projectxyz/code/tpcircularbuffer",
            "/users/lucianthorr/projectxyz/code/audio engine"
          ],
          "defines": [
            "DSP_LITTLE_ENDIAN=1",
            "DSP_EXPORTS"
          ],
          "compilerPath": "/applications/xcode.app/contents/developer/toolchains/xcodedefault.xctoolchain/usr/bin/clang++",
          "compilerArgs": [],
          "compilerFragments": [
            "-g '-std=gnu11' -fPIC"
          ]
        }
      }
    ],
    "partialMatches": [],
    "targetCount": 5,
    "executablesCount": 0,
    "librariesCount": 1,
    "targets": [
      {
        "name": "ALL_BUILD",
        "type": "UTILITY"
      },
      {
        "name": "ZERO_CHECK",
        "type": "UTILITY"
      },
      {
        "name": "ALL_BUILD",
        "type": "UTILITY"
      },
      {
        "name": "DSP",
        "type": "SHARED_LIBRARY"
      },
      {
        "name": "ZERO_CHECK",
        "type": "UTILITY"
      }
    ]
  },
  "settings": [
    {
      "communicationMode": "automatic",
      "useCMakePresets": "auto",
      "configureOnOpen": true
    }
  ]
}

Debug Log

No response

Additional Information

The diagnostics was generated while looking at the SoundDevice.h file. If the responses[0].configuration.includePath is supposed to be all the included paths available for SoundDevice.h, then that would explain the issue.

How can I get the includePath for SoundDevice.h to include all of the libraries that have been linked in CMakeLists.txt?

[lucianthorr]

If it's helpful for debugging, I have found that I can add

include_directories(BEFORE
    "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/**"
)

to my root CMakeLists.txt, before including my code and many of the intellisense squiggles go away and I can also see in the CMake Tools Diagnostics that the included director above was added to includePath.

It doesn't entirely squash the intellisense errors but it does reduce them. Maybe, since these aren't legitimate CMake or C++ errors, that there's a discrepancy between the includePaths that are being generated for intellisense and the actual included paths used for the build?

[benmcmorran]

Thanks for the report. I'm guessing this is a similar issue to #2324 where the JSON response files we get back from CMake (which are used to power IntelliSense) don't contain all the include paths used by the project. In particular, the response files won't contain paths that are injected by the generator itself. I'm not sure when we'll be able to get to this issue but I'm leaving it open for others to vote on and comment.

[Zingam]

I have reported a similar issue. Maybe in the cpptools repo.

[lucianthorr]

I don't know enough about how the Intellisense works or how the cmake and cpptools extensions communicate but I don't think it's generator-specific. I can change to "Unix Makefiles" and I get the same Intellisense errors.
From my point of view, it's not that the CMake Intellisense isn't finding the linked MacOS frameworks and libraries like CoreAudio or Accelerator, the problem is that it's not resolving the basic MacOS SDKs/MacOSX.sdk/usr/include/ libraries.

The fundamental Intellisense errors are that it can't resolve .h files like time.h that are stored /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/

If anyone can point me in a direction, I'm happy to look deeper and try to find a fix.

[lucianthorr]

I think I may have found the problem and it was totally with my configuration.
At some point in setting up the extensions, I set "configurationProvider": "ms-vscode.cmake-tools", in my c_cpp_properties.json. At the time, I was probably trying to debug a common issue with including the Accelerate framework and how it's not able to resolve some of its internal dependencies.
By either removing that setting or changing that configurationProvider to just cmake-tools fixes all the intellisense problems (except for the cblas.h dependency inside Accelerate.framework).

If anyone should run into similar issues, I was able to get all the intellisense working with the following settings inside c_cpp_properties.json

{
"configurations": [
        {
            "name": "Mac",
            "includePath": [
                "/Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Headers"
             ],
            "configurationProvider": "cmake-tools",
            ....
        }
    ],
    "version": 4
}

[bobbrow]

@lucianthorr because cmake-tools is not a valid configuration provider, what this change actually does is disable using CMake Tools as the configuration provider and results in cpptools using the path listed in your includePath instead.

What we should probably do instead is add a workaround to cpptools to have it allow reading from the macFrameworkPath when CMake Tools is the configuration provider. Then you could put the path in that field and still use CMake Tools for the other properties.

[lucianthorr]

Thanks. Although, I want to mention in the specific case of the Accelerate framework, adding it or its dependency vecLib to macFrameworkPath does not fix Intellisense. Maybe it's a cpptools bug?

If it is possible for CMake Tools to honor the paths added to includePath, that would be ideal.

[bobbrow]

I didn't scroll horizontally earlier. The correct framework path is: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks

I don't have a mac handy to test child framework includes right now, but I seem to recall writing code years ago to handle discovering child frameworks (veclib in this case). I'm not sure how you're including the framework headers in your code, but as per Apple documentation I would expect it to be like this:

#include <veclib/foo.h>

as opposed to direct inclusion like this:

#include <foo.h>  // This is a veclib header.

The path you shared above hints that you might be using the second example's syntax, so I just wanted to check.

[lucianthorr]

My code just has #include <Accelerate/Accelerate.h>, to which Intellisense gives the error cannot open source file "cblas.h"
I have the macFrameworkPath set to the same as you posted above and that helps resolve all the frameworks I'm using in this project (CoreFoundation, CoreAudio, Accelerate).

I have also tried adding the sub-framework to macFrameworkPath like
"/Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks"
hoping that would help but it didn't.

My entire c_cpp_properties is

{
    "configurations": [
        {
            "name": "Mac",
            "includePath": [
                "/Users/lucianthorr/dev/myproject/**",
                "/Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Headers"
            ],
            "defines": [],
            "macFrameworkPath": [
                "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks"
            ],
            "cStandard": "c11",
            "cppStandard": "c++17",
            "intelliSenseMode": "macos-clang-arm64",
            "mergeConfigurations": false,
            "compilerPath": "/usr/bin/clang",
            "browse": {
                "limitSymbolsToIncludedHeaders": true,
                "path": [
                    "${workspaceFolder}/**"
                ]
            }
        }
    ],
    "version": 4
}

[bobbrow]

@lucianthorr since we're getting into issues with the actual language server now, I reposted your latest comment over in the cpptools Issues page. We should be able to better help you over there.

[lucianthorr]

Thanks again for all the help working through this.