-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trouble with glog #134
Comments
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 bazelbuild/bazel#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, |
(1) Fix incorrectly assumed fresh cache when (generated) files are missing. See #134 (2) Fall back on stale caches if we fail to get any headers and have some in cache.
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:
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.
And here we see the file doesn't actually exist:
Here are all my files that I used to produce this: WORKSPACE
BUILD
main.cc
|
Oh, and to answer your question: Yes! doing a normal build 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! Yes, to resolve the _virtual_includes-requiring-rebuild issue, we need to get bazelbuild/bazel#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! |
(1) Fix incorrectly assumed fresh cache when (generated) files are missing. See hedronvision/bazel-compile-commands-extractor#134 (2) Fall back on stale caches if we fail to get any headers and have some in cache.
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!
The text was updated successfully, but these errors were encountered: