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.

Sign up for GitHub

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

Jump to bottom

Allow usage of upstream libuv #5563

Closed
fabiand opened this issue Mar 26, 2013 · 7 comments
Closed

Allow usage of upstream libuv #5563

fabiand opened this issue Mar 26, 2013 · 7 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows

Comments

@fabiand
Copy link
Contributor

fabiand commented Mar 26, 2013

Currently libuv is a submodule in the source tree of rust. It would be nice if an external libuv could be used - and configured at build time. This would allow an easier packaging.
@lucab
Copy link
Contributor

lucab commented Mar 28, 2013

I was wondering on this topic too, but to the best of my knowledge libuv doesn't currently offer a stable API/ABI and decoupling it now may result in a useless compatibility hell. See joyent/libuv#354.
Not directly related, but just for reference this report is on the same path as llvm-unbundling (#4259).

@bstrie
Copy link
Contributor

bstrie commented May 23, 2013

Libuv is now producing actual stable releases, so perhaps now this can move ahead.

@lucab
Copy link
Contributor

lucab commented May 23, 2013

I think that #6567 is temporarily blocking this.

@toddaaro
Copy link
Contributor

toddaaro commented Jul 3, 2013

This is certainly something that should happen eventually. Added a few tags and nominating for "production ready".

@graydon
Copy link
Contributor

graydon commented Aug 15, 2013

just a bug, removing milestone/nomination.

@lucab lucab mentioned this issue Nov 3, 2013
Closed
@flaper87 flaper87 changed the title Allow usage of external libuv Allow usage of upstream libuv Apr 1, 2014
@flaper87
Copy link
Contributor

flaper87 commented Apr 1, 2014

Triage bump. Updated issue title to mention upstream instead of external. Nothing else to add

@alexcrichton
Copy link
Member

There is currently only one more commit that we need to upstream (rust-lang-deprecated/libuv@800b56f), opened with libuv as joyent/libuv#1214

flip1995 pushed a commit to flip1995/rust that referenced this issue May 17, 2020
@bors
Auto merge of rust-lang#5563 - ThibsG:MergeLints, r=flip1995
cfd720d 
Merge some lints together

This PR merges following lints:

- `block_in_if_condition_expr` and `block_in_if_condition_stmt` → `blocks_in_if_conditions`
- `option_map_unwrap_or`, `option_map_unwrap_or_else` and `result_map_unwrap_or_else` → `map_unwrap`
- `option_unwrap_used` and `result_unwrap_used` → `unwrap_used`
- `option_expect_used` and `result_expect_used` → `expect_used`
- `wrong_pub_self_convention` into `wrong_self_convention`
- `for_loop_over_option` and `for_loop_over_result` → `for_loops_over_fallibles`

Lints that have already been merged since the issue was created:
- [x] `new_without_default` and `new_without_default_derive` → `new_without_default`

Need more discussion:
- `string_add` and `string_add_assign`: do we agree to merge them or not? Is there something more to do? → **not merge finally**
- `identity_op` and `modulo_one` → `useless_arithmetic`: seems outdated, since `modulo_arithmetic` has been created.

fixes rust-lang#1078

changelog: Merging some lints together:
- `block_in_if_condition_expr` and `block_in_if_condition_stmt` → `blocks_in_if_conditions`
- `option_map_unwrap_or`, `option_map_unwrap_or_else` and `result_map_unwrap_or_else` → `map_unwrap_or`
- `option_unwrap_used` and `result_unwrap_used` → `unwrap_used`
- `option_expect_used` and `result_expect_used` → `expect_used`
- `for_loop_over_option` and `for_loop_over_result` → `for_loops_over_fallibles`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@flaper87 @graydon @alexcrichton @fabiand @lucab @toddaaro @bstrie