-
Notifications
You must be signed in to change notification settings - Fork 482
Add out_dir
support in cargo_dep_env
#1571
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
Merged
Merged
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
ebe445b
Add `out_dir` support in `cargo_dep_env`
bsilver8192 7ded48d
Fix buildifier and add directory checking
bsilver8192 627ebef
Add some comments
bsilver8192 595572e
Fix buildifier
bsilver8192 4772126
Merge branch 'main' into cargo_dep_env-out_dir
UebelAndre File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
"""Tests for passing configuration to cargo_build_script rules""" | ||
|
||
def _create_dep_dir(ctx): | ||
out = ctx.actions.declare_directory("dep_dir") | ||
ctx.actions.run_shell( | ||
outputs = [out], | ||
arguments = [out.path], | ||
command = 'echo contents > "$@/a_file"', | ||
) | ||
return [DefaultInfo(files = depset(direct = [out]))] | ||
|
||
create_dep_dir = rule( | ||
implementation = _create_dep_dir, | ||
) |
This file was deleted.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
use std::{env::var, fs, io::Result}; | ||
|
||
fn main() { | ||
let dep_dir = &var("DEP_DIR").expect("DEP_DIR should be set"); | ||
let entries = fs::read_dir(dep_dir) | ||
.expect("Failed to open DEP_DIR directory") | ||
.collect::<Result<Vec<_>>>() | ||
.expect("Failed to read DEP_DIR directory entries"); | ||
let entries = entries | ||
.iter() | ||
.map(|entry| { | ||
entry | ||
.path() | ||
.file_name() | ||
.unwrap() | ||
.to_string_lossy() | ||
.to_string() | ||
}) | ||
.collect::<Vec<_>>(); | ||
assert_eq!(entries, vec!["a_file".to_string()]); | ||
} |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Why is this a separate
BuildInfo
provider? Is there a reason you couldn't just conditionally assignempty_dir
orctx.file.out_dir
?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.
Not sure which piece you're asking about, here's answers to two questions I can think of:
BuildInfo
even if there's noout_dir
to manage.BuildInfo
inDepInfo.transitive_build_infos
is handled very differently than the mainBuildInfo
being returned, so they have to be separate. The former is is for build.rs scripts that depend on it transitively, and the latter is for direct dependencies of any kind.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.
More directly, why does there need to be a new
BuildInfo
here vs updating the one created here:https://github.com/bazelbuild/rules_rust/blob/0.10.0/cargo/cargo_build_script.bzl#L455-L462
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.
That's my
#2
: thatBuildInfo
is used in separate contexts from this new one, and I don't thinkcargo_dep_env
should contribute settings there. Specifically, I don't see wheredep_env
in thatBuildInfo
is ever used, from what I see it just gets rolled up the dependency tree but nothing ever uses it. Theout_dir
from thatBuildInfo
does get used though, which I think would be pretty confusing to expose.I think the
out_dir
from the mainBuildInfo
is intended for use in conjunction withrustc_env
, whichcargo_dep_env
currently does not have the ability to set. I do not think adding that is necessary, because it's easy enough to write acargo_build_script
that passes values through. I'm not sure whether adding it would make sense, it gets kind of complicated to expose the dual meanings ofout_dir
, but at the same time I've got acargo_build_script
that just copies files fromdep_env
values to itsout_dir
and then setsrustc_env
settings to point to them.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.
Sorry for the delay here. I keep reading this and still don't think I've fully grokked the need for the transitive provider. The last two things I think I'll ask are:
out_dir
being placed in the top level provider? Or is this more of a logical/correctness thing?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.
Nothing is technically wrong, it just does something different. For example, my newly-added
//test/dep_env:build_read_dep_dir
fails because it can't find the file after changing that.The place this second (direct) BuildInfo would be useful is if a
cargo_dep_env
was directly depended on by arust_library
and setrustc_env
.Done