<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Consider using dot-prefix something like ‘.buildroot’ to hide it from a normal directory listing.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 11, 2018, at 3:41 AM, Sam McCall via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org" class="">clangd-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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 class=""><br class=""></div><div class="">Tools sometimes need to find the build tree.</div><div class="">I'd like to suggest a convention for the Tooling library to support:</div><div class=""> If $SRC/buildroot exists, it's the default build directory for the source tree $SRC.</div><div class=""> Otherwise, the build directory is $SRC itself.</div><div class=""> $SRC/buildroot may be a symlink.</div><div class=""> Configuration files like compile_commands.json are searched for in the build directory.</div><div class="">(Bikeshedding the "buildroot" string is welcome. "build" will conflict too often, sadly).</div><div class=""><br class=""></div><div class="">Implications:</div><div class=""> - for /foo/bar/<a href="http://baz.cc" class="">baz.cc</a>, we'd search for compile_commands.json in {/foo/bar/buildroot/,/foo/bar/, /foo/buildroot/, etc}. This is backwards-compatible.</div><div class=""> - 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 class=""> - 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 class=""> - 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" class="">tinyurl.com/clangd-automatic-index</a>)</div><div class=""> - non-clang tools that consume compile_commands.json will need to be updated over time.</div><div class=""><br class=""></div><div class="">What do you think?</div><div class="">Cheers, Sam</div></div>
_______________________________________________<br class="">clangd-dev mailing list<br class=""><a href="mailto:clangd-dev@lists.llvm.org" class="">clangd-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev<br class=""></div></blockquote></div><br class=""></body></html>