<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Howdy,<br>
</p>
<p>the "domain" of the two tools compiler and language server are
completely different, where the former usually lives in the
build-tree, the latter usually lives with the user inside the
source tree... So I would argue that the default lookup rather
becomes the unusual case...</p>
<p>That being said, after long hard times the CMakeTools developer
together with the Microsoft C++ extension team came up with an
approach exactly like you depict somewhere around mid-year. But
since the MS Extensions don't support "find references", it was
still useless - which is why I'm currently using cquery. I bet it
would be an easy thing to click into that interfacing for the
clangd extension as well.</p>
<p>Regards,<br>
Michael<br>
</p>
<div class="moz-cite-prefix">Am 29.11.2018 um 17:36 schrieb Anton
Södergren via clangd-dev:<br>
</div>
<blockquote type="cite"
cite="mid:CAMLD8zqok8HNruMy3gjAyUaot6uCjtbBrFJ3UaapGun3ELpmnA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="auto">
<div dir="ltr">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
But in VSCode, the build system is just another plugin
that may or may not be installed, so a decoupled design
seems most likely to work in many configurations.
</div>
</blockquote>
<div>If we could find a solution, it would of course be
completely optional. Clangd would use its normal discovery
mechanism of compile_commands.json, unless another plugin
tells it to use a specific file or build dir. Maybe the
build system extension could even give Clangd separate
info for each C++ file if we want to be really flexible,
but again, I don't know exactly how that info would be
sent to Clangd. I agree that it's not reasonable that this
info would be shared between different projects.<br>
</div>
<div><br>
</div>
<div>Something like this would be ideal:<br>
<ol>
<li>User opens a folder</li>
<li>CMake runs</li>
<li>A compile_commands.json is generated</li>
<li>CMake Tools somehow tells Clangd where to find the
file (this one is where the problem lies)<br>
</li>
<li>Repeat steps 2-4 whenever CMake needs to generate
again<br>
</li>
</ol>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
Clangd needs to be able to determine the compile command
given a filename, at any time, within the clangd process
(i.e. without exchanging LSP messages with the editor).
</div>
</blockquote>
<div>I'll admit that this sounds rather tricky. But the
build plugin would only need to notify Clangd when it
actually generates its compile_commands.json, after which
Clangd could keep and reuse that state.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
It is in fact possible as a command flag (it's spelled
-compile-commands-dir).
</div>
</blockquote>
<div>Would this only be passed once when the process starts
and then never touched again? If so, then yeah this
obviously doesn't work.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
each tool (clangd, clang-tidy etc) needs to get this
configuration in some appropriate way, it's not shared
(whereas all clang-based tools share discovery logic for
compile_commands.json)
</div>
</blockquote>
<div>Yeah, this does sound like a scalability issue if a
user wants to use multiple Clang tools, as the build
system extension would have to communicate with every one
of them.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
Maybe one idea is to stick to compile_commands.json but
extend the way they are discovered, e.g. let the Cmake
Tools plugin notify Clangd that a certain
compile_commands file is relevant and should be
considered, even if it's not in an ancestor dir of the
source file.</div>
</blockquote>
<div>This sounds like a fairly reasonable compromise. But
then again, we would still need a way for the build system
extension to communicate this to Clangd.</div>
<div><br>
</div>
<div>Given the following circumstances:</div>
<div>
<ul>
<li>There is always only one Clangd instance which is
shared between different projects/folders</li>
<li>Command line arguments can only be passed to Clangd
when launching it</li>
<li>Command line arguments passed to Clangd will affect
all different projects/folders</li>
<li>The only ways for VSCode to communicate with Clangd
after launching it is via LSP or files that both
VSCode and Clangd already know about</li>
<li>LSP can not be used for this purpose</li>
</ul>
<div>then this problem might not actually be possible to
solve.
If all of this would mean completely redesigning the way
that Clangd is invoked, then yeah maybe generating a
symlink is the only way to go about this. I'm still not
fond of polluting the source tree with something that is
not super obvious that it was generated by an IDE/editor
or what generated it, but maybe this is just an inherent
downside of using LSP rather than an integrated C++
library (not trying to discredit your work, it's still a
great project!)...<br>
</div>
<div>
<div>Then the question is how the build system extension
would decide where to put the symlink. Would it always
end up in the root folder? Or something like
CMAKE_SOURCE_DIR (these two are often the same, but I
guess it's a good idea to be specific)? What did you
mean by symlinking src/.build to build/? Sorry, I
never really use symlinks so I'm not very familiar
with them. It seems like CMake tool actually has a
config option to place a copy (not a symlink) of
compile_commands.json in a path specified by the user
in the config. Though I think this has to be done
automatically without the user having to go into the
config and set it up, maybe after clicking a "yes"
button that pops up in VSCode or something. Otherwise
most users will probably just assume that the two
plugins simply don't work well together (like I did).
Could even have a notification to warn the user to
include the file in their VCS ignore file. Of course,
this is in the hands of CMake Tools and other build
system extensions, just thought it was relevant to the
discussion.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<div dir="auto">It's... not trivial. (Other clang
tools don't handle this as they tend to be batch)</div>
<div dir="auto">So we'll fix it, but it might take a
little time :-)</div>
</div>
</blockquote>
<div>I'm not too worried about time, just good to hear
that someone is working on it. :)</div>
<div><br>
</div>
<div><br>
</div>
<div> <br>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, 28 Nov 2018 at 23:59, Sam McCall <<a
href="mailto:sammccall@google.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">sammccall@google.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>
<div class="gmail_quote">
<div dir="ltr">On Wed, Nov 28, 2018, 23:00 Anton
Södergren <<a
href="mailto:anton.sodergren@gmail.com"
rel="noreferrer" target="_blank"
moz-do-not-send="true">anton.sodergren@gmail.com</a>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
I'm not familiar with CMake Tools, I guess it
helps with editing CMakeLists, CMake configs,
and running configure/generate?</blockquote>
<div>Except for the file editing part (that's
handled by another extension), you're pretty
much right. It also allows for building and
launching debuggers. But it's the
configure/generate part that's the most
interesting in our case.</div>
<div><br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
Clangd works like other clang-based tools.
Starting at the source file in question, it
walks up directories until it finds <a
href="https://clang.llvm.org/docs/JSONCompilationDatabase.html"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">compile_commands.json</a>.<br>
</div>
</blockquote>
<div>So it turned out that it indeed seemed to
generate a compile_commands.json file in the
build folder (at least yesterday, today it
doesn't seem to work well at all). I tried
copying that file over to my project root
folder and Clangd found it and started working
correctly indeed!</div>
<div><br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
The current best-practice is to manually
create a symlink src/compile_commands.json
-> build/compile_commands.json. I think
symlinking src/.build to build/ is a
slightly more principled approach, but
something still has to create a symlink.
(Maybe we could get CMake or CMake Tools to
do it?)</div>
</blockquote>
<div>While this is a possible approach, I think
is sounds a little unwieldy (though that might
just be personal preference). When I looked
around a bit more, I saw that the <a
href="https://clang.llvm.org/docs/HowToSetupToolingForLLVM.html"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">Clang tooling docs</a>
mentioned that it's possible to pass the build
path directly to Clang tools with a -p
parameter, is this possible in Clangd too?</div>
</div>
</blockquote>
</div>
</div>
<div dir="auto">It is in fact possible as a command flag
(it's spelled -compile-commands-dir). It works in a
pinch, but it's a subtly broken idea and I don't think
it's the right long-term direction.</div>
<div dir="auto"><br>
</div>
<div dir="auto">1) a clangd instance is typically 1:1
with an editor session. But an editor can open files
from multiple projects, so what should the flag value
be?</div>
<div dir="auto">2) how does the editor know which dir to
pass to clangd? If it's an editor preference, how does
this work for users who work in different projects at
different times?</div>
<div dir="auto">3) each tool (clangd, clang-tidy etc)
needs to get this configuration in some appropriate
way, it's not shared (whereas all clang-based tools
share discovery logic for compile_commands.json)</div>
<div dir="auto"><br>
</div>
<div dir="auto">Requiring the symlink (and adding it to
gitignore etc) is a little fiddly and certainly
unconventional, but it's the best thing we've found so
far.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div> For example, other IDE's that utilize
clang-tidy (e.g. CLion) seem to do so without
any visible symlinks.</div>
</div>
</blockquote>
</div>
</div>
<div dir="auto">Yes, if you're an IDE that already knows
how to build the code (has opinions/integrations for
the build system) then directly injecting the
configuration is feasible. (Clangd has LSP extensions
for this). But in VSCode, the build system is just
another plugin that may or may not be installed, so a
decoupled design seems most likely to work in many
configurations.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div> To me, that sounds more robust and clean
than having to pollute the source tree with
symlinks. Of course, that would require some
work probably on both of the plugins involved.
Also, having a general and flexible approach
for this would be nice, as I'm also interested
in getting work on a build2 extension going,
which would require the same functionality.</div>
</div>
</blockquote>
</div>
</div>
<div dir="auto">Definitely open to new ideas here, but
I'm not sure exactly what you're proposing.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Clangd needs to be able to determine the
compile command given a filename, at any time, within
the clangd process (i.e. without exchanging LSP
messages with the editor).</div>
<div dir="auto"><br>
</div>
<div dir="auto">Maybe one idea is to stick to
compile_commands.json but extend the way they are
discovered, e.g. let the Cmake Tools plugin notify
Clangd that a certain compile_commands file is
relevant and should be considered, even if it's not in
an ancestor dir of the source file.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
clangd has to reload the data when
appropriate. Today, it caches forever :-(
Ilya is working on fixing it!
</div>
</blockquote>
<div>I did notice this problem when testing it
out yesterday. But I trust that it will get
fixed then!</div>
</div>
</blockquote>
</div>
</div>
<div dir="auto">It's... not trivial. (Other clang tools
don't handle this as they tend to be batch)</div>
<div dir="auto">So we'll fix it, but it might take a
little time :-)</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>Cheers,</div>
<div>Anton<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, 27 Nov 2018 at 20:25, Sam
McCall <<a
href="mailto:sammccall@google.com"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">sammccall@google.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Tue, Nov 27, 2018 at
8:09 PM Anton Södergren via clangd-dev
<<a
href="mailto:clangd-dev@lists.llvm.org"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">clangd-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Hello! I'm not sure if this
is the best place to ask, but
it's better to get a discussion
going rather than just being
confused.</div>
</div>
</div>
</div>
</blockquote>
<div>Right place! Welcome :-)</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>I tried using Clangd in
Visual Studio Code, but noticed
that it doesn't integrate well
with the CMake Tools extension,
which makes it hard to use
together with a CMake workflow.
I would like a way for Clangd to
automatically get the correct
info when CMake runs in the
editor.</div>
<div>Specifically, I want seamless
and automatic integration
between these two extensions
without the user having to do
any additional config:</div>
<div>
<ul>
<li>vscode-clangd (<a
href="https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.vscode-clangd"
rel="noreferrer
noreferrer"
target="_blank"
moz-do-not-send="true">https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.vscode-clangd</a>)<br>
</li>
<li>CMake Tools (<a
href="https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools"
rel="noreferrer
noreferrer"
target="_blank"
moz-do-not-send="true">https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools</a>)</li>
</ul>
</div>
</div>
</div>
</div>
</blockquote>
<div>I'm not familiar with CMake Tools, I
guess it helps with editing CMakeLists,
CMake configs, and running
configure/generate?</div>
<div>(Sorry, I would dig into it, about to
head out on vacation)</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>
<div>I see three possible
approaches for this:</div>
<div>
<ol>
<li>Work with the author of
CMake Tools to make the
extension generate the
appropriate info for
vscode-clangd</li>
<li>Make vscode-clangd
retrieve the info from
CMake Tools somehow</li>
<li>Create a new extension
that acts as a bridge
between the two</li>
</ol>
<div>Or alternatively, some
combination of the different
approaches.</div>
<div>I know that the CMake
Tools extension integrates
well with Microsoft's C/C++
extension, so maybe it would
be a good idea to do this in
a similar way that they did
it. If my understanding is
correct, a separate bridge
extension was previously
used for this, but I think
they now use a combination
of something similar to
approach 1 and 2 for the
extensions to communicate
with each other.</div>
<div>I would be interested to
hear what you all think
would be the best way to go
about this, and maybe I can
get in touch with
vector-of-bools (the author
of the CMake Tools
extension) about it too.<br>
</div>
<div><br>
</div>
<div>Another question I had
regarding this: how does
Clangd find the correct
include paths and other info
in the first place? Does it
use some kind of compilation
commands file for this? Is
it possible to tell Clangd
where to look for such a
file? I couldn't really find
any documentation about this
when I looked around.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>So if my understanding of CMake Tools
is correct, these questions are very
much related :-)</div>
<div><br>
</div>
<div>Clangd works like other clang-based
tools. Starting at the source file in
question, it walks up directories until
it finds <a
href="https://clang.llvm.org/docs/JSONCompilationDatabase.html"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">compile_commands.json</a>.
This lists the flags required to compile
each file in its scope.</div>
<div><br>
</div>
<div>So I think there are three relevant
parts here:</div>
<div>
<ul>
<li>this file has to be created
somehow. CMake can do this, it's
controlled by <a
href="https://cmake.org/cmake/help/v3.5/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html"
rel="noreferrer noreferrer"
target="_blank"
moz-do-not-send="true">CMAKE_EXPORT_COMPILE_COMMANDS</a>,
which I believe is on by default
now. It writes the files into the
root of the build tree.</li>
<li>the file has to be discovered
somehow (if the CMake build tree !=
the source tree). The current
best-practice is to manually create
a symlink src/compile_commands.json
-> build/compile_commands.json. I
think symlinking src/.build to
build/ is a slightly more principled
approach, but something still has to
create a symlink. (Maybe we could
get CMake or CMake Tools to do it?).
Or maybe there's some other clever
way to find the build tree.</li>
<li>clangd has to reload the data when
appropriate. Today, it caches
forever :-( Ilya is working on
fixing it!</li>
</ul>
<div>Gotta run, hope this helps!</div>
</div>
<div>Patches and ideas welcome :-)</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
clangd-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:clangd-dev@lists.llvm.org">clangd-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a>
</pre>
</blockquote>
</body>
</html>