Closed jmbalasalle closed 8 months ago
Hey James :)
It must be that it's inferring system python, right? (We aren't actually using system python for this tool anymore, but rather hermetic 3.11, as per that PR you linked.)
I'm not totally sure, but I'm going to guess that maybe pybind does an internal transition to configure its python version, if not using the system one. If you haven't already, would you be down to try using a refresh_compile_commands rule to point this tool to you your top-level target (this section of the readme) and see if that works? That'd cause it to pick up any configuration transitions applied in your normal build.
Cheers, Chris
FYI: Reverted rules_python in https://github.com/hedronvision/bazel-compile-commands-extractor/commit/0b821b7e4286aec887757461366f6eaaa0972cb9 because of lots of issues :( Tracking restoration in https://github.com/hedronvision/bazel-compile-commands-extractor/issues/168.
After all the recent updates to this tool, as well as cleaning up my own WORKSPACE file, I am no longer having this issue. It was likely operator error anyway.
Hello again! I'm having trouble with python versions.
I'm seeing the same issue that was reported here: https://github.com/hedronvision/bazel-compile-commands-extractor/pull/139
When I run
bazel run @hedron_compile_commands//:refresh_all
I see the following:I cannot, for the life of me, figuring out how it's picking up this ancient version of python. I don't even have a version that old installed. I'm using Ubuntu 20.04.
I'm using the latest commit, 199ca857b05a7a4dbb332e8d229158feb3f82638. Here is the relvant section of my WORKSPACE file:
The bazel target in question builds just fine from the command line.
I still get the resulting
compile_commands.json
file and it seems fine. So this is not really an issue, but I'm curious what you think.