-
-
Notifications
You must be signed in to change notification settings - Fork 79
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
Warnings from finding build targets #216
Comments
I was able to fix this by deleting the folder listed as the My extension + Bazel info:
Extension
|
Yes, the reason for step (2) in my repro is that you need to have the pulled down and compiled the external deps before you see a failure. A bazel clean also solves the problem, but VSCode immediately starts failing again once you build a target and it has pulled down the external deps. |
I encountered a similar issue. |
I'm using the latest release of rules_jvm_external. |
Try this, it worked for me: You'll need to ensure you name your workspace. To do that put |
For me, this problem was rectified by opening the VSCode Bazel extension settings, finding the "Queries Share Server" checkbox, and ensuring it is ticked (unticked by default). The box has the description: "Use the same Bazel server for queries and builds. By default, vscode-bazel uses a separate server for queries so that they can be executed in parallel with builds. You can enable this setting if running multiple Bazel servers has a negative performance impact on your system, but you may experience degraded performance in Visual Studio Code for operations that require queries." |
see also #261 |
As mentioned in #328 (comment), this seems like an issue with bazel. I'll open an issue there and see what they say. |
Looks like we already have an issue open here actually: bazelbuild/bazel#10653. Considering that issue has been open for 4 years, maybe we could implement a workaround in vscode-bazel. For example, we could pass |
The bazel query used to introspect the targets available incorrectly traverses convenience symlinks when the output base has changed. This is a bug in Bazel (see bazelbuild/bazel#10653). A lot of people are hitting this, since it happens with the default setup of bazel and this plugin. Until it is fixed upstream, this works around this issue by enabling the `queriesShareServer` option by default. Workaround for #216 Co-authored-by: Cameron Martin <cameronmartin123@gmail.com>
This'll be fixed in Bazel 7.1.0. See bazelbuild/bazel#21505 |
Bazel 7.1.0 is now released and I opened #355 to revert the workaround, so I'll close this. |
This reverts commit 64c9d7e. The underlying issue that this addresses is now fixed in Bazel 7.1.0. See #216 and bazelbuild/bazel#21505.
)" This reverts commit 64c9d7e. The underlying issue that this addresses is now fixed in Bazel 7.1.0. See bazel-contrib#216 and bazelbuild/bazel#21505.
I just tried out Bazel for the first time for a Java project and I ran into an issue that I've never seen with C++ and Python projects. Basically, when I try to hit the "refresh" button on the "Bazel build targets" side panel, I get an error popup like the following:
Command failed: bazel --output_base=/var/folders/cj/1fv063dx1772zbpnfpzvj_c00000gn/T/d855bbcad42db418fe212896af750013 query ...:* --output=package Loading: 0 packages loaded ERROR: error loading package 'bazel-bazeljava/external/rules_jvm_external': Every .bzl file must have a corresponding package, but '//:private/versions.bzl' does not have one. Please create a BUILD file in the same or any parent directory. Note that this BUILD file does not need to do anything except exist. Loading: 12 packages loaded currently loading: bazel-bazeljava/external/local_config_cc ... (9 packages) Loading: 12 packages loaded currently loading: bazel-bazeljava/external/local_config_cc ... (9 packages)
The error is slightly different each time and seems to be located in different external packages. Maybe my version of Bazel has some issues with the external dependencies that are being loaded.
Bazel version: 3.5.0
VSCode version: 1.48.2
Steps to reproduce:
I don't see anything wrong with my project WORKSPACE file. If I manually run
bazel query ...:*
in the root, I don't see any errors and all build targets are properly listed. Seems like correct behavior would be for VSCode to list all the local targets in my workspace and not fail because of issues with external dependencies.The text was updated successfully, but these errors were encountered: