2

I'm trying to run a bazel target with bazel run command from workspace root. And I want to pass relative path as an argument to this target. Currently it doesn't recognize this pass, whilst manual run from console works fine.

So I conclude that bazel`s working dir differs from workspace root at this point .

I have checked for bazel docs, google, and didn't find an explicit way to specify working directory for run command. Does anybody know proper way to do that? Thanks!

P.S.: Namely I'm trying to run mediapipe iris example, which I build with following command (from project root):

bazel build -c opt --define MEDIAPIPE_DISABLE_GPU=1 mediapipe/examples/desktop/iris_tracking:iris_tracking_cpu

Then if I run it manually (also from project root) it works fine:

GLOG_logtostderr=1 bazel-bin/mediapipe/examples/desktop/hand_tracking/hand_tracking_gpu   --calculator_graph_config_file=mediapipe/graphs/hand_tracking/hand_tracking_mobile.pbtxt

Now if I run it with bazel run it fails:

bazel run -c dbg --define MEDIAPIPE_DISABLE_GPU=1 mediapipe/examples/desktop/iris_tracking:iris_tracking_cpu -- --calculator_graph_config_file=mediapipe/graphs/iris_tracking/iris_tracking_cpu.pbtxt

Not, that using $PWD in front of graph path doesn't help, for mediapipe engine still relies on relative path and proper CWD value.

Stepan Dyatkovskiy
  • 813
  • 9
  • 15
  • I have built up simple bazel app which prints current directory. And I prints me following: "/private/var/tmp/_bazel_stepan/5fb8b1321583495e8a465a1758c5a8e4/execroot/__main__/bazel-out/darwin-fastbuild/bin/main/hello-world.runfiles/__main__" ...Oh... this is what I always supposed to be a working dir (sarcasm). – Stepan Dyatkovskiy Dec 07 '21 at 08:36
  • After a while I discovered following. Bazel uses "sandboxing" thing. Thus... whenever your run "bazel run" it runs file in semi-isolated sandbox (they use term "hermetic" run). And somehow it is possible to disable sandbox, by passing special tag into build rules. Currently I'm trying to play with "no-sandbox" but it seems that you have to clean it, otherwise it still uses sandbox. – Stepan Dyatkovskiy Dec 07 '21 at 10:18
  • Well, I defined following in "cc_binary" rule: 'tags = ["no-sandbox", "no-cache", "no-remote"]'.... and it didn't help. So far no ideas. – Stepan Dyatkovskiy Dec 07 '21 at 11:04
  • You could wrap the program in a sh_binary that takes the working dir as first arg (and cd's there) and passes the rest to the program, which you define as data dep. – Laurenz Dec 07 '21 at 18:15

2 Answers2

7

bazel run executes the binary within its runfiles tree, and there is official no way to change that. Possible solutions if this is a problem:

  • Don't use bazel run; execute the binary directly.
  • bazel run puts the working directory it was executed from in the $BUILD_WORKING_DIRECTORY environmental variable, so the binary can resolve paths relative to that if desired.
  • On platforms with a POSIX shell, there is a hacky workaround: bazel run --run_under="cd $PWD &&" //some:target
Benjamin Peterson
  • 19,297
  • 6
  • 32
  • 39
0

If you are using sh_binary then you can work around this with a script like so:

#!/bin/bash

set -e

LAUNCH_WORKING_DIRECTORY=$(pwd)

if test "${BUILD_WORKING_DIRECTORY+x}"; then
  cd $BUILD_WORKING_DIRECTORY
fi

$LAUNCH_WORKING_DIRECTORY/tool.sh "${@:1}"

sh_binary(
  name = "tool",
  srcs = [ "launcher.sh" ],
  data = [ "tool.sh" ],
)

Bazel makes this absurdly complicated it must be said.

sdgfsdh
  • 33,689
  • 26
  • 132
  • 245