Allow configuration providers to provide the compileCommands file path

[g-arjones]

Feature Request

I've also looked for documentation (a developer guide?) about how extension authors should use the configuration provider interface and could not find any...

[sean-mcmanus]

@g-arjones See https://github.com/microsoft/vscode-cpptools-api . We could move this feature request there.

[g-arjones]

Thanks!

We could move this feature request there

Sounds good to me!

[bobbrow]

I believe the feature has been requested already: microsoft/vscode-cpptools-api#50

[g-arjones]

As far as I understood, the other one proposes the construction of a SourceFileConfigurationItem from a compilation database (a.k.a. parse it and fill the existing fields). My suggestion was to extend SourceFileConfigurationItem to include a compileCommands member and then leverage what's already implemented in vscode-cpptools/IntelliSense.

Would fit my use case as well but not the same. I think my suggestion is simpler to implement.

[bobbrow]

(a.k.a. parse it and fill the existing fields)

I believe they said they had started doing that, but wanted to just give us the compile_commands.json so they wouldn't have to do it.

Currently I am trying to parse out the command portion of the compile_commands.json to get the compiler args/fragments, and building up the compilerFragments list, but it would be so much better to point at compile_commands.json directly, similar to how it is being done in the c_cpp_properties.json config.

[g-arjones]

Yeah... I understood they wanted something like:

let config = SourceFileConfigurationItem("path/to/compile_commands.json");
// ... the file is parsed by **vscode-cpptools-api** (no changes to the interface)
// and the existing members are set

What I am suggesting is:

let config = SourceFileConfigurationItem();
config.compileCommands = "path/to/compile_commands.json";
// requires adding `compileCommands` to `SourceFileConfigurationItem`
// parsing is done by vscode-cpptools/IntelliSense (I'm not sure which one consumes the compilation db)
// `config` may have nothing set aside from `SourceFileConfigurationItem.compileCommands`

That's how I typically use c_cpp_properties.json (the only option I set is compileCommands)

[g-arjones]

To be clear: I would be fine with either. Is anything like this currently a planned feature?

[bobbrow]

The difference between the two examples you provided looks like an implementation detail and I believe either would achieve the same purpose. However, since the SourceFileConfiguration[Item] interfaces are at a level more granular than a compile commands database, we probably wouldn't want to expose it there. I think a new ProjectConfiguration or similar interface needs to be designed so that information about all known files can be provided up front.

@Colengms and I have discussed the project configuration concept before but we haven't scheduled this work yet due to competing priorities. It's possible that much of this work could be done in the Open Source portions of our codebase and we would accept help from someone in the community if they had the time to look into it.

[g-arjones]

I think a new ProjectConfiguration or similar interface needs to be designed so that information about all known files can be provided up front.

Doesn't a compileCommands fit in WorkspaceBrowseConfiguration ?

I may find some time to help with the implementation if you guys can help with design and planning. I'm not familiar with this codebase and unfortunately cannot look deep into it.

[bobbrow]

Doesn't a compileCommands fit in WorkspaceBrowseConfiguration ?

It could, but the browse configuration is only looking for file paths to scan. It doesn't help with the IntelliSense configuration. The ProjectConfiguration (or similar) would conceptually be a merger of the browse configuration and an array of all SourceFileConfigurations known to the project. I haven't spent a ton of time thinking about the design yet, but if an extension supported the ProjectConfiguration, we would only request that object and not request separate WorkspaceBrowseConfigurations or individual SourceFileConfigurations - I would expect that all of that information is provided up front. A compile commands database would satisfy those requirements.

[g-arjones]

That makes sense.

I haven't spent a ton of time thinking about the design yet

Please, let me know if/when you do. I'll be happy to take care of the implementation since that would save me a lot of work on a feature I'm working on.