Includes point to bazel-out instead of project source code.

[GiulianoWF]

I am setting up a Bazel build system and integrating clangd into my development workflow. My project structure is as follows:

 | main.cc
 | BUILD
 |-base_types
   | BUILD
   | type-string.hpp
 |-units
   |-external-channel
     | external-channel.hpp

My BUILD file for the main executable looks like this:

cc_binary(
   name = "my_project",
   srcs = ["main.cc"],
   deps = [
       "//base_types:base_types",
       "//units/external_codebase:external_codebase",
       "@libssh//:libssh",
   ],
)

The problem I am encountering is that when I try to follow the links in the includes using clangd, I get redirected to the bazel-out directory instead of the actual project files.

The generated compile-commands.json includes the following flags:

[
 {
   "directory": "...",
   "command": "...",
   "file": "...",
   "arguments": [
     ...
     "-Ibazel-out/k8-fastbuild/bin/base_types/_virtual_includes/base_types",
     "-Ibazel-out/k8-fastbuild/bin/units/external_codebase/_virtual_includes/external_codebase",
     "-isystem",
     "bazel-out/k8-fastbuild/bin/external/libssh/libssh/include",
     ...
   ]
 }
]

I would expect the include paths to point to the actual files in my project, like this:

[
 {
   "directory": "...",
   "command": "...",
   "file": "...",
   "arguments": [
     ...
     "-Ibase_types",
     "-Iunits/external_codebase",
     "-isystem",
     "bazel-out/k8-fastbuild/bin/external/libssh/libssh/include",
     ...
   ]
 }
]

Question:
Is there a way to configure Bazel or clangd to get the includes to point to the actual project files instead of the bazel-out directory? Or am I missing something in my setup?

[keith]

My understanding is that bazel always uses _virtual_includes because that is how it prunes the files that can be included to only the ones you define in your hdrs, and this tool is just returning the path that bazel uses. Theoretically these files are just symlinks to the originals, so at least with my testing in neovim with clangd something in the chain is smart enough to just open the actual file, resolving all the symlinks. If I saw more issues with this I would be tempted to post-process the json file to remap these in the way I "know" works. In the case you use include_prefix on cc_library this would be more complicated, but just using includes or strip_include_prefix it could probably be 1:1

[mason-bially]

This seems to be a related issue in .clangd clangd/clangd#197

[mason-bially]

From clangd/clangd#544 it seems like the --path-mappings feature may be somewhat viable. I wonder if we could get these to be extracted and placed somewhere we could use?