Support Runfiles on Windows

[dslomov]

Currently build-runfiles.exe uncoditionally creates hardlinks to individual runfiles on Windows.
This is problematic on several levels:

• if the target of hard link is deleted, we should unlink the link in runfiles and relink...
• ..but unlinking hardlinks is not allowed if the target of hardlink cannot be written to (for permission issues or because it is exclusively locked).

[dslomov]

Need to document the current plan for runfiles.

[petemounce]

Does this get put into milestone 0.5, or is it still possible to ship in the 0.4.x

[damienmg]

We do not version documentation yet. I think this should be done ASAP now.

[petemounce]

Oh - I meant this ticket, not the docs output of it.

[laszlocsomor]

Infeasible.

Non-elevated (not running as Administrator) processes cannot create symlinks, and we don't want to require elevation to run builds.

Bazel writes runfiles manifest files instead, that describe the mapping.

[gkalpak]

@laszlocsomor : Since it now possible to enable creating symlinks on Windows without admin rights or UAC (:tada:), is there a way to tell bazel to create symlinks as it would on linux (instead of creating a RUNFILES_MANIFEST_FILE?
_{(If not, there really should be 🙏}

[laszlocsomor]

Hey @gkalpak : sure it would be possible, but I'm afraid we don't have capacity to do the migration, plus this would make it impossible to support older Windows versions (since this feature requires Win 10, v1709). That said, it is much easier now to use runfiles on Windows, thanks to the language-specific runfiles libraries (see below).

Usage:

1. Depend on the specific runfiles library in the rule where you need to use runfiles. E.g. in py_library:

   py_library(
       name = "my_lib",
       ...
       deps = ["@bazel_tools//tools/python/runfiles"],
       data = [
           ... # some runfiles
       ],
   )
   

2. Import / include / source the runfiles library, as the documentation (see below) shows.
3. Create / init the runfiles object and look up runfiles using rlocation / Rlocation.

See:

• Python: @bazel_tools//tools/python/runfiles. Usage info and examples are in the header comments of tools/python/runfiles/runfiles.py
• Bash: @bazel_tools//tools/bash/runfiles. Usage info and examples are in the header comments of tools/bash/runfiles/runfiles.bash
• C++: @bazel_tools//tools/cpp/runfiles (coming in Bazel 0.15). Usage info and examples are in the header comments of tools/cpp/runfiles/runfiles.h
• Java: @bazel_tools//tools/runfiles:java-runfiles [1]. Usage info and examples are in the header comments of src/tools/runfiles/java/com/google/devtools/build/runfiles/Runfiles.jav

---

[1] this should move to @bazel_tools//tools/java/runfiles, but I never got around doing the migration)

[gkalpak]

Thx for the info. Unfortunately, I want to use the runfiles in Node.js, which doesn't seem to have a helper lib 😞

Regarding:

sure it would be possible, but I'm afraid we don't have capacity to do the migration, plus this would make it impossible to support older Windows versions

Just to be clear, I didn't mean make this the default behavior for Windows. But it would be great if there was a way to tell bazel that symlinks are supported (e.g. set an env var) and then it could behave the same as on linux/macOS.
(But I understand that it might not be as straight forward as flipping a switch under the hood. I have no idea about bazel internals 😇)

[laszlocsomor]

Just to be clear, I didn't mean make this the default behavior for Windows. But it would be great if there was a way to tell bazel that symlinks are supported (e.g. set an env var) and then it could behave the same as on linux/macOS.

Sure, I agree. :) Alas, I don't know to do that, and we already have plenty of other things to do, I'm afraid I can't spend time on it, sorry :( Maybe someone else will pick it up?...

[filipesilva]

https://github.com/bazelbuild/rules_nodejs can be used for runfile resolution, but there are problems with the manifest approach (like #5926).

I've opened an issue for the native symlink support too, at the time I hadn't seen the discussion here: #5807