Skip to content
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

A way to use with nonstandard rustc #2

Closed
whitequark opened this issue Sep 20, 2016 · 8 comments
Closed

A way to use with nonstandard rustc #2

whitequark opened this issue Sep 20, 2016 · 8 comments

Comments

@whitequark
Copy link

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?

@jethrogb
Copy link
Owner

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.

@whitequark
Copy link
Author

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?

whitequark added a commit to m-labs/artiq that referenced this issue Sep 20, 2016
Unfortunately the crate does not work out of the box with custom
Rust builds, and forking it makes little sense over just embedding
it here. See jethrogb/rust-core_io#2.
@jethrogb
Copy link
Owner

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

@whitequark
Copy link
Author

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).

@jethrogb
Copy link
Owner

jethrogb commented Oct 12, 2016

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.

@whitequark
Copy link
Author

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.

@jethrogb
Copy link
Owner

Fixed in 3ad99dc using CORE_IO_COMMIT

@whitequark
Copy link
Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants