retain c_cpp_properties.json information

[euklid]

Hi,

it's great that you had the idea to make this tool, because it indeed is annoying to manually add all the paths by hand while CMakeTools already provides most of the parts.

My problem is: Standard paths like

/usr/include
/usr/local/include or a little bit more exotic (depending on which distro (mine Linux Mint 17.3, based on Ubuntu 14.04 LTS))
/usr/include/x86_64-linux-gnu/c++/5 <-- this is the c++ standard library I am using

are not included in my project so that simple things like using #include <vector> fail for the intellisense engine.

It would be great, if you could first use the output generated by VS Code in the c_cpp_properties.json and then extend it by the information from CMakeTools.

[decimad]

Yes, also the intellisense engine parser mode always gets overriden with "msvc-x64" and I could not yet find a way to change that default value.

[decimad]

Oh also it would be great because then I could configure ignore-paths - we have a post build step which copies the results into a result folder, ending up with multiple copies of a file in the implicitly-recursive default-include paths.

[maddouri]

Hello!

Sorry for the delay. (got taken away by real life stuff ;)
Thank you for contributing to the extension by starting this interesting discussion.

The problem with standard paths is that they are both OS- and compiler-dependent.
For instance, if you use gcc on linux, you can get the standard includes with such commands as echo | gcc -xc++ -E -v -. clang 3.8 (on ubuntu) seems to support similar flags. However, I have absolutely no idea on how to get the information from MSVC on windows. (to be honest, I haven't looked into it yet ;p )
Also, how about cross-compilers?

Currently, I can think of at least 3 approaches:

1. Trying to figure out the compiler's includes (easy if gcc/clang on linux... hopefully not impossible for others)
2. Providing a config/setting that allows the user to configure their compilers' (yes, plural) includes
3. Combining the above 2 points: i.e. trying to figure out the compiler's includes then add/merge with the ones specified by the user

What do you guys think of that?

[decimad]

Hi!
If the extension would take a template-config and only add the additional cmake-project paths I'd be totally pleased already, automatic compiler include detection is only sugar ;) Would be great if it could track that template config for changes as well.

Btw. do you happen to know what triggers cmake-tools to fall back to the "all" target? That happens quite often to me and obviously I'm losing all the include paths with that...

[euklid]

I think the best candidate for this template-config would still be the c_cpp_properties.json that is first generated by the cpptools. It probably sounds like a hack, but maybe there is a way to trigger the generation of the autogenerated c_cpp_properties.json and then use the generated file afterwards.

Because cpptools somehow already takes over the part of automatic standard includes, you would also not need to figure out to support all the different standard includes for the different compilers.

These are just some ideas, but I think your approach 3. also sound like something that would only need to be done once and then can be reused for new projects.

[rhythmchicago]

Same problem on macOS. Couldn't it just use clang to pull in the locations?

For example:

clang -Wp,-v -E -xc -x c++ /dev/null

will yield:

/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks (framework directory)

[firewave]

I also ran into this problem. On Ubuntu 17.04 I had to add the following paths to get rid of all unknown includes

/usr/include/linux
/usr/include/c++/6.3.0
/usr/include/x86_64-linux-gnu/c++/6.3.0

The first path is for stddef.h and the other ones are obviously for C++ includes - the version number is the one from the GCC being used. I assume when libc++ and/or clang are used they might differ.

[TheJare]

Ideas:

• Don't remove existing configurations in the c_cpp_properties.json file, just add your own.
• Use existing standard configurations (Mac, Linux, Win32) in c_cpp_properties.json file to extend the one(s) created by Cmake-Tools-Helper.

[Ligh7bringer]

As a workaround, I have added my sdtlib paths to <defult vscode dir>/extensions/maddouri.cmake-tools-helper-0.1.1/out/src/c_cpp_properties.js.

For example, if I wanted /usr/include to be always added to the includePaths, I would add it to the incDirs array let incDirs = ["/usr/include"] on line 27. It seems to work.