FFI Gen Feature

[Paxa]

What is the problem this feature will solve?

Writing ffi interfaces manually

What is the feature you are proposing to solve the problem?

FFI Definition Generator

What alternatives have you considered?

Hi at first I would like to say thank you for such a great work!

Is there any plans to make generator for FFI definitions? Also if you have any perspective on how this should be implemented, I would like to know

I considering try to make it, so far I have 2 ideas

Option 1
For now I'm thinking about modifying existing library (https://github.com/node-ffi-packager/node-ffi-generate/tree/ffi-napi) or make new one that works in a similar way (it uses libclang via FFI to parse header files and generate definitions).

I found other languages have something similar:

https://github.com/rust-lang/rust-bindgen (rust)
https://github.com/ffi/ffi-swig-generator (ruby, outdated)
https://github.com/dart-lang/ffigen (dart)

Option 2
use clang parsers that dump in xml or json format and convert it to js code
https://github.com/rpav/c2ffi
https://github.com/CastXML/CastXML

Either way, I think it will be nice if it can generate js and typescript definitions that can work correctly with editor auto-complete and can automatically split code into modules

(may be it even be possible to make macos apps with native UI using bun and ffi bindings)

[evanwashere]

we actually have discussed potentially doing this using zig's powerful comptime to inspect all types and build bindings, it would remove the need to parse or produce any headers as source itself would act as comptime header

import { murmur32 } from './hash.zig';

console.log(murmur32(new Uint8Array(1024), 1024));

hash.zig:

pub fn murmur32(ptr: [*]const u8, length: u32) callconv(.C) u32 {
  const slice = ptr[0..length];
  return std.hash.Murmur2_32.hash(slice);
}

[Paxa]

Does it mean that we will be able "just load" header files during runtime? but it will require to have zig compiler in a system (if I understand comptime correctly)

[evanwashere]

Does it mean that we will be able "just load" header files during runtime?

We want to experiment with being able to import source files themselves, so yeah

but it will require to have zig compiler in a system (if I understand comptime correctly)

There are multiple ways to fix this, one of them is for bun to download its own zig compiler

This is still only an idea, so anyone is welcome to try and experiment with other ways of doing ffi bindings generation

[kassane]

@Jarred-Sumner,

Recently, when looking for some reference about bindgen. I saw that you are developing a bindgen C++ to Zig.

Could you explain how this bindgen works or intends to work?
Because dealing with API C++ using hourglass pattern becomes quite complex depending on the project to be implemented.

I've been experimenting with some bindgen:

• Zig v0.10 suirad/zig-header-gen#5 (WiP) Needs to be reworked because of some datatype changes (std.builtin).

I also tried to try SWIG for Go (there is still no C Backend for target) but it doesn't seem to be ideal.

• Zig Support swig/swig#2471

My report when exploring cbindgen-fork (Rust to Zig):
kassane/zFFI#2 (There are no plans to be reviewed, Mozilla devs did not find the proposal relevant to merge PR)

[Morglod]

Just published my bindings generator (tested on wgpu)
https://github.com/Morglod/bun-ffi-gen