Cargo incompatible_runfiles_cargo_manifest_dir

[UebelAndre]

This flag implements a work-around for bazelbuild/bazel#15486 that enables cargo_build_script to explicitly create a directory to use as a crate's CARGO_MANIFEST_DIR that can be passed to dependent actions.

--@rules_rust//cargo/incompatible_runfiles_cargo_manifest_dir

The intent of this flag is to eliminate non-hermetic behavior in interactions with CARGO_MANIFEST_DIR when building without a sandbox. For details see #2887 (comment)

[UebelAndre]

Implemented in #2891

[UebelAndre]

Flipped in #2948

[gferon]

I didn't get the opportunity to dive deeper, but this broke bringing any data accessible by a build script in Bazel for us. When using the data attribute of a cargo_build_script named bs, the files are symlinked in a directory called bs-.runfiles (instead of bs-cargo.runfiles) which is not where the build script is executed. I can provide more info if necessary.

[UebelAndre]

I didn't get the opportunity to dive deeper, but this broke bringing any data accessible by a build script in Bazel for us. When using the data attribute of a cargo_build_script named bs, the files are symlinked in a directory called bs-.runfiles (instead of bs-cargo.runfiles) which is not where the build script is executed. I can provide more info if necessary.

More details would be great! The build script should be running in CARGO_MANIFEST_DIR which should be set to a path within the .cargo_runfiles directory.

rules_rust/cargo/private/cargo_build_script.bzl

Line 336 in a6426e0

manifest_dir = "{}/{}/{}".format(runfiles_dir.path, workspace_name, ctx.label.package)

[gferon]

I managed to make it work by adding one extra include path to protoc. What threw me off is that we already had an extra relative path, namely ../../external/protobuf~/src and I now have to add ../../../protobuf~/src. Not sure why external is gone, but I suppose that's OK. Apologies for the false alarm!