Skip to content

Move LLVM bindings to their own crate #8275

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

Closed
brson opened this issue Aug 3, 2013 · 4 comments
Closed

Move LLVM bindings to their own crate #8275

brson opened this issue Aug 3, 2013 · 4 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.

Comments

@brson
Copy link
Contributor

brson commented Aug 3, 2013

Right now our LLVM bindings are tightly integrated into trans. Would be good for abstraction sake to fence LLVM off into its own crate. It would also make LLVM more available to other Rust projects - Rust is a good language for writing compilers.

cc #8274

@treeman
Copy link
Contributor

treeman commented Aug 13, 2014

Visiting for triage. Still relevant.

@huonw
Copy link
Member

huonw commented Aug 13, 2014

This is actually somewhat addressed, with the new rustc_llvm crate; I don't know the full details, but from a quick perusal it still has some Rust specific parts (e.g. the external library (source), and 1, 2, 3), thus AFAICT, it's not a fully generic abstraction.

However it may be enough to close this issue; thoughts, @brson?

@treeman
Copy link
Contributor

treeman commented Aug 13, 2014

My bad.

@steveklabnik
Copy link
Member

I think this is about as addressed as it's going to get. We have the rustc_llvm crate for internal use, and people can use Cargo if they want to make better / nonrustc specific bindings.

@brson, if you disagree, feel free to re-open :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
Projects
None yet
Development

No branches or pull requests

4 participants