-
Notifications
You must be signed in to change notification settings - Fork 214
Remove cloudabi, winapi, and fuchsia-cprng dependancies #40
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
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
12b4f8c
Fix libc dependancies
josephlr c720a5d
Ony automatically include std impls on platforms using std anyway
josephlr bddc134
Remove `cloudabi` crate dependancy
josephlr 11931a3
Remove `winapi` crate dependancy
josephlr 68707a5
Remove `fuchsia-cprng` dependancy
josephlr d54ba39
Cleanup Cargo.toml
josephlr File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want to depend on
libc
for all targets. Maybe instead construct one bigcfg
expression with enumeration of targets which uselibc
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, I just used
unix || wasi
. Although that's not perfect, as we don't use libc on all unix targets (only 7 of them), but writing all that out makes theCargo.toml
way harder to read.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also could remove
libc
dependency for WASI as well,libc
code is quite straightforward. Not sure if it's worth though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We totally could (Strictly speaking we could do it for any libc declaration), but I think it’s best to not duplicate declarations from the libc, if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we wanted we could not depend on the libc at all for any target, by copying over the 6 or 7 libc declarations needed to make everything link. But I think that would make breakage/instability more likely, not less.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just a bit strange for me to depend on
libc
crate for a target which, well, does not havelibc
as a system interface, i.e. it's defined in terms of core functions. (I wonder why WASI target was added tolibc
crate in the first place, instead of creating a separate crate à lacloudabi
or Fuchsia crates)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think they added it because
wasi-libc
defines that symbol. However, it's just a macro that links to thewasi_unstable
module. From their Github issues, it seems like thewasi_unstable
module is an implementation detail and may change in the future.Given that, linking to the libc seems like the most stable approach, so we are not depending on an unstable components of the WASI API.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my understanding we shouldn't care about
wasi-libc
at all. WASI defines Core API and__wasi_random_get
is part of it. So we should be able to use it directly without any issues.cc @alexcrichton @gnzlbg
UPD: Ah, the linked page states that:
So it looks like
random_get
(to which__wasi_random_get
links) is unstable. I don't quite get this situation, but it seems that usinglibc
will be indeed the best option right now.