[
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
|
Comments below. I created
https://bugs.eclipse.org/bugs/show_bug.cgi?id=564349 to track the
"generalized compile db access" effort.
Regards,
AF
16.06.2020 16:53, Jonah Graham пишет:
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.
Yes, LSP people do need the access to "compilation database", either
to a parser directly or better to a service that can query
compile_command.json
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.
+1 the earlier we can get it the more chances we have to generalize
and reuase it before 2020-09.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
