Revisit --enable_runfiles

[buchgr]

The flags --build_runfile_manifests and --build_runfile_links govern whether runfile manifests and runfile trees should be created at the time of building a binary. bazel run/test has extra logic to create runfile trees on-demand if --nobuild_runfile_links is set. This is where --enable_runfiles comes in. It disables any runfile trees creation and instead only copies the input manifest to the output manifest.

1. I suggest we deprecate and remove the flag.
2. Instead we introduce --test_runfile_links which enables/disables the symlink tree creation for bazel run/test. On Windows, both --build_runfile_links and --test_runfile_links would be disabled by default.
3. In case of --nobuild_runfile_links it also copies the input manifest to the output manifest. This is unnecessary and can be slow.
4. It has a correctness issue in that if its value changes analysis is not rerun: Runfiles tree is not recreated when value of --enable_runfiles changes #9150

@meteorcloudy @laszlocsomor

[nicolov]

Just to add to the list, --enable_runfiles=false doesn't seem to work with bazel test, the symlink tree is created anyway: #9164

[laszlocsomor]

Sounds like --[no]test_runfile_links means the same as --[no]enable_runfiles, is that correct?

[buchgr]

@laszlocsomor no. --[no]build_runfile_links and --[no]test_runfile_links combined are the same as --[no]enable_runfiles

[laszlocsomor]

Ah, gotcha. They individually control runfiles link generation in build phase vs. test phase.

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.

[tjgq]

Still relevant.

[coeuvre]

We have made the conclusion in #18580, closing.