Only use cargokit for all platforms

[bookshiyi]

#85 (comment)

[temeddix]

Hope this becomes a reality someday :)

For newcomers, the currently used connectors under the hood for each build target are:

• Linux: Corrosion
• Android: Cargokit
• Windows: Corrosion
• macOS: Cargokit
• iOS: Cargokit
• Web: (None)

These connectors are located in ./connectors folder of this repository. Since cargokit also supports Windows and Linux, Corrosion is not really needed. Corrosion was being used since when this project was in the draft stage.

Links to those connectors' original repository:
https://github.com/irondash/cargokit
https://github.com/corrosion-rs/corrosion

[temeddix]

When this happens, maybe hub can always be a static library. and sample_crate(as well as other new crates in production) can be dynamic libraries.

Current status of hub crate:

• Linux: C dynamic library
• Windows: C dynamic library
• Android: C dynamic library
• macOS: Static library
• iOS: Static library
• web: Webassembly(Not really relevant)

[bookshiyi]

When this happens, maybe hub can always be a static library. and sample_crate(as well as other new crates in production) can be dynamic libraries.

Current status of hub crate:

• Linux: C dynamic library
• Windows: C dynamic library
• Android: C dynamic library
• macOS: static library
• iOS: static library
• web: webassembly(doesn't matter)

Thank you for your support. It is a great idea.
Although it seems to be a little challenging, the fun is also here.

[temeddix]

Yeah it is a challenging task, and I can say that it is not so urgent. This more looks like a nice interior refinement :)

[temeddix]

For anyone who might be working on this in the future, I will leave the link to a good reference project that also(and purely) uses cargokit:

https://github.com/superlistapp/super_native_extensions

[bookshiyi]

For anyone who might be working on this in the future, I will leave the link to a good reference project that also(and purely) uses cargokit:

https://github.com/superlistapp/super_native_extensions

Yes, it's a good example, I am trying to transplant and combine to this project.

[temeddix]

Don't need to hurry, if we're going to do it, we can dive in when we have spare time haha

[knopp]

In case it helps here is bit of documentation regarding cargokit: https://matejknopp.com/post/flutter_plugin_in_rust_with_no_prebuilt_binaries/

I should probably link it in cargokit readme.

[bookshiyi]

In case it helps here is bit of documentation regarding cargokit: https://matejknopp.com/post/flutter_plugin_in_rust_with_no_prebuilt_binaries/

I should probably link it in cargokit readme.

Wooo, It is very useful.
Thank you.

[temeddix]

@knopp Thanks! Maybe we can also contribute to cargokit development in the future from what we learned here.

[bookshiyi]

@knopp Thanks! Maybe we can also contribute to cargokit development in the future from what we learned here.

So great idea~ Let's do something interesting together.

[temeddix]

From that article, I can see that cargokit was designed to compile Rust crates to cdylib for Linux, Android, and Windows. I think we should keep the usage of cdylib/staticlib as it is.

[knopp]

The plan was initially to use cdylib on all platforms. Unfortunately there are issues with using cdylib with cocoapods so for the time being static libraries are needed on iOS and macOS and the linking step is moved to podspec.

[temeddix]

I see, I also remember flutter_rust_bridge stated that iOS requires staticlib.

[knopp]

Initially the Rust iOS target didn't support creating dynamic libraries at all. That is now fixed. The bigger problem is integrating with cocoapods (which FRB doesn't do) where XCode doesn't always relink with correct dylib version when the cdylib rebuilds. So unless I figure that out sticking to static lib on macOS and iOS is the way to go.

[temeddix]

Great explanation, thank you for your insights.

[temeddix]

Solved with #114