Moving to dart FFIGen

[JoschuaL]

Du you have plans / would be open accept a PR to port the automatic part of the binding generation to dart-lang/ffigen ?

Using a officially supported package generally seems like a better idea than a custom one. I don't know if you plan to support your rust solution in the future (as I understand, that crate is also developed by you. Also, ffigen seems to have more functionality (nested structs, fixed size arrays)

[shekohex]

Hey @JoschuaL Yes, actually in recent issue I commented here https://github.com/shekohex/flutterust/issues/22#issuecomment-800129212 that I want to switch to ffigen, and archive the dart-bindgen repo.

but Yes, would love to see a PR for adding support for it, also will review it :)

One thing I should mention here that, it needs to be invoked from cargo make, so the flow should be the same, also I don't know yet, if ffigen supports custom code injection (by that I mean, adding custom function/declaration to the generated code from the configuration). since we will need that to add the support for allo-isolate crate (there is a hook needed to be added to the bindings).

Thanks!

[JoschuaL]

The options to include support for allo-isolate would be to

1. Add the necessary dart code as a preamble in the configuration of ffigen
2. make cbindgen on the rust side aware of the required functions for it, so they are included in the C header (so ffigen can create the bindings for it automatically)
3. Include a pre-made header file with the allo-isolate crate to copy and use with ffigen

1 has the problem of needing to write a chunk of code in the .yml file of each plugin that uses 'allo-isolate' that the developer would need to copy-paste manually every time

I don't know if 2 is possible (or rather, i don't know why 2 does not already work out of the box) and I lack the required knowledge to implement it

I also don't know if 3 is possible, because I don't know if c headers can just be shipped with crates. Alternatively, there could be a build hook in "allo-isolate' that just outputs a header file on build similar to cbindgen. Since integration with flutter is probably the only use case for it anyways, that does not seem to be too problematic in terms of generating unwanted build artifacts.

I could probably use 1 as a MVP in the PR i'm working on, though I suppose 2 or 3 would be better in general.

So I'd be happy to hear any opinions or alternative suggestions on how to proceed.

[shekohex]

For option 2 sounds like cbindgen allow parsing crates too, so I guess we should give it a try first. in our build.rs we should add it to the config https://github.com/shekohex/flutterust/blob/56ba0e9603607c0e9dcc79c1511a93150c342911/native/scrap-ffi/build.rs#L5-L17

From the cbindgen docs we set parse_deps to true and adding allo_isolate to include too.

One Issue I guess we would face is the callback function defined here https://github.com/sunshine-protocol/allo-isolate/blob/2e7a25e96e1790c245e7686090f7a503b147082d/src/ffi.rs#L126-L127 Not sure if the cbindgen would be able to define it correctly and if ffigen in dart would possible. but worth the try!

Please Keep me updated!

[JoschuaL]

seems that including the crate with cbindgen works well enough. But using ffigen requires ffi version 1 now, so porting that needs to happen first. I opened a PR for that.

[jerel]

I just ported our project to use ffigen 1.0 since dart-bindgen is deprecated and this worked well for allo_isolate:

// manually added this in lib.rs of our rust project
#[no_mangle]
pub unsafe extern "C" fn store_dart_post_cobject(ptr: DartPostCObjectFnType) {
  allo_isolate::store_dart_post_cobject(ptr)
}

and then in the Dart code:

final example = NativeLibrary(DynamicLibrary.open('libfoo.so'));

// note that this now uses the address int because of the headers ffigen generates
example.store_dart_post_cobject(NativeApi.postCObject.address);

[tojocky]

Any progress on this issue @JoschuaL and @shekohex ? I would be glad to see the PR created finished and merged.

Thank you in advance

[shekohex]

Any progress on this issue @JoschuaL and @shekohex ? I would be glad to see the PR created finished and merged.

Not yet as we both got super busy with other work, they started working on a PR here #25 but we face some issues, would be great if you could help progress this!