mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-24 21:50:14 +01:00
This restructures the `compile_flags.txt` to use the downloaded libc++ system headers and avoid needing a virtual include directory to be built. It still needs _some_ Bazel build to complete before working in order to have the libc++ system headers downloaded and the symlink to the Bazel tree created. One (very) tricky part of making this work is to work around bugs in Clang's tooling layer that incorrectly handle `..` path components after traversing symlinks. To avoid this, we add a custom symlinks (`bazel-execroot` and `bazel-clang-toolchain`) that hide the relevant traversal of the Bazel layout to find build artifacts and the downloaded toolchain. These symlinks will be broken until a build with Bazel downloads the toolchain and creates the basic output tree structure. It also adds a `create_compdb.py` script. Running this script improves the tooling fidelity by taking a few steps: 1. It queries Bazel to find all the relevant files and adds them to a `compile_commands.json` database that allows `clangd` and other tools to index the entire project for improved cross-references, etc. 2. It builds all the generated files with Bazel so that they can be included successfully. This is very fast in my testing, taking only 10s of seconds. It is also very likely to be cached effectively. 3. It translates the arguments from `compile_flags.txt` to make them persistently use the built generated files include paths so that nothing breaks even as different targets are built potentially with different configurations. There are still some limitations. - It still requires running Bazel before anything works, even if a fast run. - It will require re-running if new generated files are added and needed but not built. - It assumes that the standard Bazel symlink names are used and available. Much of the Python here was written by @geoffromer in #384 -- I've adapted it here after discussing to try to fill in some of the blanks and use a slightly different approach to querying Bazel. I use the normal `bazel query` rather than `bazel aquery`. This, for example, allows the index to reliably cover header files in header-only libraries more directly (rather than relying on transitive inclusion). It also seems a bit simpler too parse, but that is a pretty minor difference. Co-authored-by: Geoffrey Romer <gromer@google.com>
Symbolic link
1 line
22 B
Plaintext
Symbolic link
1 line
22 B
Plaintext
bazel-out/../../carbon |