Bazel: ./bazel-out created despite different symlink-prefix

[yaroslavvb]

I'm using --symlink_prefix to keep my folder clear of bazel files (it causes my dropbox sync to try to fswatch 1M files), and while it works for other "bazel-*" folders, bazel-out is still being created in local folder.

IE, every time I run bazel command, it gets recreated. Note that there's also bazel-out symlink being created in the proper --symlink_prefix location. So it looks like there's two things trying to create bazel-out symlink.

yaroslav@home:~/temp/git0_tensorflow$ bazel version
INFO: Reading 'startup' options from /home/yaroslav/.bazelrc: --max_idle_secs=100000000
Build label: 0.5.4
Build target: bazel-out/local-fastbuild/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Fri Aug 25 10:00:00 2017 (1503655200)
Build timestamp: 1503655200
Build timestamp as int: 1503655200

[yaroslavvb]

A work-around is to create unwriteable file bazel-out. It complains but things work

WARNING: failed to create one or more convenience symlinks for prefix

```
bazel test --config=opt --config=cuda --symlink_prefix=/home/yaroslav/temp/git0_tensorflow/ -k //tensorflow/contrib/memory_stats:memory_stats_ops_test

...
INFO: Found 1 test target...
WARNING: failed to create one or more convenience symlinks for prefix '/home/yaroslav/temp/git0_tensorflow/':
cannot create symbolic link bazel-out -> /home/yaroslav/.cache/bazel/_bazel_yaroslav/fca38da2e1ec1157a975f8193037fc98/execroot/org_tensorflow/bazel-out: /home/yaroslav/Dropbox/git0/tensorflow/bazel-out (File exists)
2017-09-22 19:06:24.167041: I tensorflow/core/common_runtime/gpu/gpu_device.cc:965] Found device 0 with properties:
name: GeForce GTX 1080 major: 6 minor: 1 memoryClockRate(GHz): 1.7335```

[ulfjack]

It's intentional that --symlink_prefix does not get applied to bazel-out. I realize that it's surprising, but it's working as intended. IIRC, Luis was working on something in this area.

[lfpino]

What happens when you use --symlink_prefix=myprefix- is that it generates the following symlinks:
bazel-out
myprefix-bin
myprefix-genfiles
myprefix-out
myprefix-testlogs
myprefix-workspace

The bazel-out symlink is always created because of some internal issues, hence this is WAI.

[arjantop]

Is it planned that the behavior will change? (not unconditionally creating bazel-out)

[ulfjack]

The problem with not creating that symlink is that you won't be able to run bazel with -s and then rerun individual commands in your workspace. At the same time, keeping the symlink around doesn't hurt much, even if you run multiple builds with different output bases in the same workspace - the symlink will flip-flop around depending on what the most recent build was, but Bazel should work just fine, even if the symlink is changed or removed while it's running.

[alexeagle]

Note, this contributed to a nasty bug yesterday where VSCode ate all the filehandles and broke C++ compilation on santa-enabled google corp mac because XCode initialization fails after bazel clean, yuck...
https://github.com/bazelbuild/bazel/issues/4603#issuecomment-364269706

[igorgatis]

Any news on this? Is there any way to point bazel-out to somewhere else? I have my source code in a Windows machine and build environment inside a Docker container under boot2docker inside VirtualBox. Bazel fails to create bazel-out under the shared folder and it gets very inconvenient to locate output artifacts.

[lfpino]

Hi @igorgatis, no sorry, no news about this. I'm wondering doesn't --symlink_prefix=myprefix and the myprefix-out work for your case? This issue is just about bazel-out being created despite --symlink_prefix being set.

[Globegitter]

Discussion at https://groups.google.com/forum/#!topic/bazel-discuss/uUxjsLZVkPQ lead me here and imo a very suprising user experience and something that is only needed for some internal or legacy reasons should still be treated as a bug. Surely it is possible to make bazel builld -s etc work with the out directory in a different location.

Also neither the cli flag documentation nor the manual (https://docs.bazel.build/versions/master/user-manual.html#flag--symlink_prefix) describe the behaviour that is reported here.

[ulfjack]

IDK, it also seems like a very surprising user experience if you can't run commands in your current directory anymore.

[Globegitter]

Yes agreed @ulfjack, but what is the underlying reason that this directory is needed at this location? Is there a reason why this behaviour can not be changed?

[ulfjack]

The bazel-out segment is part of the output paths and action command lines, so if it changes you can't get any cache hits (unless they use an identical segment) and Bazel will have to redo the entire analysis phase (which can be expensive for large projects).

[ulfjack]

...unless you're willing to compromise on being able to run commands in the workspace.

There are several constraints here (symlink names, bazel-out segment, run commands in the workspace, getting cache hits) and you can't hold all of them at the same time. There are several compromises that could be useful in different scenarios. I'm not against supporting another scenario, but I'd be careful about changing the semantics of the existing symlink_prefix flag: it currently implements one compromise.

[ChankiWu]

I set --symlink_prefix, and every time when I run bazel build it will generate all the "bazel-out", etc files with the parameters I set. And it is really annoying. How could I reset this command to let bazel generate files as default directory rules?

[astraujums]

Probably not the most common case, but when trying to build from Linux and Windows in the same workspace (Windows natively, Linux from Windows Subsystem for Linux) the bazel-out symlink gets in the way because Windows and Linux use different kind of links (ERROR: Cannot read link (name=C:\testbazel-out): unknown link type). So it would be nice if it were possible to configure the name differently for different platforms, say, in the WORKSPACE file.

[guobiaoxiong]

@ulfjack when set symlink_prefix="./bazel-out/" , Is there some way close the warning -- WARNING: failed to create one or more convenience symlinks for prefix './bazel-out/'

[adam-azarchs]

I understand how setting --symlink_prefix differently from one run to the next could cause issues for caching if the prefix value was different, but I'd think most users would set it in one of the various .bazelrc files. Given that, I don't understand why the bazel-out symlink is required.

My concrete example of how keeping this symlink around causes active harm is that I have an editor on-save hook to run goimports on go source files. The problem is that the tool will often find a desired import within bazel-$(dirname $PWD)/external and generate an incorrect import based on that. The bazel-out symlink doesn't cause quite as much of an issue, but it can still take a long time for goimports to search through the directory. I would like to be able to solve the problem by prepending _ to the directory name, since (as is the convention in go) directories starting with . or _ are ignored.

[benjaminp]

There's now --experimental_no_product_name_out_symlink.