<div dir="ltr"><div>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).</div><div><br></div><div>Tools sometimes need to find the build tree.</div><div>I'd like to suggest a convention for the Tooling library to support:</div><div>    If $SRC/buildroot exists, it's the default build directory for the source tree $SRC.</div><div>    Otherwise, the build directory is $SRC itself.</div><div>    $SRC/buildroot may be a symlink.</div><div>    Configuration files like compile_commands.json are searched for in the build directory.</div><div>(Bikeshedding the "buildroot" string is welcome. "build" will conflict too often, sadly).</div><div><br></div><div>Implications:</div><div> - 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.</div><div> - 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.</div><div> - if we implement e.g. a Ninja-backed compilation DB that doesn't need compile_commands.json, the same symlink convention would work.</div><div> - 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>)</div><div> - non-clang tools that consume compile_commands.json will need to be updated over time.</div><div><br></div><div>What do you think?</div><div>Cheers, Sam</div></div>