You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to request a flag --keep_cwd be added to bazel run that, when set, runs the child process in the same working directory that bazel was invoked in.
In addition, I'd propose adding a BUILD_RUNFILES (or maybe just RUNFILES) environment variable that contains the runfiles path (this is the same as PWD when --keep_cwd is not passed). This way, binaries can be updated to be agnostic to whether --keep_cwd was passed or not by always looking under $BUILD_RUNFILES for runfiles instead of under the CWD.
This is similar to #3325 but I'm trying to put forward a concrete proposal that is backwards compatible.
Feature requests: what underlying problem are you trying to solve with this feature?
Oftentimes I would like to bazel run a program relative to the working directory (e.g. a program that dumps some output to a text file in the CWD).
If this option existed, I would probably add it to the .bazelrc in the repository that I work in (after double-checking that binaries correctly reference BUILD_RUNFILES instead of PWD) because running in the CWD is a very common use-case for me and other users of this repository (currently we use the work-around bazel build //path/to:bin && bazel-bin/path/to/bin).
What operating system are you running Bazel on?
macOS 10.15.4.
What's the output of bazel info release?
release 3.3.0-homebrew
What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?
(proprietary repo)
Have you found anything relevant by searching the web?
Any other information, logs, or outputs that you want to share?
In #3325 they propose using argv[0] to get the directory that the binary was invoked in in order to infer the runfiles directory, but I'm not sure this is as simple or as general as just having a BUILD_RUNFILES env var.
I'm not hard set on the name --keep_cwd; it's just a suggestion.
The text was updated successfully, but these errors were encountered:
Feature request:
I would like to request a flag
--keep_cwd
be added tobazel run
that, when set, runs the child process in the same working directory thatbazel
was invoked in.In addition, I'd propose adding a
BUILD_RUNFILES
(or maybe justRUNFILES
) environment variable that contains the runfiles path (this is the same asPWD
when--keep_cwd
is not passed). This way, binaries can be updated to be agnostic to whether--keep_cwd
was passed or not by always looking under$BUILD_RUNFILES
for runfiles instead of under the CWD.This is similar to #3325 but I'm trying to put forward a concrete proposal that is backwards compatible.
Feature requests: what underlying problem are you trying to solve with this feature?
Oftentimes I would like to
bazel run
a program relative to the working directory (e.g. a program that dumps some output to a text file in the CWD).If this option existed, I would probably add it to the
.bazelrc
in the repository that I work in (after double-checking that binaries correctly referenceBUILD_RUNFILES
instead ofPWD
) because running in the CWD is a very common use-case for me and other users of this repository (currently we use the work-aroundbazel build //path/to:bin && bazel-bin/path/to/bin
).What operating system are you running Bazel on?
macOS 10.15.4.
What's the output of
bazel info release
?release 3.3.0-homebrew
What's the output of
git remote get-url origin ; git rev-parse master ; git rev-parse HEAD
?(proprietary repo)
Have you found anything relevant by searching the web?
#3325
https://stackoverflow.com/questions/47764221/how-to-write-files-to-current-directory-instead-of-bazel-out
Any other information, logs, or outputs that you want to share?
In #3325 they propose using
argv[0]
to get the directory that the binary was invoked in in order to infer the runfiles directory, but I'm not sure this is as simple or as general as just having aBUILD_RUNFILES
env var.I'm not hard set on the name
--keep_cwd
; it's just a suggestion.The text was updated successfully, but these errors were encountered: