Allow to provide a set of full configuration objects in c_cpp_properties by a configuration provider

[LostTime76]

Feature Request

Today, a configuration provider can be set on each individual configuration object defined within the configurations array within c_cpp_properties. However, if my configuration provider understands all of the possible configurations that exist within a build, why can't it just provide the full set of configuration objects to the cpp extension - name and all. Right now, we would have to define each configuration twice: once in the actual build for the build tool and once within c_cpp_properties. I think the configuration provider extension can just provide the lot of configurations to the cpp extension. This would get rid of configuration duplication and ease maintenance.

c_cpp_properties.json today:

{
"configurations": [
{
"name": "first",
"configurationProvider": "provider"
},
{
"name": "second",
"configurationProvider": "provider"
},
{
"name": "third",
"configurationProvider": "provider"
}]
}

Could change to:

{
"configurationsProvider": "provider",

"configurations": [
{
	"name": "config_that_top_level_provider_does_not_feed",
	"provider": "another_provider"
}]

}

There are several ways to skin this cat to get the proposed functionality. One could provide additional interface functions on a configuration provider OR create a new interface that is a CustomConfiguration_s_Provider for example.

My point is that my configuration provider (by virtue of most likely being an extension that adds build tool support for a project) probably already knows all of the configurations that exist within the build. I should not have to duplicate define them in c_cpp_properties.json

[sean-mcmanus]

@LostTime76 You should be able to set one configurationProvider and then when the configuration provider extension changes, it would just send updated configurations -- this is what happens with the CMake Tools extension configuration provider when you switch between different CMakePresets.json configurations. Multiple configurations in c_cpp_properties.json with the same configurationProvider would generally only be used if you wanted to have different "fallbacks" for files that the configurationProvider doesn't have a configuration for. Did you have some other reason to have multiple configurations with the same provider?

[LostTime76]

I am not sure I grep your response. In my project, I have multiple configurations using the same toolchain. The difference is that source files, include paths, and defines are changed per configuration. The build tool understands there are multiple configurations and how to build each one. However I would like a means to supply all those configurations from the build tool extension to the cpp tools extension such that I don't have to manually populate a duplicate array as above. I don't see a way for a CustomConfigurationProvider to supply full objects into the configuration array (including the name of the configurations).

Are you saying there is a way to define a single global configuration within c_cpp_properties.json with a provider that can supply multiple full object configurations to the cpp tools extension?

[sean-mcmanus]

@LostTime76 The configurationProvider is able to send different includePaths and defines when it changes. If you're using a configurationProvider via the API at https://github.com/microsoft/vscode-cpptools-api, you shouldn't need to have multiple configurations. The configurationProvider API doesn't generate or c_cpp_properties.json or generate configurations json blocks into that file or deal with configuration names -- the API supplies the other info, includePath/defines/compilerArgs, etc. with other includePath/etc. in c_cpp_properties.json just available for users to set as a fallback if the configurationProvider doesn't have a configuration for a file.

[LostTime76]

The (my) configuration provider does not change. There is a file within the project that defines the configurations for the build tool. My extension activates, reads all the configurations from the file and then notifies the cpp extension it can serve configurations. The user is the one selecting the active configuration within vscode. I could provide the new includes if I was notified that a configuration changed. I have not gotten that far within the extension. I am not sure if my interface functions get called when the configuration changes.

For reference:

The user selects the active configuration in the bottom right from a list of (named) configurations provided within c_cpp_properties.json. I am either missing something, or I see no way how a configuration provider within the extension can provide a set of configurations that the user can select in the bottom right. Currently, it is using the c_cpp_properties.json to define those configurations.

[LostTime76]

Maybe I must be the one driving that right click menu to select the configuration in the bottom right? I am not experienced with vscode extensions yet, but I thought I saw something about a menu contribution point allowing to manipulate that menu. Can you confirm if that's the case? If it is, then I can just do didChangeConfiguration myself after handling the configuration change within my extension.