Test fixtures on Linux about rules_swift

[allevato]

This is one place where the way the rules work at runtime fundamentally differs between Apple and Linux.

On Linux, it's a good idea to think of swift_{library,binary,test} as operating in the same fashion as cc_{library,binary,test} in terms of things like runfiles and data dependencies. Forget everything you know about using the rules on Apple platforms 🙂 The behavior of much of our Apple build logic is special-cased for historical reasons and because of the nature of Apple bundling, and we haven't settled to a stable state yet where we can eliminate all of those special cases.

For Linux, the similarities to cc_{library,binary,test} mean that runtime data needed during the execution should be passed via the data attribute, which causes the files to be symlinked into the runfiles directory of the binary when you bazel run or bazel test it. Then, the current working directory of the binary will be (a view of) your workspace root, and you can access those files using their workspace-relative path at runtime.

If you're using a {ios,macos,tvos}_unit_test target instead of a swift_test, then the Apple rules apply, because those rules create test bundles. You need to use resources or structured_resources and then load those resources from wherever they exist in your bundle at runtime.

This means that, at this time, if you want to support running a test on both Apple and Linux, you need to do some repetition of your resources in the resources/structured_resources and data attributes (and you can use select functions to select based on target platform, as well) to have them work uniformly. You may also need to have some conditional compilation in your Swift code to find the resources at the correct locations at runtime.†

This situation should be improved when we eventually retire the Apple-specific resource attributes and have everything use data across the board, but that work's still pending.

† One of my teammates mentioned that the Foundation.Bundle APIs have also seen some love recently in Swift on Linux, and that you can use those to access resources that are in the same package or subpackages, even for unbundled command line binaries (the "bundle" that the API returns is the directory containing the binary). I haven't looked at it myself yet so I don't know which version of Swift those changes are in, but that could also be helpful in making the Swift code that loads such resources identical on both platforms.

[keith]

Thanks for the super detailed response. Now that swift_test supports macOS, do you have any thoughts on how / if resources should work with that?

Then, the current working directory of the binary will be (a view of) your workspace root, and you can access those files using their workspace-relative path at runtime.

It looks like right now the test bundle does have access to the runfiles directory in the path Target.test-runner.sh.runfiles/__main__/workspace/root/to/data. Is that the behavior we want from this long term?

[keith]

It looks like, unsurprisingly, you also can't write to this directory in case you write and delete files throughout the run of the tests.