Fix for header-only compile actions by Bazel

[mikael-s-persson]

Fix for header-only compile actions by Bazel

This PR fixes, as far as I can tell, the issues related to #199 where Bazel adds header-only / syntax-only compilation actions that produce dummy output files (.processed). I believe this is part of Bazel open-sourcing more of its capabilities for preprocessing headers and handling pre-compiled modules.

The fix is based on #209 and makes the following changes:

• Adds '.h', '.inl', '.hh', '.hpp', '.hxx' to the list of expected source files for C and C++.
• Add '.processed' to the list of expected output file extensions for compiler actions.
• Removes '-fsyntax-only' or '/Zs' from the compilation arguments when running the preprocessor-only compilation step to silence any warnings about unused compiler arguments.

This fix was tested in this repo: https://github.com/mikael-s-persson/evdevpp
And also tested and used for a while in other private repos.
This seems to produce clean, non-racy outputs. AFAICT, the resulting compile_commands.json file contains everything it should, including the headers.

Fixes #199

[davidzchen]

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

[xFile3160]

LGTM

[mtanida]

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

[LaicepS]

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

[davidzchen]

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

[axbycc-mark]

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

[silversword05]

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

[mrmarkwell]

Please consider merging this fix. Thanks!

[silversword05]

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.

[hhkblogi]

LGTM

[mikael-s-persson]

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

[skrassiev]

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.

[Flash-LHR]

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

[seanngpack]

we good to merge?

[mlyoung101]

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.

[kdowney-lot49]

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.

@mikael-s-persson's bazel_cc_meta worked out of the box for me on a C++23/Bazel 8.5/VSCode project on Linux ARM with multiple dependencies including Abseil and Protobuf, with the caveat that you should force clangd.path to point to the hermetic clangd to ensure toolchain consistency.

E.g. in settings.json:

    "clangd.path": "${workspaceFolder}/external/toolchains_llvm++llvm+llvm_toolchain/bin/clangd",

YMMV, but it is worth a try if you are seeing issues similar to this one (as I was).

[helly25]

Hi — since upstream has been quiet for some time, the fork at https://github.com/helly25/bazel-compile-commands-extractor has picked up this functionality via the parallel #209 (which is similar in intent and was a touch further along).

Backported in helly25#2. Thanks for the original patch.