Extension to CppTools extension - how to?

[tdjastrzebski]

I am set to build VS Code Extension carring simple automated build. I would like to read current basic settings from this extensions, especially properties defined in c_cpp_properties.json like compilerPath, includePath or defines, so I do not need to redefine them in my extension and such user settings are always consistens between extensions.

Is there any simple way to accomplish the above, other than re-parsing c_cpp_properties.json file in my extension and maintaining copy of configurations.ts?
Please excuse posting here if this is not the best place for such question.

[michelleangela]

There is a cmake extension https://github.com/microsoft/vscode-cmake-tools. Will this work for your case?

Can you elaborate more on what you will do with the information in c_cpp_properties.json?

[Colengms]

Hi @tdjastrzebski . I think that information would normally flow in the other direction - from a build system extension to the C/C++ extension. (i.e. the CMake Tools Extension). Existing build systems usually already have their own way to provide that information, such as a makefile, or CMakeLists.txt. The API here provides a way for the C/C++ Extension to receive that information from a build system extension.

[tdjastrzebski]

@michelleangela CMake, Make etc. and associated maintenance overhead is exactly what I would like to avoid in my SDLC. Such approach imposes obvious constraints but for simple projects it is feasible.
Thank you for adding compilerArgs to API.

[tdjastrzebski]

@Colengms While the desirable config data flow direction could be a matter of debate the reality is MS C++ extension is an excellent, well established tool with own configuration, so I better adopt what is available. Thank you for the link to cpp tools API, I will check it out.

[tdjastrzebski]

@michelleangela, @Colengms I managed to employ vscode-cpptools-api.
However, a bit more detailed docs would be very helpful. Part missing the most: how to construct CustomConfigurationProvider. Luckily, I found code using this api wrritten by others but relying on V1. I am still not quite certain what is BrowseConfiguration and BrowseConfigurationsPerFolder. Perhaps it is obvious. I admit, it is the first vscode extension I ever write.

I am not convinced this solution is better than what I asked for.

1. What I do not like is tight coupling between extensions. I think simply reading CppTools properties and combining with my extension props (namely, linker params) would allow for more loose coupling. At least my extension would not have a chance of breaking CppTools extension.
2. User of my extension will have to copy some settings from c_cpp_properties.json to my extension config and maintain it there. If/when they decide to disable my extension they will have to copy current config back to c_cpp_properties.json. It is just impractical. For that reason alone I may end up parsing c_cpp_properties.json.

[Colengms]

Hi @tdjastrzebski . A custom configuration provider provides settings that are already managed as part of a build system, to cpptools, making configuration of cpptools automatic. If using a custom configuration provider, most settings in c_cpp_properties.json are unnecessary as that information would come from the provider. A build system usually requires a superset of the information needed by cpptools. There are a number of challenges to implementing a (flexible) build system, and there may not be sufficient information in c_cpp_properties to drive it. (i.e. linking) That said, I don't think it would be unreasonable to leverage c_cpp_properties in your own extension. It's a json file, so can be loaded directly into a json object. I don't suspect you would require anything from configuration.ts, as that is mainly doing validating, handling changes as they are made, parsing data we get back from a custom configuration provider, etc..

[tdjastrzebski]

Hi @Colengms, thank you for your support. For the reasons I stated, at least for initial version(s) I will go with own c_cpp_properties.json file parsing.

[tdjastrzebski]

@michelleangela, @Colengms, What puzzles me a bit is why cpptools shows and allows to select current configuration while configuration is provided by the external provider. Is it sign of weakness (ext config provider not quite working), a bug or a feature?

I would expect current config name(s) to be supplied/managed by the external provider.

[michelleangela]

@michelleangela, @Colengms, What puzzles me a bit is why cpptools shows and allows to select current configuration while configuration is provided by the external provider. Is it sign of weakness (ext config provider not quite working), a bug or a feature?

I would expect current config name(s) to be supplied/managed by the external provider.

The "Win32" on the status bar refers to the current active configuration in c_cpp_properties.json. The external provider is then set under the configurationProvider settings.

[tdjastrzebski]

@michelleangela Do I correctly understand calling api.registerCustomConfigurationProvider(provider) and api.notifyReady(provider) is not sufficient and 'configurationProvider' property in c_cpp_properties.json must set as well? That is, c_cpp_properties.json is still needed? I feel like I am lost again.

[michelleangela]

In order for the C/C++ extension to know to use IntelliSense configuration from a specific provider, configurationProvider needs to be set in c_cpp_properties.json. There could be several configuration providers installed on VS Code, so it's up to the user to specify which one to use.

When opening a workspace folder, the C/C++ extension also prompts the user in a notification window if they would like to use a detected custom configuration provider to serve as IntelliSense configurations for the workspace folder. If the user responds with "yes", then that configuration provider will be added to the c_cpp_properties.json for them for the workspace folder.

Users can also specify default values for the properties in c_cpp_properties.json, either in the User or Workspace scope. This way, users do not need to explicitly set properties in c_cpp_properties.json that may share the same value among different workspaces. Example below for setting the default value for C_Cpp.default.configurationProvider.

"C_Cpp.default.configurationProvider": "id.of.config.provider"

Go to https://code.visualstudio.com/docs/cpp/customize-default-settings-cpp for more information on setting default values.

[tdjastrzebski]

@michelleangela That makes sense, thank you very much for the explanation.
Is there any way my extension can get the current c_cpp_properties configuration or at least selected configuration name without all the burden of being CppTools configuration provider?

[michelleangela]

The C/C++ extension and its API does not provide an automated way for other extensions to read the data from c_cpp_properties.json.

The data in c_cpp_properties.json can be from:

• default values set by the extension based on the platform, detected compiler, etc, on a user's
  machine
• user manually specifies or edits the values for a project

Whereas, the IntelliSense configuration information for the C/C++ extension can be from:

• data in c_cpp_properties.json
• information provided by other extensions via the C/C++ extension API if configurationProvider is set in c_cpp_properties.json

What will your extension use the data from c_cpp_properties.json for?