Differences between SourceFileConfiguration and c_cpp_properties.json...

[busticated]

hey there 👋

as i continue to improve support for intellisense in Particle Workbench, i'm noticing there are a few differences between what can be configured via the provider APIs (CustomConfigurationProvider and related) and what is supported via the standard c_cpp_properties.json configuration file.

specifically:

• standard vs. cStandard and cppStandard (briefly discussed here)
• compileCommands is not supported

what's the reasoning here? i ask b/c i need to generate much of the required info as part of my release process and want to target a stable, well-documented output format.

i'm also fuzzy on the UX around c_cpp_properties.json support for the configurationProvider field - does using this allow end-users to add their own settings on top of what the provider sets? if so, are end-user settings merged or do they fully replace what is provided?

thanks 🙏

[bobbrow]

• standard vs. cStandard and cppStandard (briefly discussed here)

The reasoning here is that you provide one configuration per translation unit (e.g. .c or .cpp file), so it doesn't make sense to send both C and C++ standard versions since the file will only compiled as one or the other.

• compileCommands is not supported

The reasoning here is that compile commands contains configurations for an entire project. The config provider is the replacement for compile commands.

i'm also fuzzy on the UX around c_cpp_properties.json support for the configurationProvider field - does using this allow end-users to add their own settings on top of what the provider sets? if so, are end-user settings merged or do they fully replace what is provided?

My vision for this is to show all registered providers in a drop down list to allow the user to configure this more easily. It would be an alternate experience to the "Change Configuration Provider" command. The UI doesn't do that yet, but I plan for it to.

[busticated]

@bobbrow thanks 🙏

it doesn't make sense to send both C and C++ standard versions since the file will only compiled as one or the other

yeah, i get that. how do you go about disambiguating .h files? and how does it work for WorkspaceBrowseConfiguration (source) since provideBrowseConfiguration() and the newly added provideFolderBrowseConfiguration() don't expose file-level URIs...?

The reasoning here is that compile commands contains configurations for an entire project. The config provider is the replacement for compile commands.

ah, ok. well, i'm actually trying to configure the entire project. my wrinkle is that configurations can change based on how the user has configured their project. i went w/ the provider api to make it easier to manage those dynamically (as opposed to having to update the c_cpp_properties.json itself on behalf of the user... which given how changes propagate may not even be possible).

[bobbrow]

yeah, i get that. how do you go about disambiguating .h files?

For .h files we try to find a .c or .cpp file that includes it and then we ask you for the configuration for that file instead (since many providers don't know what to do with .h). If we don't find a good match, we'll ask you for the configuration for the .h directly.

and how does it work for WorkspaceBrowseConfiguration (source) since provideBrowseConfiguration() and the newly added provideFolderBrowseConfiguration() don't expose file-level URIs...?

For WorkspaceBrowseConfiguration you would return a C++ standard if there are any C++ files in your project and a C standard otherwise. For mixed language projects, you return a C++ standard. What you send here determines whether the C++ STL is browseable or not.

ah, ok. well, i'm actually trying to configure the entire project. my wrinkle is that configurations can change based on how the user has configured their project.

If the configurations change based on user interaction with the workspace (e.g. switching a configuration from "Debug" to "Release"), you call the didChangeCustomConfiguration and didChangeCustomBrowseConfiguration APIs to tell cpptools to discard the previously provided information and ask for it again.

[busticated]

@bobbrow thanks 🙏

For .h files we try to find a .c or .cpp file that includes it and then we ask you for the configuration for that file instead (since many providers don't know what to do with .h). If we don't find a good match, we'll ask you for the configuration for the .h directly.

ah, that works 👍

For mixed language projects, you return a C++ standard.

sound good 👍

If the configurations change based on user interaction with the workspace (e.g. switching a configuration from "Debug" to "Release"), you call the didChangeCustomConfiguration and didChangeCustomBrowseConfiguration APIs to tell cpptools to discard the previously provided information and ask for it again.

yep, that's what i'm doing today. my point was that as we are exploring migrating to a cmake driven build system, it would be convenient to provide those configurations as compileCommands (aka compile_commands.json) while still using the provider API to supply configuration. otherwise, we'll essentially be translating from compile_commands.json to the format accepted via the provider API (defines, includePaths, etc) which seems redundant since you all already have that logic in place today.

but i guess that's better filed as a "feature request" so fwiw 🤗

[bobbrow]

If you are migrating to CMake, is your extension able to leverage the CMake Tools extension which already implements the configuration provider? We recently became the maintainers of that extension and can work with you to make sure your stuff continues to configure properly if you want to try that route.

[busticated]

ah, interesting! i'll definitely take a look 👍

one tricky bit for us is that we'd need to support both old and new build systems in order to facilitate building older releases 😬

[bobbrow]

Is there anything left from this issue that needs to be addressed?

[busticated]

nope!