jethrogb/rust-core_io

A way to use with nonstandard rustc

whitequark opened this issue · 8 comments

Upstream rustc does not provide support for my target. As such, core_io does not build on it with the "Unknown compiler version" error. The fork, of course, does not change anything in std::io.

Do you think it is possible to switch to a semver-based approach for selecting the source to accommodate this use case?

Happy to think solutions with you, but I'm not sure what you mean with semver-based approach in this case. The idea of the current setup is to automatically select the io source that comes with your compiler version.

What I mean is shipping sources grabbed from a set of Rust releases, let's say for example we just have 1.12 and 1.13. The version of core_io would also be 1.13.(something maybe). The build script would grab the Rust version and then select the newest core_io version that is still compatible, semver-wise, with the rustc it's compiled with.

This way you don't have to update the crate within moments of a new rustc being released, since it will no longer break all downstream crates. Since the version of the core_io crate itself is the same as the newest std::io it emulates, downstream crates that require new enough std::io features can simply add that as a version requirement.

Is what I've described clear enough?

Would it be ok if one could specify a commit hash of the closest nightly version in an environment variable?

That would make it possible to use, but the ergonomics would be very bad IMO.

Is there any problem with recording the original release version in the repository, and then using the semver crate to compare the current version with that? This is what I was going to implement (but I have no time for that so far).

I'm not sure what good recording the version would do. There are many nightlies per version.

I was thinking of using the commit date and selecting something close in that range, but that doesn't work if you have an older rustc with a new branch with recent commits.

Another thing is one could run "git log" on the rust git repository to find the most recent commit that works, but this requires at build time, having git, having the rust source repository, and being able to point the build script at that repository.

I thought about this and now I agree that your solution (specifying an environment variable) is probably the best that can be done here, or at least I cannot think of anything better.

Fixed in 3ad99dc using CORE_IO_COMMIT

Thanks!