Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update
cargo_build_script
to always render custom runfiles dirs. (#…
…2891) After #2887 I started finding similar linker errors in environments that supported runfiles and symlinks but have yet to see this issue in environments without them. I believe my understanding of how the [DefaultInfo.default_runfiles](https://bazel.build/rules/lib/providers/DefaultInfo#default_runfiles) objects worked and in the previous change had attempted to rely on it for a runfiles directory. However, there is no guarantee a directory will be rendered and no way to force it to be rendered for actions either (bazelbuild/bazel#15486). The consequence is that creating a custom runfiles directory is no longer a contingency and explicitly creating it is the correct thing to do to ensure `CARGO_MANIFEST_DIR` linker inputs are always available to the consuming actions. With the propagation of `CARGO_MANIFEST_DIR` (now an action output) into `Rustc` actions, a new flag is also introduced to prune unnecessary files out of the directory to reduce bloat and potential invalidation in downstream actions, `--@rules_rust//cargo/settings:cargo_manifest_dir_filename_suffixes_to_retain`. This flag accepts a list of path suffixes used to determine what (if anything) in `CARGO_MANIFEST_DIR` should be retained and passed to downstream actions. Note that the failure mode this addresses is hard to observe as it requires a crate which defines a linker path to something in `CARGO_MANIFEST_DIR` and then for a clean build to be done with a change to a dependent of said crate. If the runfiles directory for the build script is never rendered then there will be no file to link into the crate. --------- Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
- Loading branch information