<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Oct 11, 2018 at 5:40 PM Doug Schaefer <<a href="mailto:dschaefer@blackberry.com">dschaefer@blackberry.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-9215925879189674674WordSection1">
<p class="MsoNormal">+1, been thinking about this as well as I end up setting –compile-commands-dir all the time as a big user of cmake. And I’m on Windows where symlinks are generally suspect. clangd doing this for us would be definitely helpful.</p></div></div></blockquote><div>Just trying to unpack this a bit:</div><div> - today, it's possible to get this to work by symlinking src/compile_commands.json -> build/compile_commands.json. I'm proposing to generalize this by supporting symlinking src/buildroot -> build/. But if symlinks don't work for you now, I don't think this would fix that problem.</div><div> - you could indeed put your physical build dir in src/buildroot, though obviously this limits your flexibility.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-9215925879189674674WordSection1">
<p class="MsoNormal">Though, one for the bikeshed. As an example, the llvm .gitignore suggests using /build, as do many other projects. I’m just wondering if the cost of conflicts outweighs the convenience of not having to change.</p></div></div></blockquote><div>So we could check src/build and if there's no CDB there, fall back to checking src/.</div><div>The problem is I don't know what projects that have an existing src/build and also use an external build dir are supposed to do. Chromium is one such project. The cost is probably *also* adding a fallback to src/buildroot, which increases the number of stats we need to do when walking up from your source files to find the root.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-9215925879189674674WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Doug.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>From:</b> clangd-dev <<a href="mailto:clangd-dev-bounces@lists.llvm.org" target="_blank">clangd-dev-bounces@lists.llvm.org</a>> <b>
On Behalf Of </b>Sam McCall via clangd-dev<br>
<b>Sent:</b> Thursday, October 11, 2018 6:42 AM<br>
<b>To:</b> clang developer list <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>; <a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a><br>
<b>Subject:</b> [clangd-dev] Tooling RFC: Find build root from source root with a symlink?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Many projects/build systems have the concept of a "build tree" that can be separate from the source tree. (e.g. CMake supports this, and LLVM recommends this approach).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Tools sometimes need to find the build tree.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I'd like to suggest a convention for the Tooling library to support:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">    If $SRC/buildroot exists, it's the default build directory for the source tree $SRC.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">    Otherwise, the build directory is $SRC itself.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">    $SRC/buildroot may be a symlink.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">    Configuration files like compile_commands.json are searched for in the build directory.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">(Bikeshedding the "buildroot" string is welcome. "build" will conflict too often, sadly).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Implications:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - for /foo/bar/baz.cc, we'd search for compile_commands.json in {/foo/bar/buildroot/,/foo/bar/, /foo/buildroot/, etc}. This is backwards-compatible.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - where users currently symlink compile_commands.json itself, they could create the buildroot symlink instead. This would work in the same way, and enable new cases.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - if we implement e.g. a Ninja-backed compilation DB that doesn't need compile_commands.json, the same symlink convention would work.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - it provides a simple model for multi-configuration-aware tools: a configuration is defined by a build dir, there's a default configuration, tools can let the user override the build dir. e.g. clangd can write its index files into the
 build dir instead of the source dir, which is multi-configuration-friendly (<a href="http://tinyurl.com/clangd-automatic-index" target="_blank">tinyurl.com/clangd-automatic-index</a>)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - non-clang tools that consume compile_commands.json will need to be updated over time.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">What do you think?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Cheers, Sam<u></u><u></u></p>
</div>
</div>
</div>
</div>

</blockquote></div></div>