Skip to content

Allow usage of upstream libuv #5563

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom
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`
# for free to join this conversation on GitHub. Already have an account? # 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