![Latest Version] ![docs] ![MIT] [](https://github.com/ralfbiedert/interoptopus)

Interoptopus

C#, Python, C, ... → 🐙 → 🦀

FFI from your favorite language to Rust. Escape hatchets included.

Overview

If you ...

• have an extern "C" API in Rust,
• need C#, Python, C, ... bindings to your library,
• prefer having fine-grained-control over your API and interop generation,
• would like to use quality-of-life patterns on both sides (e.g., options, slices, 'classes') where feasible,
• might need to swiftly support a new language,
• think your FFI single source of truth should be living Rust code,

... then Interoptopus might be for you.

Known Limitations

• not yet used in production
• a bit verbose if you don't own your types (still possible, just more work)
• if you target only a single language and don't care about your FFI layer other solutions might be better

Example & Backends

Assume you have written this Rust FFI code:

```rust use interoptopus::{ffifunction, ffitype};

[ffi_type]

[repr(C)]

pub struct Vec3 { pub x: f32, pub y: f32, pub z: f32, }

[ffi_function]

[no_mangle]

pub extern "C" fn my_function(input: Vec3) -> Vec3 { Vec3 { x: 2.0, y: 4.0, z: input.z } }

interoptopus::inventoryfunction!(ffiinventory, [], [my_function], []); ```

You can now use one of these backends to generate interop code:

| Language | Crate | Sample Output | | --- | --- | --- | | C# (incl. Unity) | interoptopusbackendcsharp | Interop.cs | | C | interoptopusbackendc | myheader.h | | Python CFFI | interoptopusbackendcpythoncffi | reference.py | | Your language | Write your own backend! | - |

Features

See the reference project for a list of all supported features.

Current Status

• June 20, 2021 - Alpha. Has generated simple working<sup>TM</sup> bindings for a few projects for a week now, many things missing.
• June 13, 2021 - Pre-alpha. Has generated C#, C, Python-CFFI bindings at least once, many things missing, untested.

FAQ

• FAQ and Safety Guides.

Contributing

PRs are welcome.

• Bug fixes can be submitted directly. Major changes should be filed as issues first.

• Anything that would make previously working bindings change behavior or stop compiling is a major change; which doesn't mean we're opposed to breaking stuff before 1.0, just that we'd like to talk about it before it happens.

• New features or patterns must be materialized in the reference project and accompanied by an interop test (i.e., a backend test running C# / Python against a DLL invoking that code) in at least one included backend.