metal-rs VS rust-bindgen

I found working in rust with these bindings much easier https://github.com/gfx-rs/metal-rs

An alternative would be to use rust bindings for metal with gfx-rs/metal-rs. There is a metal compute example in the examples folder.

Thanks very much for this detailed information, it's very helpful. I've filed https://github.com/gfx-rs/metal-rs/issues/222 to track it in the Rust ecosystem side.

Rust bindgen[1] will automatically generate native Rust stucts (and unions) from C headers where possible. Note that c_int, c_char, etc. are just aliases for the cooresponding native Rust types.

However, not all C constructs have idomatic Rust equivalents. For example, bitfields don't exist in Rust, and unlike Rust enums, C enums can have any value of the underlying type. And for ABI reasons, it's very commom in C APIs to use a pointer to an opaque type paired with what are effectively accessor function and methods, so mapping them to accessors and methods on a "Handle" type in Rust often is the most idomatic Rust representation of the C interface.

[1]: https://github.com/rust-lang/rust-bindgen

You only hand-write function bindings in simple or well-constrained cases.

In general, the expectation is that you will use bindgen [0].

It's a very easy process:

1. Create a `build.rs` file in your Rust project, which defines pre-build actions. Use it to call bindgen on whatever headers you want to import, and optionally to define library linkage. This file is very simple and mainly boilerplate. [1]

2. Import your bindgen-generated header as a module and... just use it. [2]

You can also skip step 1: bindgen is also a CLI tool, so if your C target is stable, you can just run bindgen once to generate the Rust interface module and move that right into your crate.

[0]: https://rust-lang.github.io/rust-bindgen/

[1]: https://rust-lang.github.io/rust-bindgen/tutorial-3.html

[2]: https://github.com/Charles-Schleich/Rust-Bindgen-Example/blo...

Well, I don't use makefiles to deploy software with Rust. I also have never used lex or yacc, but I bet there are similar tools in the ecosystem, or wrappers for those. That would obviate what I will offer below.

Often a new language in a project would define an application boundary. So those would be different containers or services. I may deploy via container images, or an OS specific installer, etc. If we aren't crossing an application boundary I may use FFI. Sometimes I use https://rust-lang.github.io/rust-bindgen/ to smooth that over for C dependencies. There is also a nice concept called a build.rs file: https://doc.rust-lang.org/cargo/reference/build-script-examp.... There's also tools like: https://github.com/casey/just and https://sagiegurari.github.io/cargo-make/

I rarely use multiple languages with Rust. A lot of interpreted languages have bindings through crates and can go in to a project through Cargo. If it involves JS/TS on desktop, I'm usually using Tauri for that. Guess it depends on the system?

Hopefully that helps. You can also still use a Makefile if you want I just haven't dealt with one in a long time.

Essentially, this has been Rusts value proposition from the outset - build a language that you can integrate into other codebases seamlessly, hence the choice of no runtime, no garbage collector etc. Bindgen (https://github.com/rust-lang/rust-bindgen) and similar tooling were around essentially since day one to assist in that.

It’s the only approach that has any chance of transitioning away from unsafe languages for existing, mature codebases. Rewriting entirely in a different language is not a reasonable proposition for every practical real-world project.

Now, if you have a complex library and don't want to write all of the declarations by hand, you can use a tool like bindgen to automatically generate those extern declarations from a C header file: https://github.com/rust-lang/rust-bindgen

There's an argument to be made that something like bindgen could be included in Rust, not requiring a third party dependency and setting up build.rs to invoke it, but that's not really the issue at hand in this article.

The issue is not the low-level bindings, but higher level wrappers that are more idiomatic in Rust. There's no way you're going to be able to have a general tool that can automatically do that from arbitrary C code.

Rust supports two kinds of FFI: calling into Rust from another language; and calling into another language from Rust. Most of the thought and tooling that exists right now is organized around the second kind. For example, bindgen is a popular tool that generates useful Rust wrappers from a C or C++ header file.

I have looked into bindgen, but found that it would not be feasible due to OMPL not having a C API, just C++.

Yes! Are you running LLVM version 16.0.0 or newer, by any chance? I believe this is an issue with some builds of bindgen with newer versions of LLVM. See https://github.com/rust-lang/rust-bindgen/issues/2488

On native, you have to define a C API, probably using a header file. Even if both sides are implemented in Rust, they have to speak that C API (documentation).