<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Oct 11, 2018 at 12:50 PM Roman Lebedev <<a href="mailto:lebedev.ri@gmail.com">lebedev.ri@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Oct 11, 2018 at 1:42 PM Sam McCall via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> 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).<br>
><br>
> Tools sometimes need to find the build tree.<br>
> I'd like to suggest a convention for the Tooling library to support:<br>
>     If $SRC/buildroot exists, it's the default build directory for the source tree $SRC.<br>
>     Otherwise, the build directory is $SRC itself.<br>
>     $SRC/buildroot may be a symlink.<br>
>     Configuration files like compile_commands.json are searched for in the build directory.<br>
> (Bikeshedding the "buildroot" string is welcome. "build" will conflict too often, sadly).<br>
Is "buildroot" supposed to be a hardcoded constant?<br></blockquote><div>Yes, I don't mind what the constant is, but this needs to be a constant for the discovery to work.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Personally, i have never ever named any of my build dirs that. They<br>
were always named "build".<br></blockquote><div>Unfortunately people also name other types of directories "build", such as those containing checked-in build scripts.</div><div>If you had a project set up with your build-dir as $SRC/build, then you'd need to ln -s $SRC/build $SRC/buildroot.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, what if there are multiple build trees - build-clang-release,<br>
build-gcc-release, ... ?<br></blockquote><div>Source-based tools (clang-tidy, code completion, etc) need to be able to pick a default configuration without user interaction, for usability.</div><div>You should symlink one of these to $SRC/buildroot, to use as the default. Tools should provide some way to override this default.</div><div>(Possibly CMake etc could create this symlink if it doesn't exist, i.e. when you create the first build dir).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Implications:<br>
>  - 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.<br>
>  - 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.<br>
>  - if we implement e.g. a Ninja-backed compilation DB that doesn't need compile_commands.json, the same symlink convention would work.<br>
>  - 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" rel="noreferrer" target="_blank">tinyurl.com/clangd-automatic-index</a>)<br>
>  - non-clang tools that consume compile_commands.json will need to be updated over time.<br>
><br>
> What do you think?<br>
> Cheers, Sam<br>
Roman.<br>
<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>