On Sun, May 5, 2013 at 2:16 AM, Brian Anderson <[email protected]> wrote: > On 05/03/2013 09:24 PM, Thad Guidry wrote: >> >> Looks like libuv is a showstopper currently for me on Windows Cygwin >> building. >> >> Why is it used ? Should it be ? Will it be in the future ? >> >> Can someone throw up a quick paragraph or 2 about this on the wiki and let >> me know ? > > > libuv is Rust's I/O abstraction layer. It provides efficient asynchronous > I/O that works on all platforms, including windows (but apparently excluding > cygwin). > > The I/O layer is somewhat tightly integrated with the new scheduler, but the > scheduler is being designed with the intent that the I/O implementation be > dynamically pluggable, allowing for alternatives to libuv. Making libuv > truly optional requires fixing a few blockers, ripping out and refactoring a > lot of code. If you are someone else is interested I can point in the > direction necessary, but it is a significant amount of work. > > Under the *current* runtime libuv is not strictly necessary, so it may be > possible to carve out everything that depends on libuv and still get it to > compile, but it would be very ugly. > > The path of least resistance here is probably to port libuv to cygwin. > > Some details here: https://github.com/mozilla/rust/issues/4419
Libuv used to support cygwin but I recently removed it[1]. It was broken (as in: wouldn't build) for a long time with no bug reports; strong indication that no one uses it. I'll happily take pull requests that resurrect it but, if you can get away with it, I would suggest that Rust uses the native windows back-end instead: it's much more battle-tested, performs way better and should mostly Just Work(TM) in a cygwin environment. [1] https://github.com/joyent/libuv/commit/7f8130a _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
