-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Runfiles libraries don't find runfiles in directories that are themselves runfiles when using manifest #14336
Labels
Comments
fmeum
added a commit
to fmeum/runfiles
that referenced
this issue
Nov 26, 2021
When a target has a runfile that is contained in a directory that is itself one of its runfiles, the runfile will be shadowed by the SymlinkEntry for the directory. While this still allows to resolve the file in the runfiles symlink tree, a manifest-based lookup will fail. This PR extends the lookup logic to also find runfiles contained within directories that are themselves runfiles. It does so by searching the manifest not only for the exact provided rlocation path, but also for all path prefixes. If a prefix is looked up successfully, the corresponding suffix is resolved relative to the looked up path. See bazelbuild/bazel#14336 for more context.
This was referenced Nov 26, 2021
sventiffe
added
team-Rules-Server
Issues for serverside rules included with Bazel
untriaged
labels
Dec 8, 2021
fmeum
added a commit
to fmeum/runfiles
that referenced
this issue
Dec 30, 2021
When a target has a runfile that is contained in a directory that is itself one of its runfiles, the runfile will be shadowed by the SymlinkEntry for the directory. While this still allows to resolve the file in the runfiles symlink tree, a manifest-based lookup will fail. This PR extends the lookup logic to also find runfiles contained within directories that are themselves runfiles. It does so by searching the manifest not only for the exact provided rlocation path, but also for all path prefixes. If a prefix is looked up successfully, the corresponding suffix is resolved relative to the looked up path. See bazelbuild/bazel#14336 for more context.
fmeum
added a commit
to fmeum/runfiles
that referenced
this issue
Feb 5, 2022
When a target has a runfile that is contained in a directory that is itself one of its runfiles, the runfile will be shadowed by the SymlinkEntry for the directory. While this still allows to resolve the file in the runfiles symlink tree, a manifest-based lookup will fail. This PR extends the lookup logic to also find runfiles contained within directories that are themselves runfiles. It does so by searching the manifest not only for the exact provided rlocation path, but also for all path prefixes. If a prefix is looked up successfully, the corresponding suffix is resolved relative to the looked up path. See bazelbuild/bazel#14336 for more context.
fmeum
added a commit
to fmeum/runfiles
that referenced
this issue
Feb 5, 2022
When a target has a runfile that is contained in a directory that is itself one of its runfiles, the runfile will be shadowed by the SymlinkEntry for the directory. While this still allows to resolve the file in the runfiles symlink tree, a manifest-based lookup will fail. This PR extends the lookup logic to also find runfiles contained within directories that are themselves runfiles. It does so by searching the manifest not only for the exact provided rlocation path, but also for all path prefixes. If a prefix is looked up successfully, the corresponding suffix is resolved relative to the looked up path. See bazelbuild/bazel#14336 for more context.
@bazel-io fork |
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
Feb 7, 2022
When a target has a runfile that is contained in a directory that is itself one of its runfiles, the runfile will be shadowed by the `SymlinkEntry` for the directory. While this still allows to resolve the file in the runfiles symlink tree, a manifest-based lookup will fail. Since the manifest is used to create the symlink tree for which it is important that no path is a prefix of another, this can only be fixed in the runfiles libraries. This PR extends the lookup logic of the Bash, C++, Java, and Python runfiles libraries to also find runfiles contained within directories that are themselves runfiles. It does so by searching the manifest not only for the exact provided rlocation path, but also for all path prefixes. If a prefix is looked up successfully, the corresponding suffix is resolved relative to the looked up path. Fixes bazelbuild#14336. Closes bazelbuild#14335. PiperOrigin-RevId: 426894517
Wyverald
pushed a commit
that referenced
this issue
Feb 7, 2022
When a target has a runfile that is contained in a directory that is itself one of its runfiles, the runfile will be shadowed by the `SymlinkEntry` for the directory. While this still allows to resolve the file in the runfiles symlink tree, a manifest-based lookup will fail. Since the manifest is used to create the symlink tree for which it is important that no path is a prefix of another, this can only be fixed in the runfiles libraries. This PR extends the lookup logic of the Bash, C++, Java, and Python runfiles libraries to also find runfiles contained within directories that are themselves runfiles. It does so by searching the manifest not only for the exact provided rlocation path, but also for all path prefixes. If a prefix is looked up successfully, the corresponding suffix is resolved relative to the looked up path. Fixes #14336. Closes #14335. PiperOrigin-RevId: 426894517
fmeum
added a commit
to fmeum/runfiles
that referenced
this issue
Mar 9, 2022
When a target has a runfile that is contained in a directory that is itself one of its runfiles, the runfile will be shadowed by the SymlinkEntry for the directory. While this still allows to resolve the file in the runfiles symlink tree, a manifest-based lookup will fail. This PR extends the lookup logic to also find runfiles contained within directories that are themselves runfiles. It does so by searching the manifest not only for the exact provided rlocation path, but also for all path prefixes. If a prefix is looked up successfully, the corresponding suffix is resolved relative to the looked up path. See bazelbuild/bazel#14336 for more context.
fmeum
added a commit
to fmeum/runfiles
that referenced
this issue
Mar 22, 2022
When a target has a runfile that is contained in a directory that is itself one of its runfiles, the runfile will be shadowed by the SymlinkEntry for the directory. While this still allows to resolve the file in the runfiles symlink tree, a manifest-based lookup will fail. This PR extends the lookup logic to also find runfiles contained within directories that are themselves runfiles. It does so by searching the manifest not only for the exact provided rlocation path, but also for all path prefixes. If a prefix is looked up successfully, the corresponding suffix is resolved relative to the looked up path. See bazelbuild/bazel#14336 for more context.
fmeum
added a commit
to fmeum/runfiles
that referenced
this issue
Mar 24, 2022
When a target has a runfile that is contained in a directory that is itself one of its runfiles, the runfile will be shadowed by the SymlinkEntry for the directory. While this still allows to resolve the file in the runfiles symlink tree, a manifest-based lookup will fail. This PR extends the lookup logic to also find runfiles contained within directories that are themselves runfiles. It does so by searching the manifest not only for the exact provided rlocation path, but also for all path prefixes. If a prefix is looked up successfully, the corresponding suffix is resolved relative to the looked up path. See bazelbuild/bazel#14336 for more context.
phst
added a commit
to phst/rules_elisp
that referenced
this issue
Apr 17, 2022
This is equivalent to the fixes made for bazelbuild/bazel#14336.
phst
added a commit
to phst/rules_elisp
that referenced
this issue
Apr 17, 2022
This is equivalent to the fixes made for bazelbuild/bazel#14336.
12 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the problem / feature request:
In the way they are currently implemented, the Bazel runfiles libraries at
@bazel_tools//tools/*/runfiles
do not always find the identical set of runfiles when using a manifest compared to when using a runfiles directory.Specificially, if a target has runfiles
foo
(a directory) andfoo/a.txt
(a file in that directory), thenRunfiles#filterListForObscuringSymlinks
will filter outfoo/a.txt
. As a result:foo/a.txt
will be found since the symlinkfoo
resolves to the correct directory containinga.txt
;foo/a.txt
is not found since it is not listed in the manifest, onlyfoo
itself is.Note that it is pretty easy to pick up both a directory and a file contained in that directory as runfiles through transitive dependencies and everything will work well on Linux/macOS, only to non-obviously break on Windows. I encountered this issue while working on a ruleset that would allow for compile-time checked
rlocation
lookups for C++ and Java, but found the current issue to block this effort.Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
correctly prints
When using
@bazel_tools//tools/cpp/runfiles
with the runfiles manifest, e.g. on Windows, thenRlocation("foo/a.txt")
will return an empty string instead of the correct path for the declared runfile.What operating system are you running Bazel on?
Any, but this mostly applies to Windows.
What's the output of
bazel info release
?Any version is affected, including current
master
.Have you found anything relevant by searching the web?
No.
Any other information, logs, or outputs that you want to share?
I prepared a PR (#14335) that extends the C++, Java, and Python runfiles libraries so that they also find runfiles within runfiles directories when using the runfiles manifest. I could also fix this for the bash implementation, but would like to wait for general feedback before I start working on this.
The text was updated successfully, but these errors were encountered: