macOS framework support for IntelliSense

[trtd]

Feature Request for macOS

Please consider supporting the finding of include files in macOS frameworks, where the include files are located together with libraries inside framework bundles.
Compilers on macOS have built-in support for frameworks.

An example based on the Qt Core framework:

QtCore.framework/
  |── Headers -> Versions/Current/Headers
  |── Resources -> Versions/Current/Resources
  └── Versions
    |── 5
    |   |── Headers
             ...
             qiodevice.h
             QProcess.h
    |  └── Resources
    └── Current -> 5

The file QProcess.h has include directive #include <QtCore/qiodevice.h>, and it is impossible to define the macOS includePath in a way that IntelliSense would find the included header.

Additional links on the framework bundles:
https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html#//apple_ref/doc/uid/20002253-99920-BAJFEJFI
http://blog.bfitz.us/?p=1793 - see chapter Frameworks (NeXT/Mac OS X)

[Pagghiu]

I am experiencing the same exact problem with IOKit and other macOS frameworks, it would be very nice to support intellisense.

[sean-mcmanus]

I think you can work around the issue by creating a symbolic link with the same name as the framework or header path name (e.g. QTCore) and then add a path to that file to includePath. Are you able to get that to work?

[trtd]

Yes, it is possible to use this kind of work-around.
However I do not think this is a permanent solution since a lot of Apple's and third party frameworks are packaged this way, and I am not willing to touch system framework bundles.
I personally will use XCode if I develop applications using macOS frameworks, which is a shame since XCode's UX is horrible compared to VS Code.

[bobbrow]

We plan to add better support for frameworks. It won't make it into the 0.12.3 release, but the plan is to have it in the next one.

[trtd]

That's great!
If I can help with something (testing for example), please let me know.

[jiayihu]

We plan to add better support for frameworks. It won't make it into the 0.12.3 release, but the plan is to have it in the next one.

That would be awesome, for now I'm sticking with CLion but today I was very surprised by the effort you are putting into C++ support in VSCode.

[bobbrow]

Quick question for those following along. We are considering two different options for letting you specify the framework paths. Which option best matches how you would expect it to work? Please respond with your vote.

Option 1 - just put it in the "includePath" with all the other paths

        {
            "name": "Mac",
            "includePath": [
                "/System/Library/Frameworks",
                "${workspaceRoot}"
            ],
            ...
        }

or

Option 2 - create a new property for it (which is only evaluated on Mac systems)

        {
            "name": "Mac",
            "includePath": [
                "${workspaceRoot}"
            ],
            "frameworksPath": [
                "/System/Library/Frameworks"
            ],
            ...
        }

[florian-jackisch]

I prefer option 1.

[Pagghiu]

I prefer option 2

[jiayihu]

I prefer option 1, to keep the configuration properties at the minimum possible.

[trtd]

Don't really care, both would solve the problem for me. For example gcc and ld have special option "-framework", so solution 2 would be OK as well.

[bobbrow]

This is about how the voting turned out among the people I asked here at Microsoft. 😄

I personally lean toward option 1, but wanted to make sure that it wouldn't be confusing for people before committing to that design. I don't like the idea of a property that only applies to one platform (option 2), but I can understand that people might want to think about frameworks as a separate entity because of how you have to craft the command line for the compiler. In the same breath, there may be people who are less familiar with the command line because of IDE's and tools that do this for you and therefore they think of this as simply another path that serves to resolve #include statements, and is therefore just an "includePath"

Does anyone think that the absence of a specific property to declare your framework paths would leave people guessing as to where to put them? Or do you think they would instinctively try the includePath first before having to search the Internet for answers?