Closed jmbalasalle closed 9 months ago
I also face a similar issue. Any help would be appreciated.
Hey guys, does, by any chance, running a normal build after running this tool make the error go away again? (And then does running the tool again make the error come back?)
I'm trying to determine if this is the same underlying issues as #140. If so, we're hoping to land a fix in Bazel, soon. I put up a PR over at https://github.com/bazelbuild/bazel/pull/20540 that should fix. Any amount you'd like to chime in over there to encourage merging would be much appreciated :)
That still doesn't answer why we're getting a compile_command entry for glog at the wrong path. I'm still at a loss there, because it's doing the right thing in my test repo. We'll need to look at the contents of bazel-out/k8-fastbuild/bin/_objs/main/main.pic.d and bazel-out/k8-fastbuild/bin/_objs/main/main.pic.o.hedron.compile-commands.headers.
Sorry to have been so slow in getting to this; I've just been totally underwater with other tasks. Glad the tool has been otherwise useful in the meantime.
Cheers, Chris
Re the entry for glog/logging.h at the wrong path: I've tracked that down and fixed the subtle bug there. Thank you for reporting!
Hi @cpsauer. Happy New Year! I had some time to look at this. I think the original problem (logging.h) has been fixed, but now I see a different problem - my editor (emacs + lsp + clangd) indicates the following:
In included file: 'glog/platform.h' file not found [pp_file_not_found]
I don't see the incorrect path in compile_commands.json anymore. The new offending file (platform.h) also appears correct in compile_commands.json. However, the file it points to is a link - and the target file does not exist.
(base) ➜ glog_test grep "platform.h" compile_commands.json
"file": "bazel-out/k8-fastbuild/bin/external/com_github_google_glog/_virtual_includes/glog/glog/platform.h",
(base) ➜ glog_test ls -l bazel-out/k8-fastbuild/bin/external/com_github_google_glog/_virtual_includes/glog/glog/platform.h
lrwxrwxrwx 1 myuser myuser 158 Jan 8 12:14 bazel-out/k8-fastbuild/bin/external/com_github_google_glog/_virtual_includes/glog/glog/platform.h -> /home/homedir/.cache/bazel/_bazel_user/1156eecec01e9147beb94486bd4b5613/execroot/__main__/external/com_github_google_glog/src/glog/platform.h
And here we see the file doesn't actually exist:
(base) ➜ glog_test ls -altr /home/homedir/.cache/bazel/_bazel_jamesbalasalle/1156eecec01e9147beb94486bd4b5613/execroot/__main__/external/com_github_google_glog/src/glog/platform.h
ls: cannot access '/home/homedir/.cache/bazel/_bazel_user/1156eecec01e9147beb94486bd4b5613/execroot/__main__/external/com_github_google_glog/src/glog/platform.h': No such file or directory
Here are all my files that I used to produce this:
WORKSPACE
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
#http_archive(
# name = "com_google_googletest",
# urls = ["https://github.com/google/googletest/archive/45804691223635953f311cf31a10c632553bbfc3.zip"],
# strip_prefix = "googletest-45804691223635953f311cf31a10c632553bbfc3",
#)
http_archive(
name = "com_github_gflags_gflags",
sha256 = "34af2f15cf7367513b352bdcd2493ab14ce43692d2dcd9dfc499492966c64dcf",
strip_prefix = "gflags-2.2.2",
urls = ["https://github.com/gflags/gflags/archive/v2.2.2.tar.gz"],
)
http_archive(
name = "com_github_google_glog",
sha256 = "122fb6b712808ef43fbf80f75c52a21c9760683dae470154f02bddfc61135022",
strip_prefix = "glog-0.6.0",
urls = ["https://github.com/google/glog/archive/v0.6.0.zip"],
)
# Hedron's Compile Commands Extractor for Bazel
# https://github.com/hedronvision/bazel-compile-commands-extractor
http_archive(
name = "hedron_compile_commands",
url = "https://github.com/hedronvision/bazel-compile-commands-extractor/archive/f41ec092c76458374900242e0d6ed5e96f4e3a21.tar.gz",
strip_prefix = "bazel-compile-commands-extractor-f41ec092c76458374900242e0d6ed5e96f4e3a21",
# When you first run this tool, it'll recommend a sha256 hash to
# put here with a message like: "DEBUG: Rule
# 'hedron_compile_commands' indicated that a canonical
# reproducible form can be obtained by modifying arguments sha256
# = ..."
)
load("@hedron_compile_commands//:workspace_setup.bzl", "hedron_compile_commands_setup")
hedron_compile_commands_setup()
load("@hedron_compile_commands//:workspace_setup_transitive.bzl", "hedron_compile_commands_setup_transitive")
hedron_compile_commands_setup_transitive()
load("@hedron_compile_commands//:workspace_setup_transitive_transitive.bzl", "hedron_compile_commands_setup_transitive_transitive")
hedron_compile_commands_setup_transitive_transitive()
load("@hedron_compile_commands//:workspace_setup_transitive_transitive_transitive.bzl", "hedron_compile_commands_setup_transitive_transitive_transitive")
hedron_compile_commands_setup_transitive_transitive_transitive()
BUILD
cc_binary(
name = "main",
srcs = ["main.cc"],
deps = ["@com_github_google_glog//:glog"],
)
main.cc
#include <glog/logging.h>
int main(int argc, char** argv)
{
google::InitGoogleLogging(argv[0]);
LOG(INFO) << "this is a log message";
return 0;
}
Oh, and to answer your question: Yes! doing a normal build bazel build main
does make the file actually exist and the problem go away.
From that other issue, sounds like I need to wait for the bazel PR to be merged?
Thanks for giving it a thorough test, and for all your great detailed reporting that helped track things down! Happy New Year to you, too :) Appreciate your helping leave things better than you found them.
Yes, to resolve the _virtual_includes-requiring-rebuild issue, we need to get https://github.com/bazelbuild/bazel/pull/20540 merged to fix the rebuild problem, unfortunately :/ For now, just run that build after the tool--hopefully with the outpouring of support (yours included and much appreciated!) it won't be too much longer until they merge and release.
Thank you very much for fixing this issue and creating this wonderful tool. Emacs + lsp makes me oh so happy!
:) you're very welcome, James
Any chance I could ask you to contribute back by adding emacs instructions to the readme, especially if there are gotchas that people should know?
I don't mind but, in this case, I have nothing for my emacs config. I do everything from the command line. The rest of the setup just follows what's available on the emacs-lsp page: emacs lsp.
The fix has made it into the bazel mainline!
Thanks for helping track this down and get it in--should be released as part of Bazel 7.1 and the next rolling release!
Re emacs: Would still love it if you'd add links and or a walkthrough, doubly if there's something parallel people need to do to specify the clangd flags!
I've been using the extractor for a while now, and it has been working very well - thank you!
I just added the Google logger,
glog
, as a dependency to one of my applications. When I run the extractor, it seems to find the correct file ("logging.h") but the path is wrong. I created a simple reproduce case.BUILD
main.cc
Then I run:
bazel run @hedron_compile_commands//:refresh_all
When I open the code emacs/clangd complain that "logging.h" cannot be found. Now, looking in the resulting compile_commands.json file I see entries for "logging.h":
The file name
glog/logging.h
looks incorrect to me. I would expect it to be somewhere underexternal/
. The code compiles and runs just fine.I'm using bazel version:
bazel 6.2.0- (@non-git)
on Ubuntu 22.04, with gcc 11.3.0. I also tested on my Mac - same thing.The strange thing is this: when I first tried this it didn't work in my larger codebase, so then I built this smaller test example and it worked fine. I then modified this smaller one to be closer to my larger one (added
gtest
in the WORKSPACE file, for example), and it broke. But now, I can't make it work even starting from scratch again.I just followed the instructions here (https://github.com/google/glog#bazel) to add
glog
.If anyone has time to look into it, I'd appreciate it. Other than this one issue, your tool has definitely helped my development environment - thank you!