-
Notifications
You must be signed in to change notification settings - Fork 460
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add tools attr with exec transition for cargo_build_script #885
Add tools attr with exec transition for cargo_build_script #885
Conversation
b360e41
to
c42f81d
Compare
This is actually a very interesting find. Lets consider the case of rules_rust/examples/sys/complex/raze/remote/BUILD.openssl-sys-0.9.60.bazel Lines 39 to 76 in fe657ed
Assuming |
I suppose the question is what is the openssl-sys build script doing with the openssl binary? For what it's worth, we do use openssl-sys in our build and it doesn't seem broken to me (yet...) |
This (or some other mechanism for passing tools in the exec configuration) would solve #884 |
How about if we added a |
I believe `tools` is a more idiomatic naming for “things that need to
execute during this rule” if another attribute is preferred, e.g. as on
genrule
https://docs.bazel.build/versions/main/be/general.html#genrule.tools
…On Wed, Aug 11, 2021 at 2:37 AM Daniel Wagner-Hall ***@***.***> wrote:
How about if we added a compile_data attribute to cargo_build_script as
per #516 <#516> ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#885 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA5AF4ODVDOHGW6LJZACQDT4JAF7ANCNFSM5B5BCDDQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
Yeah, |
|
Updated to add a tools attr instead. This is potentially more fixup work in other tools such as cargo raze if they are using data to pass tools that should be built for the exec platform, but certainly better from the perspective of ensuring backwards compatibility. |
Fantastic - LGTM One last piece - any chance of a test? I know that in our current execution environments on CI we won't see a difference, but it'd be handy for the future. I imagine adding a one-line |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! I wonder if tools
should be wired into compile_data
for the rust_binary
? Leaning towards not but would like some other opinions as well 😄
Either way, thank you!
The PR looks good to me, and as for the test, I guess it would be enough to have a genrule that touches a file (using for example this rule: https://github.com/bazelbuild/bazel-skylib/blob/main/rules/write_file.bzl), and then in the unit test we would check the exec path of the file passed in data and in tools. Like you do in a different PR, exec path of the file in tools should have "exec" in it. |
4f2e05d
to
bd7ebf7
Compare
Test added, merged main, and documentation re-updated. |
bd7ebf7
to
d51da84
Compare
@hlopko do these tests look good to you? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks! Over to @hlopko
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thank you!
(please rebase and somebody will merge this right away, thank you!) |
If tools are passed in
data
, they must be built in theexec
configuration in order to run on the host machine when the target != host.I think this should be a fairly safe change, unless someone is doing something with the tools passed to the build script that would require them to run on the target configuration, but short of copying these tools into the out_dir I don't know what that would be. And -- that would be better handled by depending directly on these tools in the data attr of the library or binary anyway.