cc_test doesn't appear to copy data files correctly on windows

[mason-bially]

Description of the problem / feature request:

On windows I can't seem to get the cc_test rule to copy data files that my tests depend on. The .runfiles folder has a MANIFEST with the links listed and an empty folder named after my WORKSPACE.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

The repo I found the bug on https://github.com/mason-bially/PEGTL

Run bazel test ... all of the file_*.cpp tests will fail on windows but succeed on another platform (there are some other tests I haven't finished setting up, notably contrib_json.cpp which are expected to fail).

What operating system are you running Bazel on?

Windows

What's the output of bazel info release?

release 0.27.1

Have you found anything relevant by searching the web?

It maybe related to my earlier issue: #8820

This issue appears to have been open for a while #4102

Any other information, logs, or outputs that you want to share?

[laszlocsomor]

This should be better documented, sorry it isn't. (#6402)

This behavior is normal on Windows: data-dependencies on Linux/macOS create a tree of symlinks, but not on Windows, only the MANIFEST file as you noticed.

If you use Windows 10 version 1703 or newer, and enabled Developer Mode, then you can use the --enable_runfiles flag to generate the runfiles tree. This gives you the same behavior as you get on Linux and macOS: the data-dependencies are there.

Otherwise you can use one of the runfiles-libraries built into Bazel. For C++ see instructions here:

bazel/tools/cpp/runfiles/runfiles_src.h

Line 15 in ece92fb

// Runfiles lookup library for Bazel-built C++ binaries and tests.

[laszlocsomor]

I recommend using the runfiles library even if you use --enable_runfiles, because it finds the runfiles directory or runfiles manifest next to (or near) the binary, so your binary will work even when launched from bazel-bin/.

[laszlocsomor]

The downside of using the runfiles library is that its init code is rigid: you have to use std::string and cannot use std::wstring (so you must convert argv[0] if you use wmain). That's a missing feature I never had time to implement.

[mason-bially]

Yea it also prevents gluing bazel on-top of existing tests. If you don't mind expanding, what is the limitation on windows? It seems like plenty of other bazel symlink style shenanigans work perfectly fine on it.
And, can it be fixed? If so, how would one go about doing that (like what files or classes would need to be changed)?

[laszlocsomor]

The working symlinks are in fact junctions -- a symlink [1] that can only point to directories.
Creating junctions requires no Admin privileges, i.e. you need not run Bazel as Admin. Creating file symlinks required Admin rights until Windows 10 Creators Update (version 1703).

[1] Technically not a symlink, but it behaves like one. See https://superuser.com/a/343079

[mason-bially]

So then will --enable_runfiles run as default behavior on windows once the creators update gets pushed to the mainstream windows 10 versions?

[laszlocsomor]

Maybe, see #8704. Do you know where mainstream windows 10 is?

[mason-bially]

@laszlocsomor I'm not sure I understand the question. I mean Windows 1703 (decoded as March 2017, though it launched in April) was over 2 years ago, and with the auto update behavior of windows 10 I sincerely doubt anyone is that far behind without being on an older OS entirely.

[laszlocsomor]

Sorry about the confusion. You wrote:

once the creators update gets pushed to the mainstream windows 10 versions?

I thought you implied Creators Update wasn't mainstream yet. Did I misunderstand?

[mason-bially]

Oh my fault I didn't actually parse the version number in my head when I asked.