Skip to content
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

Subworkspaces causes errors in result of bazel query command #13545

Open
akstr opened this issue May 31, 2021 · 5 comments
Open

Subworkspaces causes errors in result of bazel query command #13545

akstr opened this issue May 31, 2021 · 5 comments
Labels
not stale Issues or PRs that are inactive but not considered stale P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug

Comments

@akstr
Copy link

akstr commented May 31, 2021

Description of the problem / feature request:

We have subworkspaces in our project and that causes problems for us with the query command.
We have noticed that bazel does not detects that there is a subworkspace and instead just treat it as
packages belonging to the workspace above.
The problem comes when the target is addressed as @repo1//... and if there is a subrepo @repo2 is is just
treated as packages beloning to repo1.

More detailed description below

Example 1:

Our test project:


Norden/
├── BUILD
├── HelloNorden.cc
├── HelloNorden.hh
├── WORKSPACE
└── World
    ├── BUILD
    ├── HelloWorld.cc
    ├── HelloWorld.hh
    ├── Universe
    │   ├── BUILD
    │   ├── HelloUniverse.cc
    │   ├── HelloUniverse.hh
    │   ├── WORKSPACE
    │   └── foo.bzl
    └── WORKSPACE

>more Norden/WORKSPACE
local_repository(
    name = "europe",
    path = "../Europe",
)

local_repository(
    name = "world",
    path = "World",
)

>more Norden/BUILD
cc_binary(
    name = "HelloNorden",
    srcs = ["HelloNorden.cc", "HelloNorden.hh"],
    deps = ["@europe//:HelloEurope", "@world//:HelloWorld"],
    visibility = ["//visibility:public"],
)

>more Norden/World/WORKSPACE
 <empty>

>more Norden/World/BUILD
cc_library(
    name = "HelloWorld",
    srcs = ["HelloWorld.cc"],
    hdrs = ["HelloWorld.hh"], 
    visibility = ["//visibility:public"],
    
)

We are running from the the directory bazel:

>more WORKSPACE
local_repository(
    name = "world",
    path = "../../bbi/testarea/tutorialFromBazel/54322/Norden/World",
)

local_repository(
    name = "norden",
    path = "../../bbi/testarea/tutorialFromBazel/54322/Norden",
)

The following commands gives different results:


>bazel query 'attr(visibility, "//visibility:public",@norden//...)'
@norden//World:HelloWorld
@norden//:HelloNorden
Loading: 2 packages loaded

>cd cd  ../../bbi/testarea/tutorialFromBazel/54322/Norden/
>bazel query 'attr(visibility, "//visibility:public",//...)'
//:HelloNorden
Loading: 1 packages loaded


The different targets @norden//... and //... gives different results. //... gives only result from Norden,
@norden//:HelloNorden
while @norden//... gives
@norden//World:HelloWorld
@norden//:HelloNorden

When reading about bazel, we get the impression that both these should give the same result: @norden//:HelloNorden

Example 2:

In our project we run into an error when running the command in another project:

bazel query 'attr(visibility, "//visibility:public", @bbi//...)'

>bazel query 'attr(visibility, "//visibility:public", @bbi//...)'
 ERROR: error loading package '@bbi//tools/cda/cda_fludm': cannot load '@bbi//:cda.bzl': no such file
 Loading: 11 packages loaded
   currently loading: @bbi//tutorials/tutorialUBSan/flex ... (25 packages)
     Fetching @svp; fetching ]
    Fetching @fader2_sdk; fetching
     Fetching @cda_server; fetching

 bbi (contains WORKSPACE )
  |
    - tools
        |
        - cda (contains WORKSPACE)  
             |
              - cda.bzl
              - cda_fludm (BUILD contains that following statement load("//:cda.bzl", "cda_module"))

The reason for the error is that bazel does not detect that cda is it own workspace.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Running the command in a workspace containing a subworkspace

What operating system are you running Bazel on?

Linux

What's the output of bazel info release?

development version

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

Cloned the bazel repo and comiled it

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

facc7d5
4fd8e562a061dd6b1481ed034f276a6d41d70507

Have you found anything relevant by searching the web?

No

Any other information, logs, or outputs that you want to share?

Replace these lines with your answer.

If the files are large, upload as attachment or provide link.

@sventiffe sventiffe added team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website untriaged labels Jun 18, 2021
@eustas
Copy link

eustas commented Jun 21, 2021

Similar problems when using external dependencies.
E.g.:

http_archive(
    name = "hwy",
    url = "https://github.com/eustas/highway/archive/refs/heads/master.zip",
    sha256 = "somehash",
    strip_prefix = "highway-master",
)

in WORKSPACE file will cause problem in BUILD file:

ERROR: /project/BUILD:121:11: error loading package '@hwy//': Unable to find package for @bazel_skylib//lib:selects.bzl: The repository '@bazel_skylib' could not be resolved. and referenced by '//:target'

Unless bazel_skylib is imported again in project WORKSPACE.

@philwo philwo added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. P2 We'll consider working on this in future. (Assignee optional) type: bug and removed untriaged labels Aug 31, 2021
@philwo philwo removed the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Nov 29, 2021
@github-actions
Copy link

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label May 25, 2023
@github-actions
Copy link

github-actions bot commented Jun 8, 2023

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 8, 2023
@eustas
Copy link

eustas commented Jun 8, 2023

Not fixed.

@fmeum
Copy link
Collaborator

fmeum commented Jun 8, 2023

@bazelbuild/triage Not stale, please reopen

@Pavank1992 Pavank1992 reopened this Jun 8, 2023
@Pavank1992 Pavank1992 added not stale Issues or PRs that are inactive but not considered stale and removed stale Issues or PRs that are stale (no activity for 30 days) labels Jun 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not stale Issues or PRs that are inactive but not considered stale P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug
Projects
None yet
Development

No branches or pull requests

6 participants