Is ready to be committed? Can someone please review this?

Is this ready to be merged? We are running into the same issue...

This worked fine to produce a compilation database on a Abseil library. But I had to patch the refresh.template.py file in the bazel cache by hand. Is there another way (other than waiting for this to be merged)?

@cpsauer could you take a look at this when you have a chance? It would be great to finally get this merged. Thanks in advance.

Simply using @mikael-s-persson 's branch in your MODULE.bazel is a workaround until this gets merged into the main branch.

# Hedron's Compile Commands Extractor for Bazel
# https://github.com/hedronvision/bazel-compile-commands-extractor
bazel_dep(name = "hedron_compile_commands", dev_dependency = True)
git_override(
    module_name = "hedron_compile_commands",
    remote = "https://github.com/mikael-s-persson/bazel-compile-commands-extractor",
    commit = "f5fbd4cee671d8d908f37c83abaf70fba5928fc7"
)

When is this going to be merged? Keep facing the same problems and figuring out these work-arounds.

Please consider merging this fix. Thanks!

bazel_dep(name = "hedron_compile_commands", dev_dependency = True)
git_override(
module_name = "hedron_compile_commands",
remote = "https://github.com/mikael-s-persson/bazel-compile-commands-extractor",
commit = "f5fbd4cee671d8d908f37c83abaf70fba5928fc7"
)

Please merge this.

FYI, people on this thread might be interested in checking out my new repo "bazel_cc_meta" which combines the functionality of this compile-commands-extractor and the depend-on-what-you-use tool into a much more efficient solution (benefits from bazel caching through an aspect-based implementation). It is still highly experimental, needless to say, but we've been using it for a few weeks in a relatively complicated cross-compilation setup. And it should be less brittle to issues like the one that spurred this PR because it can rely on Bazel's own logic to classify sources and headers rather than inferring them externally.

https://github.com/mikael-s-persson/bazel_cc_meta

FYI, people on this thread might be interested in checking out my new repo "bazel_cc_meta" which combines the functionality of this compile-commands-extractor and the depend-on-what-you-use tool into a much more efficient solution (benefits from bazel caching through an aspect-based implementation). It is still highly experimental, needless to say, but we've been using it for a few weeks in a relatively complicated cross-compilation setup. And it should be less brittle to issues like the one that spurred this PR because it can rely on Bazel's own logic to classify sources and headers rather than inferring them externally.

https://github.com/mikael-s-persson/bazel_cc_meta

I tried it and unfortunately it does not generate the proper compile db for the simplest abseil hello world example, at least for clangd based LSP in vim. I.e. firing up vim would immediately report plenty of undefined symbols.

When the project relies on boost.beast, there are still errors.
#249 in detail.

we good to merge?

I apologise if this comes across as rude, but:

This PR was raised more than a full year ago and has not yet been merged. The last non-bot commit to this repository was 1e08f8e in July 2024.

I know the README says:

If there haven't been commits in a while, it's because of stability, not neglect. This is in daily use inside Hedron.

But it's been more than an entire year and this PR, which multiple people have confirmed works, has not been merged. Despite the above, this project is clearly not stable, myself and others (#271, #265, #258, #249, #242) run into this bug immediately on relatively basic projects.

I'm aware of the internal issues (#232), but it has been a full year since that comment with no update. If this PR cannot be merged timely and this repository is indeed abandoned, perhaps it is time to fork. I would offer to do so myself but I'm only a downstream user of Bazel, I don't know enough about the tool itself to maintain a tool of this complexity.