-
Notifications
You must be signed in to change notification settings - Fork 385
miri-script: Transform Windows paths to Unix. #2877
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
miri-script: Transform Windows paths to Unix. #2877
Conversation
python3 snippet used to fill $MIRIDIR variable returns native paths. Down the line in `bench` subcommand this leads to benchmark setup failure, preventing contributors from running benchmarks on Windows hosts. This commit replaces usage of native os.path module with pathlib, which explicitly converts paths to Unix flavour.
1d86152
to
0255998
Compare
Thanks! Could we test a trivial fast benchmark in CI just to make sure it works? Or will that take too long due to compiling in release mode? |
Running Edit: It seems that miri is already compiled in release mode in CI, so yeah, it should essentially be free to do that. |
Yea, just part of the build pipeline makes sense. We'll see on the PR CI if there's a relevant increase in time |
So it seems like current hyperfine release doesn't work on i686-pc-windows-msvc target. The fix is available, but not released (yet). |
ci.sh
Outdated
@@ -81,6 +81,9 @@ function run_tests { | |||
cargo miri run --manifest-path bench-cargo-miri/$BENCH/Cargo.toml | |||
done | |||
fi | |||
# Ensure that `./miri bench` works on all relevant platforms. | |||
# `slice-get-unchecked` is the least complex of all available benchmarks. | |||
CARGO_EXTRA_FLAGS="" ./miri bench slice-get-unchecked |
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.
This is the wrong place to put the check. This here will be run for each target that we check. It needs to either be gated by -z "${MIRI_TEST_TARGET+exists}"
(to only run on the host) or be moved elsewhere.
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.
Also why the CARGO_EXTRA_FLAGS=""
?
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.
Also why the
CARGO_EXTRA_FLAGS=""
?
Since CARGO_EXTRA_FLAGS is set to --locked
, I've cleared it to fix an issue with --locked
being passed twice (which manifested itself in CI run of ca60799 commit). Is there a better way to do that? Perhaps I could document why this flag is cleared?
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.
Ah, that sounds like a bug in our miri script... maybe we just shouldn't have the --locked
in the install
command.
@@ -78,6 +78,9 @@ jobs: | |||
rustc -Vv | |||
cargo -V | |||
|
|||
- name: Install hyperfine | |||
run: cargo install hyperfine |
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.
This looks like it will cost us a minute. :/ Are there binary releases we could install?
Also the Linux run in this PR took almost 1h which is a lot slower than what I remember... is that a coincidence or related to this PR?
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.
I'm not aware of binary distributions of hyperfine.
Perhaps we could install dev
version, as we don't really care about measurements?
Though I'd expect hyperfine to be quick to build - even in release mode.
As for the slowdown of Linux build, let's see if reproduces on another CI run. I wouldn't expect this PR to slow down CI significantly.
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.
It looks like Linux run is back to normal. Perhaps running miri bench
only for host targets is a positive factor?
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.
It's about a minute to build. So not too bad I guess...
OTOH we don't actually care about the benchmarking part on CI, so we could as a hack also have CI create some hyperfine
shell script that just executes its last argument. At least that would work on Linux. Whether it makes sense on Windows I cannot say.
Document the reason for CARGO_EXTRA_FLAGS being cleared.
@@ -77,7 +77,7 @@ if [ -z "$COMMAND" ]; then | |||
fi | |||
shift | |||
# macOS does not have a useful readlink/realpath so we have to use Python instead... | |||
MIRIDIR=$(python3 -c 'import os, sys; print(os.path.dirname(os.path.realpath(sys.argv[1])))' "$0") | |||
MIRIDIR=$(python3 -c 'import pathlib, sys; print(pathlib.Path(sys.argv[1]).resolve().parent.as_posix())' "$0") |
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.
By the way, what do you think about detecting python binary to run (similar to what's done in ci.sh)? On my Windows machine python3
does not work out of the box, so I guess it might be worthwhile to do that.
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.
Oh no why is everything so terrible. :(
We don't have to use python for this but I found no better way to make it work on macOS.
Really we should rewrite the entire damn thing in Rust I guess if we truly want it to be portable...
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.
Really we should rewrite the entire damn thing in Rust I guess if we truly want it to be portable...
I'd be happy to tackle that in the future PR. Is there a tracking issue for that initiative?
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.
No. Do you want to create one? :)
Looks like hyperfine doesn't even build on Windows currently? I have implemented the alternative sketched above that avoids the need for hyperfine on CI in #2908. I'll add your commit fixing Windows to that PR, and close this one. Thanks a lot for your help! |
New version of hyperfine just dropped (with proper Windows support): https://github.com/sharkdp/hyperfine/releases/tag/v0.17.0 |
python3 snippet used to fill $MIRIDIR variable returns native paths. Down the line in
bench
subcommand this leads to benchmark setup failure, preventing contributors from running benchmarks on Windows hosts.This commit replaces usage of native os.path module with pathlib, which explicitly converts paths to Unix flavour.
pathlib is available from Python 3.4. There's also a nice comparison of features with os module.
On current master, running
./miri bench
under MinGW results in an error from cargo-metadata about path format.With this commit, it is not an issue anymore.