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

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.

I have been experimenting with the change. It looks promising in the correct direction. Some aspects don't just work, for example I am getting inconsistent indexing - i.e. sometimes index contains none of the includes. However I don't know if that is a core build problem, or something related to the experiments.

I think I am not answering your questions below - hopefully my semi-random comments help in the discussion.
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.

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.)

I am not sure on this - this sounds like information that the language server should provide. i.e. in the case of LSP the Java code should not read compile_commands.json. This may be idealistic on my part, there may be very many places that the IDE will need to know such information.
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. 

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.

cdt-dev mailing list
To unsubscribe from this list, visit

Back to the top