Build deps of _build_script_run in 'exec' mode

[scentini]

#1537 (comment)

[UebelAndre]

Sorry for the delay here!

I think this seems correct but could you elaborate on what deps is for the _build_script_run target? I only ever thought of deps as things for the rust_binary or script attribute. Would it make more sense to not pass deps as an attribute there? And to expect anything that needs to be used at runtime maybe:

1. A data or compile_data attribute to the rust_binary
2. A data or tools dependency of _build_script_run

[UebelAndre]

@scentini I saw you rebased this but did you see #1561 (comment) ?

[scentini]

Hey @UebelAndre, sorry for the delayed response! I believe the premise for needing the deps in the _build_script_run rule is to collect outputs from transitive build scripts.

1. I wouldn't put them in data of rust_binary, because rust_binary is a generic rule, and the build script outputs shouldn't be present in the bazel-out/.../runfiles/... directory when it is used as a tool dependency, rather than as part of the build script setup.
2. I don't see an easy way of doing this; currently we collect the output directories all the transitive BuildInfos; we wouldn't want to force users to be aware of all the transitive build scripts.
3. There is a third option though: instead of a macro, we could have a build_script Starlark rule that unifies the work done by rust_binary and _build_script_run. In that case we could do something similar to 1., because the regular rust_binary won't have the build script outputs propagated in its data, it would be the build_script rule. I consider this option out of scope for this PR though :)

[UebelAndre]

Sorry about the merge conflict. Hope you don't mind me resolving it for you. I think this change is fine but after looking closer at cargo_build_script I feel it's implemented in a confusing way and can be simplified. I'll try to open PRs to improve that.

Sorry for the delay and looks good!

[scentini]

No worries @UebelAndre, thanks for the review!