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.
I was trying out the new -> C/C++ Project -> CMake Project. While the header file (iostream) was found (i.e. ctrl-click worked) most of the time. Getting std and cout to not have error markers was a problem. The AST for iostream was giving parse error in the namespace std _GLIBCXX_VISIBILITY(default) somewhere, so the symbols were not being found.
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)?
I second that request.
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?
Yes please - lets get the basic functionality in and we can enhance. Between now and (approx) early Sept it is really easy to refactor as needed as nothing is API even.
Jonah
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
