It's common for users of multitool to want to run tools in the current working directory. In #26, @alexeagle documented a technique we've used for a while with creating a script and symlinking to it. Our internal copy of this script is a bit more complicated to help avoid expensive calls to Bazel that simple bazel run calls don't really need. More refinements have been proposed in #27. All of these things are fundamentally workarounds for https://github.com/bazelbuild/bazel/issues/3325.
To help simplify things, this PR adds a convenience wrapper that captures the execpath, switches to $BUILD_WORKING_DIRECTORY, and then runs the desired tool. The resulting shell script gets to use a very simple bazel run, should be compatible across any slew of Bazel options, and cache as well as any typical run target.
It's common for users of multitool to want to run tools in the current working directory. In #26, @alexeagle documented a technique we've used for a while with creating a script and symlinking to it. Our internal copy of this script is a bit more complicated to help avoid expensive calls to Bazel that simple
bazel runcalls don't really need. More refinements have been proposed in #27. All of these things are fundamentally workarounds for https://github.com/bazelbuild/bazel/issues/3325.To help simplify things, this PR adds a convenience wrapper that captures the execpath, switches to $BUILD_WORKING_DIRECTORY, and then runs the desired tool. The resulting shell script gets to use a very simple
bazel run, should be compatible across any slew of Bazel options, and cache as well as any typical run target.