-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
macOS framework support for IntelliSense #970
Comments
I am experiencing the same exact problem with IOKit and other macOS frameworks, it would be very nice to support intellisense. |
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? |
Yes, it is possible to use this kind of work-around. |
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's great! |
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. |
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
or Option 2 - create a new property for it (which is only evaluated on Mac systems)
|
I prefer option 1. |
I prefer option 2 |
I prefer option 1, to keep the configuration properties at the minimum possible. |
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. |
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? |
I would probably start typing "framew...." side by side the to "includePath" in the json file hoping that intellisense would popup something meaningful. |
Since there was no clear winner, we decided to support both options. So you can specify the framework include path either way and we'll accept it. |
The fix for this is in 0.12.4. The new property in c_cpp_properties.json is called "macFrameworkPath" and it should be auto-added to your c_cpp_properties.json file when you open your folder on a Mac. Let us know if you have any trouble with it. I just realized that we didn't send the paths through our variable resolver, so |
Unfortunately this feature seems to not work on my side, As you can see i tried different things, put the root folder or frameworks/headers directories directly. If i switch "fuzzy" mode on & off the result is the same (well in fuzzy mode it's underlined in green with a message telling to update includePath). Did I miss something ? OSX 10.14.3 |
@jbltx You should remove the .framework folders from the "includePath" (i.e. only use the |
@sean-mcmanus I just deleted all paths in includePath but |
@jbltx If you're using the "Tag Parser" intelliSenseMode then you may need to copy the framework path to the browse.path setting....otherwise this could be a bug should investigate (i.e. I could move it to a new issue). We're about to release 0.22.0, but this scenario isn't expected to have changes. |
I am not using Tag Parser right now, here are my settings : "C_Cpp.intelliSenseEngineFallback": "Disabled",
"C_Cpp.errorSquiggles": "Disabled",
"C_Cpp.intelliSenseEngine": "Default", |
Based on what I see in the picture you showed above, the correct way to include QMainWindow is:
When the compiler resolves frameworks, it trims the part of the path from |
Though looking back at the original error, it seems the extension should have picked up the dependency. I'll have to try this out on my mac tomorrow. But let's move the conversation over to #3323 since this issue is closed. |
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:
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)
The text was updated successfully, but these errors were encountered: