| commit | fa911e597502443b3633b59bf284004125db3deb | [log] [tgz] |
|---|---|---|
| author | Devin Jeanpierre <jeanpierreda@google.com> | Thu Aug 29 00:23:31 2024 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Thu Aug 29 00:24:25 2024 -0700 |
| tree | aeae5d6610b626991b9cd9c9eceddea7540b079d | |
| parent | 8c9013f5a42f2ea3142a370100534a6a9bea6cba [diff] |
Use a toolchain to resolve the crubit binary. Without using toolchains, or some other solution that also spares the build graph to the same extent, C++/Rust interop via Crubit is incompatible with some binaries, because it would introduce an unacceptable increase to the size of the build graph at analysis time. Before this CL, we used `select()` to find the actual binary that generates the bindings. `select()` is resolved pretty late, and so puts everything from every branch on the dependency graph at analysis-time. Yet production builds literally only take the branch of the `select()` which depends on just a single binary! So, by making this a toolchain, and evaluated sooner (as I understand it), we cut the number of imagined dependencies significantly. (I am not a bazel expert.) We can repeat this for the other uses of select in Crubit (ESPECIALLY for the C++ standard library) to cut the dependencies even further, hopefully so that, by the end of the toolchainification, all or almost all analysis-time deps are in fact the real dependencies. --- This CL does not port over the prebuilt-for-debugging option. That was obsoleted by crubit on demand, so there's no point. It is now deleted. I'm not 100% sure on code organization here, but overall I'm pretty pleased with how this worked out. I do think it will not be as pretty once we add standard library headers to this (possibly a bunch of toolchains created by a list comprehension), but on the plus side it might mean we can totally kill the is_on_demand bool, so we'll see. PiperOrigin-RevId: 668800654 Change-Id: I36a5d8c3bff8c77cf15b1abdc07f75b7f9f27055
NOTE: Crubit currently expects deep integration with the build system, and is difficult to deploy to environments dissimilar to Google's monorepo. We do not have our tooling set up to accept external contributions at this time.
Crubit is a bidirectional bindings generator for C++ and Rust, with the goal of integrating the C++ and Rust ecosystems.
Support for calling FFI-friendly C++ from Rust is in progress.
Support for calling Rust from C++ will arrive in 2024H2.
Consider the following C++ function:
extern "C" bool IsGreater(int lhs, int rhs);
This function, if present in a header file which is processed by Crubit, becomes callable from Rust as if it were defined as:
pub fn IsGreater(lhs: ffi::c_int, rhs: ffi::c_int) -> bool {...}
Note: There are some temporary restrictions on the API shape. For example, functions that are not extern "C", or that accept a type like std::string, can't be called from Rust directly via Crubit. These restrictions will be relaxed over time.
Here are some resources for getting started with Crubit:
Rust Bindings for C++ Libraries is a detailed walkthrough on how to use C++ from Rust using Crubit.
The examples/cpp/ directory has copy-pastable examples of calling C++ from Rust, together with snapshots of what the generated Rust interface looks like.
$ apt install clang lld bazel $ git clone git@github.com:google/crubit.git $ cd crubit $ bazel build --linkopt=-fuse-ld=/usr/bin/ld.lld //rs_bindings_from_cc:rs_bindings_from_cc_impl
$ git clone https://github.com/llvm/llvm-project $ cd llvm-project $ CC=clang CXX=clang++ cmake -S llvm -B build -DLLVM_ENABLE_PROJECTS='clang' -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=install $ cmake --build build -j $ # wait... $ cmake --install build $ cd ../crubit $ LLVM_INSTALL_PATH=../llvm-project/install bazel build //rs_bindings_from_cc:rs_bindings_from_cc_impl