<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Doug.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> clangd-dev <clangd-dev-bounces@lists.llvm.org> <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 <cfe-dev@lists.llvm.org>; clangd-dev@lists.llvm.org<br>
<b>Subject:</b> [clangd-dev] Tooling RFC: Find build root from source root with a symlink?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Tools sometimes need to find the build tree.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I'd like to suggest a convention for the Tooling library to support:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> If $SRC/buildroot exists, it's the default build directory for the source tree $SRC.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> Otherwise, the build directory is $SRC itself.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> $SRC/buildroot may be a symlink.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> Configuration files like compile_commands.json are searched for in the build directory.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(Bikeshedding the "buildroot" string is welcome. "build" will conflict too often, sadly).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Implications:<o:p></o:p></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.<o:p></o:p></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.<o:p></o:p></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.<o:p></o:p></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">tinyurl.com/clangd-automatic-index</a>)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - non-clang tools that consume compile_commands.json will need to be updated over time.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What do you think?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers, Sam<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>