bazel: The symlink to exec root seems to be named incorrectly
Description of the problem / feature request:
According to this documentation: https://docs.bazel.build/versions/master/output_directories.html, the symlink to exec root should be named bazel-<workspace-name>, but in practice it’s named bazel-<containing-dir-name>, which may be different.
For example, if I have a WORKSPACE file with this:
workspace(name = "foo")
contained in directory named bar, then inside bar Bazel creates bazel-bar, not bazel-foo as it should.
This is inconvenient sometimes because I don’t see how to get the name of containing directory (bar), while workspace name (foo) is available from ctx.
What operating system are you running Bazel on?
NixOS:
- system:
"x86_64-linux" - host os:
Linux 4.14.48, NixOS, 18.09pre142796.4b649a99d84 (Jellyfish) - multi-user?:
yes - sandbox:
no - version:
nix-env (Nix) 2.1pre6148_a4aac7f - channels(root):
"nixos-18.09pre142796.4b649a99d84"warning: Nix search path entry ‘/home/mark/.nix-defexpr/channels’ does not exist, ignoring - nixpkgs:
/nix/var/nix/profiles/per-user/root/channels/nixos
What’s the output of bazel info release?
release 0.12.0- (@non-git)
If bazel info release returns “development version” or “(@non-git)”, tell us how you built Bazel.
Got it from nix.
Have you found anything relevant by searching the web?
No.
Any other information, logs, or outputs that you want to share?
No.
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 1
- Comments: 23 (14 by maintainers)
This is definitely a pain point. My strong preference is for the symlink to be a predictable bazel-<workspace-name> (whatever I put in the WORKSPACE file as workspace(name=“myname”). This allows us to use it in things like .bazelignore, and other scripts or tool settings as needed.
When it is the dir name, it changes based on wherever the dev puts it, and therefore not static and can’t be put inside files.
Ok, thanks. Given the issue with
bazel cleanthat I highlighted earlier, I think that our first effort would be to enablebazel cleanto aggressively delete all symlinks into the output base that start withbazel-, even if they do not match the expected suffix. That would fix your immediate pain point, I think, and then open up the option for us to change bazel’s behavior to actually match the documentation, although I could see us going either way on that (it’s possible that some users have workflows built around the directory name at this point). I filed #11980 for the behavior change. https://github.com/bazelbuild/bazel/issues/11980I don’t know how quickly we’ll be able to get this done, though. If you think that you or someone else would be interested in contributing to Bazel by fixing this, that would be great. It would also help for you or other people to let us know how big a pain point this is, so we can understand how to prioritize properly.