I'm trying to build an app and trying to optimize memory footprint by separating the logic into plugins.
The app will be compiled along will all the plugins. I'll verify that the plugins were compiled together with the app somehow (.build_id perhaps).
The important part is being able to use Rust types in the parameters and name mangling.
Here's the ideal implementation:
I'm trying to avoid dropping to a C ABI, especially since I don't have to do language interop.
Here's what I have so far:
This is especially fragile because the link_name part changes whenever you change things in Cargo.toml (it's a hash), and no IDE will deal with this properly (i.e. go to definition).
I want name mangling, I want both abc::my_func() and xyz::my_func() to coexist.
I want to avoid the whole extern "Rust" { ... } part, and simply use abc::my_func;
I suppose you could instead have you primary crate produce both a bin and a library, and then have the plugins depend on the lib. But I'm not sure that's a wise choice.
Ultimately you should keep that core crate pretty lean and generally communicate through trait objects. This reduces the coupling of the plugins to the application and increases the chance that you can introduce new capabilities without having to rebuild all the plugins, if that's important to you. But if you just pass structs around, any time you change anything in the layout of that struct, you risk having to rebuild all the plugins.