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

Would it be safe to alias c_int ? #44

Open
RCasatta opened this issue Sep 13, 2022 · 3 comments
Open

Would it be safe to alias c_int ? #44

RCasatta opened this issue Sep 13, 2022 · 3 comments

Comments

@RCasatta
Copy link

related to rust-lang/cc-rs#721

I was wondering if it would be safe to alias c_int along the lines of what is done here

https://github.com/tcharding/rust-bitcoinconsensus/blob/9b3496a5c827e99cf10debe2c36f7b20fd622cc4/src/types.rs

This would allow this lib to not depend on libc on unix?

@joshtriplett
Copy link
Member

c_int is not the only thing jobserver-rs uses libc for; it's also invoking various functions via libc. That would be a lot harder to work around.

If it saved substantial build time for many crates, it might be worth working around, but it's also not obvious how to do so.

@NobodyXu
Copy link
Contributor

NobodyXu commented Aug 10, 2023

it's also invoking various functions via libc. That would be a lot harder to work around.

Yes, you would have to manually define syscalls using assembly, which really cannot be "vendored".

Though it's possible for cc to vendor jobserver since it only uses a subset of its API and already vendored windows-sys APIs and have function for making anonymous pipe on Unix and Windows.

@NobodyXu
Copy link
Contributor

If it saved substantial build time for many crates, it might be worth working around, but it's also not obvious how to do so.

If libc can bump its MSRV, then its build.rs could be reduced in size and faster to compile.

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

3 participants