Implement untaring in rust #348
Conversation
illicitonion
requested review from
acmcarther,
damienmg and
mfarrugi
as code owners
|
#346 being merged, do you mind rebasing? Thanks! |
This avoids relying on the system path The exposed `untar` attribute is pretty ugly, but I'm not sure the best alternative. We need to be able to access `untar` from anything which has an `out_dir_tar` attribute, which may be any of our rules, but need to specifically not depend on it from the targets which make `untar` itself. This means it can't live in a toolchain. Ideally it'd be an attribute conditionally set only iff `out_dir_tar` is set, which we could do in a macro, but introducing a layer of macros to the rules just to make our handful of bootstrap rust_libraries not need to fake out the attribute seems overkill. The binary will only _actually_ be depended on and built if it's needed.
|
Rebased - thanks! CI is currently failing in the examples dir because this puts a requirement on having a few repositories bound into the workspace - I guess this is something we can put into the |
| #[test] | ||
| fn fails() { | ||
| let mut dir = temp_dir(); | ||
| let now_millis = SystemTime::now().duration_since(UNIX_EPOCH).expect("You're not before 1970, surely?").as_millis(); |
There was a problem hiding this comment.
| let now_millis = SystemTime::now().duration_since(UNIX_EPOCH).expect("You're not before 1970, surely?").as_millis(); | |
| let now_millis = SystemTime::now().duration_since(UNIX_EPOCH).expect("Did you time travelled?").as_millis(); |
;)
I think the best approach is rust_repositories, however this is not really nice to have that much deps for such a feature. I would lean toward deprecating the support for tarball, do we actually have a use-case that justify keeping this feature around? |
|
Yeah, I think I agree that deprecating the |
|
@dfreese @smklein @acmcarther @mfarrugi Any reason to keep out_dir_tar around now that we have a build_script rule? |
No reason that I'm aware of - I only saw it used for the build scripts. "out_dir_tar" is no longer referenced by cargo-raze anymore either. |
|
@illicitonion Do you mind doing a change to simply add a failure if someone use out_dir_tar instead pointing them at the build script rule? |
|
This is now superceded by #354 which is needed for windows support. |
4 participants
This avoids relying on the system path
The exposed
untarattribute is pretty ugly, but I'm not sure the bestalternative. We need to be able to access
untarfrom anything whichhas an
out_dir_tarattribute, which may be any of our rules, but needto specifically not depend on it from the targets which make
untaritself. This means it can't live in a toolchain.
Ideally it'd be an attribute conditionally set only iff
out_dir_tarisset, which we could do in a macro, but introducing a layer of macros to
the rules just to make our handful of bootstrap rust_libraries not need
to fake out the attribute seems overkill. The binary will only
actually be depended on and built if it's needed.
Everything except the top commit is #346