Hi Martin,
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
Maybe, IScannerInfoProvider.subscribe(IResource, IScannerInfoChangeListener) is not implemented properly yet. If a new source file gets opened, everything looks like intended.
I could provide a sample eclipse project including cmake-scripts and minimalistic sources if you want.
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.
...
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.
Yes, I refer to Language Server Protocol here. But I was not aware of the fact that (at least clangd) can parse a compile_command.json file by itself. Sorry for the noise. Could the Language Server people chime in here and clarify whether they need a the parser (or do NOT need)?
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.
Forgot to mention that the report should be based on a per-source-file level. cmake allows to specify multiple artifacts to build; with different compile options for the artifact's sources. In contrast to managed build: One project, one artifact, one set of compiler options for each source.
But could be that be addressed in a different change request?
Martin
