[cfe-dev] [clangd-dev] Tooling RFC: Find build root from source root with a symlink?

Doug Schaefer via cfe-dev cfe-dev at lists.llvm.org
Thu Oct 11 08:40:30 PDT 2018


+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.

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.

Doug.


From: clangd-dev <clangd-dev-bounces at lists.llvm.org> On Behalf Of Sam McCall via clangd-dev
Sent: Thursday, October 11, 2018 6:42 AM
To: clang developer list <cfe-dev at lists.llvm.org>; clangd-dev at lists.llvm.org
Subject: [clangd-dev] Tooling RFC: Find build root from source root with a symlink?

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).

Tools sometimes need to find the build tree.
I'd like to suggest a convention for the Tooling library to support:
    If $SRC/buildroot exists, it's the default build directory for the source tree $SRC.
    Otherwise, the build directory is $SRC itself.
    $SRC/buildroot may be a symlink.
    Configuration files like compile_commands.json are searched for in the build directory.
(Bikeshedding the "buildroot" string is welcome. "build" will conflict too often, sadly).

Implications:
 - 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.
 - 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.
 - if we implement e.g. a Ninja-backed compilation DB that doesn't need compile_commands.json, the same symlink convention would work.
 - 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 (tinyurl.com/clangd-automatic-index<http://tinyurl.com/clangd-automatic-index>)
 - non-clang tools that consume compile_commands.json will need to be updated over time.

What do you think?
Cheers, Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181011/3194b41a/attachment.html>


More information about the cfe-dev mailing list