New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Differences between SourceFileConfiguration
and c_cpp_properties.json
...
#19
Comments
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.
The reasoning here is that compile commands contains configurations for an entire project. The config provider is the replacement for compile commands.
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. |
@bobbrow thanks 馃檹
yeah, i get that. how do you go about disambiguating
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 |
For
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.
If the configurations change based on user interaction with the workspace (e.g. switching a configuration from "Debug" to "Release"), you call the |
@bobbrow thanks 馃檹
ah, that works 馃憤
sound good 馃憤
yep, that's what i'm doing today. my point was that as we are exploring migrating to a but i guess that's better filed as a "feature request" so fwiw 馃 |
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. |
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 馃槵 |
Is there anything left from this issue that needs to be addressed? |
nope! |
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 standardc_cpp_properties.json
configuration file.specifically:
standard
vs.cStandard
andcppStandard
(briefly discussed here)compileCommands
is not supportedwhat'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 theconfigurationProvider
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 馃檹
The text was updated successfully, but these errors were encountered: