-
-
Notifications
You must be signed in to change notification settings - Fork 645
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
Add language support for Rust #15775
Comments
you might want to join the project discussions. There are topics for Rust and Cpp. This is a big task though and I think, stabilizing Java related toolchains is even higher on the agenda. They have progressed a lot farther. |
Agreed, we'd love this. Check out #15093. @tdyas put some great thought on how to model targets, which is IMO one of the trickier parts of figuring out this change: https://docs.google.com/document/d/1Q5h0PTusb2WyD3EScgeqUxBPF1IuEXCaa3qO31HEHjQ/edit |
Maybe we should move in inverse with LLVM based compilers.
|
@siemato could you speak more to this, please? We think a lot about Rust <-> Python interop, e.g. PyO3. But haven't put any Pants design thought into Rust w/ other languages. What does your ideal world look like? |
@Eric-Arellano sure, I'll gladly do. First of all, interoperability issues are, as much as I am aware of, either frontend or (dynamic) linking issues in LLVM land and pretty much always based on being non-hermetic in nature. An example would be C/C++ compilers greeding for their libc. That's, why I would prefer to ignore frontends for now, starting at LLVM-IR level and making sure, LLVM works properly and in a hermetic fashion. Using this foundation, I would try to keep pushing. One option would be, to use language specific frontends as LLVM-IR 'code generators', then using LLVM as a compiler. For a short tldr: Zig can compile C/C++, and does so hermetically and decoupled from the target - great for cross compilation. Bazel folks (Uber in particular, contracting the Zig foundation for support) started to use the Zig toolchain to build all their C code. This affects CFFI for Rust, CGo, generally building projects based on C/C++ in scope of cross compiling to different platforms and different libc (musl/glibc/FreeBSD-libc/...) I would strongly prefer to keep watching for now, though. As I see it, this doesn't block Rust (being hermetic), but I think it's wiser in the grand scheme, to move from backend to frontend. |
I've created a topic around a freshly released plugin for Rust support here: #20119 |
It would be great if Pants added Rust as a supported language!
The text was updated successfully, but these errors were encountered: