Repository navigation
Extension to CppTools extension - how to? #3978
Description
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.
Activity
michelleangela commentedon Jul 25, 2019
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 commentedon Jul 25, 2019
Hi Tomasz Jastrzębski (@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 commentedon Jul 25, 2019
Michelle Matias (@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 commentedon Jul 25, 2019
Colen Garoutte-Carson (@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 commentedon Jul 28, 2019
Michelle Matias (@michelleangela), Colen Garoutte-Carson (@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.
c_cpp_properties.jsonto my extension config and maintain it there. If/when they decide to disable my extension they will have to copy current config back toc_cpp_properties.json. It is just impractical. For that reason alone I may end up parsingc_cpp_properties.json.Colengms commentedon Jul 29, 2019
Hi Tomasz Jastrzębski (@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 commentedon Jul 29, 2019
Hi Colen Garoutte-Carson (@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.jsonfile parsing.tdjastrzebski commentedon Jul 29, 2019
Michelle Matias (@michelleangela), Colen Garoutte-Carson (@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 commentedon Jul 29, 2019
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
configurationProvidersettings.tdjastrzebski commentedon Jul 30, 2019
Michelle Matias (@michelleangela) Do I correctly understand calling
api.registerCustomConfigurationProvider(provider)andapi.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 commentedon Jul 31, 2019
In order for the C/C++ extension to know to use IntelliSense configuration from a specific provider,
configurationProviderneeds 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.Go to https://code.visualstudio.com/docs/cpp/customize-default-settings-cpp for more information on setting default values.
tdjastrzebski commentedon Aug 1, 2019
Michelle Matias (@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 commentedon Aug 1, 2019
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:
machine
Whereas, the IntelliSense configuration information for the C/C++ extension can be from:
configurationProvideris set in c_cpp_properties.jsonWhat will your extension use the data from c_cpp_properties.json for?
tdjastrzebski commentedon Aug 1, 2019
Michelle Matias (@michelleangela) My extensions needs most of what is available in c_cpp_properties file plus just a few linker setting. For that reason it does not make much sense to copy all the properties to another file or maintain same settings in two places or copy settings back and forth.
Probably what makes the most sense from the user perspective is extension which provides settings already available in c_cpp_properties file. That requires external settings provider to be specified in c_cpp_properties file and providing settings from.. the same c_cpp_properties file. I fully agree such design scenario is a bit weird but it may be the best option currently available.
tdjastrzebski commentedon Oct 27, 2019
Michelle Matias (@michelleangela) I ended up developing my own build tool. See Build++ VS Code extension. It can read setting from c_cpp_properties file but it does not have to.
Extension builds task for every available configuration.
It still would be very nice to be able to read the current selected configuration.
michelleangela commentedon Oct 30, 2019
Tomasz Jastrzębski (@tdjastrzebski) , the extension has the command
${command:cpptools.activeConfigName}to get the "name" of the active configuration. Will that work? For more info, see #1524tdjastrzebski commentedon Oct 31, 2019
Michelle Matias (@michelleangela), I do not think this would work. What I am looking for is a way for my extension to read activeConfigName from cpptools extension or, better yet, subscribe to some event and be notified whenever it changes.
bobbrow commentedon Nov 1, 2019
The current selected configuration is available via the command Michelle Matias (@michelleangela) shared. Though it sounds like you want to invoke it via TypeScript, which is possible by calling:
tdjastrzebski commentedon Nov 3, 2019
Bob Brown (@bobbrow) Thank you, I will check it out. It should work, albeit no notifications.
Please close this issue.