diff options
author | laszlocsomor <laszlocsomor@google.com> | 2018-05-30 02:08:15 -0700 |
---|---|---|
committer | Copybara-Service <copybara-piper@google.com> | 2018-05-30 02:09:50 -0700 |
commit | 2cbcde33478756d265a57e88c89732126f33879a (patch) | |
tree | b90265543bbd2a903ad52c8a9d4d0b395534429a /scripts/bash_completion_test.sh | |
parent | 8f384fc273e36ecc2a35f0b2f0d69e137651e36c (diff) |
Automated rollback of commit 7fcbc8ffdead028d19606fefa2fa3be13781da98.
*** Reason for rollback ***
According to a post-submit regression test, this
commit increased Bazel's memory usage slightly
beyond some threshold. That event prompted me to
consider and question the necessity of this
commit.
My goal is to make Bazel work on Windows without
requiring MSYS, failing the build only if an
action is a shell action. Toolchainifying the
shell is related to, but not required by this
effort. What is required is to fail the build when
Bazel tries to create a shell action but the shell
is missing, and we have that already with
ShToolchain.getPath (which only considers the
ShellConfiguration fragment).
What's missing for my goal is to reimplement
hardcoded shell actions
(i.e. SpawnAction.builder().setShellCommand(...))
without using the shell where possible.
*** Original change description ***
shell toolchain: genrule now uses it
genrule() now uses the shell toolchain (as well as
the ShellConfiguration config fragment) to look up
the shell interpreter's path.
Also the CommandHelper no longer looks up the
shell interpreter's path itself. Instead its ctor
takes the path as an argument. This allows
supporting rules that already use the shell
toolchain and rules that still only consider the
configuration fragment.
With these changes genrule() is now able to use
the shell interpreter registered as a toolchain,
even if there's no `--shell_executable` flag
specified (or its value is empty).
Subsequent commits will migrate more and more
rules to depend on the shell toolchain.
This commit takes us closer to:
1. be able to detect the local shell interpreter's
location, especially when it's not the default
/bin/bash
2. be able to define different shell toolchains
(different interpreter paths) for remote builds
3. gracefully fail the build if the machine has no
shell installed but the action graph included a
shell action
See https://github.com/bazelbuild/bazel/issues/4319
Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7
Closes #5282.
***
RELNOTES: none
PiperOrigin-RevId: 198527351
Diffstat (limited to 'scripts/bash_completion_test.sh')
0 files changed, 0 insertions, 0 deletions