| commit | 3f71bedb657f2e819cc3512316bbc3c0267d7012 | [log] [tgz] |
|---|---|---|
| author | Devin Jeanpierre <jeanpierreda@google.com> | Thu Aug 15 13:03:39 2024 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Thu Aug 15 13:05:10 2024 -0700 |
| tree | 13609aa62be6f48b216d98cbb33f4da57bb69645 | |
| parent | 8a24de999f733b98cf42727bfa7a81d29a4c439a [diff] |
Rename `--bindings-from-dependency` to `--crate-header`, with an alias to keep old calls working. The problem with the old name is that it doesn't generalize: it's specifying the bindings that were generated from a given dependency, but we also want to have per-crate arguments that _aren't_ generated "from" them, and that aren't only for dependencies. In particular, we'll want a per-crate crubit feature flag argument, where one of the crates is the current crate. `feature-from-dependency` is consistent with the existing naming scheme, but misleading, I feel. So the choices were: 1. introduce a _new_ naming scheme for the per-crate feature flags, such as `crate-feature`, which is inconsistent with the per-crate header flag. 2. be consistent (`feature-from-dependency`), but misleading. 3. be consistent (`feature-from-dependency`), and make it not-as-misleading by using a different flag for the current non-dependency crate. One last thing is that I think `V_from_K` or `V_of_K` etc. names for K->V maps are somewhat rare. For example, rs_bindings_from_cc names the equivalent map just `V_K`: `target_args`. So, here, we can name it just `crate-header`. It's not entirely self-descriptive, but it doesn't need to be. "When should we delete the old name"? This isn't use in GNI or anything, so we can remove it in the next toolchain release. PiperOrigin-RevId: 663419411 Change-Id: I0bd9acb503352b9cbd6a8e7925186ade3b652365
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