IncludePath override for generated paths?

[rillian]

Is there a way to provide default or local overrides to the includePath key in c_cpp_properties.json? Or a code hook so we could script our own defaults?

I'd like to provide a basic file in our repo so users get some kind of intellisense in their first-run experience, but we also have generated code whose location varies depending on the build config. If devs add those paths, we'll have diff noise if it goes in the same file. The build system knows what needs to be added, and could easily generate something, but that has the same collision issue.

[sean-mcmanus]

There is not currently a way to provide defaults for the include path. Would a global user setting for the include path be good enough? I don't understand how you want the build system generated include path to be specified to our extension.

[rillian]

I think a global setting would be unfortunate; shouldn't include paths be specific to a workspace?

I want to automate the work of building the list of include paths for a project so developers don't need to do this individually.

For static paths, a simple approach is to put .vscode/c_cpp_properties.json under version control. If an include path for some experimental variant is added, we have the problem that version control will try to propagate that path to other checkouts where it's not appropriate. A path could be added manually by the developer, or automatically by our build system munging the file. Our build system generates code, so needing to add object directories is common.

One solution would be to have a c_cpp_base.json with the same schema, and your extension would merge includePath values from that into those in c_cpp_properties.json. Then we could check in only the base file and local additions could go in the current properties file.

Another solution would be have some hook to ask your extension to call a script whenever it wants to know the include paths and preprocessor defines. We do this with the YouCompleteMe vim plugin, where we've written a glue service to ask the build system for the compiler flags it would pass when building any particular source file, which it propagates to clang-complete.

[sean-mcmanus]

Systems have certain include paths that are shared by multiple workspaces and could be configured per-user, like the user settings in vscode. I don't think our includePath setup was designed for "sharing" in mind, particularly since the install location can be different on everyone's machine. Would supporting environment variables be good enough, like ${env.MY_SPECIAL_PATH}, then somehow set that variable to be what you want? Can you check in some c_cpp_base.json and then run some script to combine it with the build paths to generate the c_cpp_properties.json? I'll ask our "designer" what he thinks of your scenario. Are you using something like CMake or a custom build system?

[rillian]

I don't think our includePath setup was designed for "sharing" in mind.

Sharing build configuration has always been a short-coming of Visual Studio. I hoped vscode could do better here.

Environment variable substitution wouldn't work well for our application. The build process cannot poke things in to the user session's environment, so this means we're still having to set the same things twice. What I'd really like is an overlay, the way settings.json overrides the built-in defaults, or script hook we can provide to generate properties on the fly.

[rillian]

We use a custom build system written in python.

[dab0bby]

I think for a build system linke CMake this would be a great feature. When the the generated include directories of CMake could be used by the plugin.

[bobbrow]

I have just posted a plan to issue #1338 that may address this issue. I encourage those on this thread to take a look and provide feedback.

It doesn't talk about a script hook to provide configurations at this time, but that is something we're also exploring in parallel, albeit offline right now.

[bobbrow]

A preview of this is available in the insiders build if you would like to try it out and provide feedback.

Configurations can come from a combination of the c_cpp_properties.json file and the new "C_Cpp.default.*" settings. The value of the settings will be injected into the configurations in c_cpp_properties.json wherever the special variable "${default}" is encountered.

The static paths can remain in c_cpp_properties.json and any workspace-specific values can go into "C_Cpp.default.includePath", etc (saved in the .vscode/settings.json file). You then can merge the two as follows: "includePath": [ "${default}", "/static/paths", ... ]

[bobbrow]

Two other features have since been added to the extension that may also address this issue:

• recursive includes - you can use ** syntax to tell the extension to automatically select include paths that contain the header files your source files are including. The ** must (currently) be at the end of the path string. For example, ${workspaceFolder}/** instructs the extension to use any path in the workspace folder that contains a header file as an include path if the source file includes a header from that path.

• custom configuration providers - this is the "hook" you refer to. You can write an extension that consumes the API our extension exports and register yourself as a "provider" of IntelliSense configurations. The api is published as vscode-cpptools on npm. 0.17.5 of our extension (released yesterday) supports version 0.1.0 of this API and I have started a PR that will support 1.1.0 though it is not 100% finished yet.