search

hedronvision / bazel-compile-commands-extractor

Goal: Enable awesome tooling for Bazel users of the C language family.
Other
689 stars 114 forks source link

Rules for dependencies using include_prefix are fragile in Bazel 6 #133

Closed jemeador closed 9 months ago

jemeador commented 1 year ago

See https://github.com/jemeador/bazel-compile-commands-extractor-bazel-6-include-prefix-bug for a minimal reproducible example.

Merely running the compile commands extractor invalidates the build flags as the symlink destinations in the execroot get replaced. The generated compile commands worked in Bazel 5.4.1 because the headers in bazel-out would stick around. In Bazel 6 they are symbolic links to temporary files in execroot. This is still a problem in Bazel 6.2.0.

I'm also noticing this is a problem for some third-party dependencies, but using includes = ['.'] is more palatable in that situation.

tervay-bdai commented 1 year ago

Bumping as this is a pain point for us. We're consuming a third party library where we are writing the Bazel rules for ourselves:

cc_library(
  name = "foo",
  hdrs = ["src/foo/a.h"],
  srcs = ["src/foo/a.c"],
  include_prefix = "lib/",
  strip_include_prefix = "src/",
)

The third party library imports as lib/foo/a.h so we need to use the prefix options (unless there is another way I am missing).

jinchengJL commented 1 year ago

Hi, I'm also affected by this problem. It would be great to get some insight as to why this would happen. I'm using this tool primarily to run clang-tidy on some C++ code, and for targets that depend on bazel-native 3rd-party libraries that use include_prefix, clang-tidy is unable to find the includes.

In the meantime, I think I've also found the following to be a workaround: instead of building the targets and then running the compile commands extractor, invert the bazel command order and build the targets after generating compile commands. This seems sufficient for the clang-tidy use case.

Hope this helps.

cpsauer commented 10 months ago

Hey guys--sorry for being so slow in getting to this; I've just been totally underwater with other urgent tasks.

The good news is that a fix should be on its way. I put up a PR over at https://github.com/bazelbuild/bazel/pull/20540. Any amount you'd like to chime in over there to encourage merging would be much appreciated :)

140 and #147 are the same underlying issue, I think.

cpsauer commented 9 months ago

The fix has made it into the bazelbuild mainline!

Thanks all for helping track this down and get it in--should be released as part of Bazel 7.1 and the next rolling release!