To replace *.udl with use of Uniffi proc macro initially

[Binlogo]

Try to fix #131.

Progress of samples.

• [x] hello_world
• [x] simple_counter

Known issue tracking:

simple_counter

• [x] uniffi-bindgen using a library file failed.
  • uniffi-bindgen generate --library target/release/libshared.dylib --language swift --out-dir generate/swift/SharedFF
    • Error: cargo metadata returned 2 packages for crate name shared
    • Potential reason: conflict because following crate conflict.
      • "crate_types":["lib","staticlib","cdylib"]
      • "crate_types":["bin"]
    • Potential solution:
      • ~~[x] Move uniffi-bindgen bin out of shared package.~~
        • ~~Note: but still failed in 0.28.0 version.~~
      • ~~[ ] Submit a PR to update uniffi-bindgen to ignore crate of bin kind.~~
        • It seems that this https://github.com/mozilla/uniffi-rs/pull/2175 solved this issue. 🎉Just wait for version update.
        • [ ] Update uniffi to next release version.
• [ ] Still need a build phrase for Xcode project or just generate bindings in advance like SharedTypes package?.
  • [x] Include SharedFFI as sources

[Binlogo]

@StuartHarris Hi, if you're interested, please review this PR. Any concerns or suggestion, just comment. If this solution works for us, we can provide or update more examples using this procedural macro approach.

[StuartHarris]

Hey @Binlogo — thank you for this! I love the direction it's heading in. I looked through the diff and got quite excited. 🎉 I will dig in deeper when I get a chance over the next couple of days. 🤗

[charypar]

Thanks a lot for having a go at this, it looks like it will simplify the UniFFI setup a fair bit!

[Binlogo]

Additional notes: To replace *.udl with the Uniffi proc macro for generating bindings, we still rely on an intermediate product, '--library target/release/libshared.{dylib, so}'. This process is not as straightforward as I initially thought. We may need to reconsider the project structure.

• Should the generation of all bindings be driven by the iOS/Android side?
• Should the binary and bindings be combined into a single task? A deeper investigation is required.

[charypar]

Indeed, there are fundamentally three parts we need to produce from the shared crate:

• The library target built by cargo which the shell links to (.dylib/.so/.wasm)
• The uniffi bindings generated by the uniffi-bindgen command for each language to surface the base core interface
• The generated types from serde-generate to get equivalents of Rust types which cross the FFI boundary, which can serialize and deserialize across the languages

I think the latter two steps can probably be combined into a single step. It may even be possible to make them a single tool - we may be able to import and call some of the code the uniffi-bindgen tool runs in the same bin target as the one running the serde type generation and run both in one go. That may even allow us to target a specific language.

[StuartHarris]

Thank you for your work on this @Binlogo ❤️

I'm closing it in favour of #347 which adds a new bridge macro that uses uniffi proc macro annotations. It also adds a counter-next example that simplifies the iOS and Android projects. This is an evolution towards a better DX for Crux apps, and can (and will) still be improved.

[Binlogo]

Thank you for your work on this @Binlogo ❤️

I'm closing it in favour of #347 which adds a new bridge macro that uses uniffi proc macro annotations. It also adds a counter-next example that simplifies the iOS and Android projects. This is an evolution towards a better DX for Crux apps, and can (and will) still be improved.

Ok, it sounds like a significant step towards improving the DX for Crux apps. I'm looking forward to seeing how the new bridge macro enhances Crux.