Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] cmake support how to integrate the compile_commands.json parser into CDT

Am So., 14. Juni 2020 um 04:07 Uhr schrieb Jonah Graham <jonah@xxxxxxxxxxxxxxxx>:
Hi Martin,

On Sat, 13 Jun 2020 at 07:47, 15 knots <fifteenknots505@xxxxxxxxx> wrote:
Hi all,

I added some experimental integration in gerrit mainly for testing so far.
As it turns out there are use cases behind just index support for the parser.
So please comment on how to design the methods for the parser to integrate it with CDT. I am appreciating any suggestions.

For now I found the following use cases:
1) Syntax highlighting/C-DOM-parser: For a given IFile, return the set of defines, include path to the DOM.

I did some re-work on the interface following Alexander`s suggestion. See
2) LSP. For a given IFile, return the path to the compiler executable and the set of command-line args that affect LSP (e.g. -m32, --sysroot). (This use-case is just a rough guess of mine).

(I assume you are referring to Language Server Protocol - I know earlier on there was another LSP acronym, but I can't recall what that was for.)

There is not much that I can tell about this.
3) End users often ask: Is compiler-option '-std=c17' (or similar) recognized and used for built-in detection? To aid users, these should be a way to provide a report on the options and detected include path and macros. (Otherwise we might get lots of questions).

I think this is a great idea. This is indeed a regular problem! This along with the better way of displaying is a good problem to solve. 

I see two things here that users might want to see:
3a) A report on the effective include paths and macros for a given source file. This information can be retrieved by calling IScannerInfoProvider#getScannerInformation(IFile). So it does not affect the interface of the CompileCommandsJsonParser class.
3b) To answer the question "Is compiler-option '-std=cxx17' (or similar) recognized and used for built-in detection?", a new method on CompileCommandsJsonParser could be introduced which returns the compiler path and the arguments that affect built-in detection as a list of strings for a given file. Or it may return a list of file names along with the args used for built-in detection. 

Concerning the end-user question, this is currently implemented by printing the command-line and output of built-in detection to a console. This was inspired by managed built but turns out to be wayy too complicated for users. They will have to enable the 'allocate console' option, force a new build ro be run and finally have to find the console. It could be much simpler if users can just click a 'show report' button and have a dialog/view opened.

We could get rid of the console printing if we implement 3b above. The console argument for the parser may then be removed, too.

Back to the top