convert to Flutter plugin package

[maks]

Given there is no good solution at the moment for distributing packages with dynamic libs using FFI the easiest thing to do for now is to convert this into a Flutter plugin package for which there is documentation on how to distribute dynamic libs in the package.

[alexmercerind]

Oh I saw this now. I was saying the same thing.

Although, if you use the plugin format, then you can still use the FFI (although its not easy). And thus, the thing can be cross platform.

[maks]

@alexmercerind yes this is the main annoyance I can see so far in that there is no good way to publish dynamic platform libraries in a pure Dart pub package.
But I'm not sure what your concern is about using FFI? as from what I can see using async callbacks with Dart FFI has been documented and there is sample code available.

Also per your other comment, I'm not sure I understand what you mean you can't run CMake for plain Dart files? Sure its not part of standard build process as it is for example for Android apps but there is nothing stopping you having that as part of your packages build process, for example using a Grinder script.

[alexmercerind]

Hi there @maks !

Yes, those async callbacks are using NativePorts mechanism (I linked that issue in my previous comment).
The most advance structure that you can transfer between Dart & C/C++ through FFI is just array of string. And, things like event callbacks atleast need to contain player instance id, along with the other information the callback is taking place for.

you can't run CMake for plain Dart files

I meant like when the Dart library is distributed as a plugin, it executes a CMake script to get the plugin's C++ code ready & compiled to be linked with the app. But in case of a plain Dart or a simple package, there is no starting point to run a CMake script after a Dart/Flutter developer installs the package. The developer then, himself has to run the CMakeLists to get its dependencies (headers, libs & dlls) ready, which a plugin does out of the box.
(Even in the official FFI examples, one has to compile DLLs himself or as they are using docker to get things ready here).

So, changing to plugin is the good solution, by that you can setup FFI things (if you wish).

[maks]

@alexmercerind I think I can help with that, these ports are the same SendPort mechanism used within Dart to communicate between Isolates, so there is really no limitation to what data can be sent. The only limitation is really to do with performance, especially deserialisation on the Dart side, but thats exactly the same problem people face at the moment shipping large amounts of data between Main and worker Isolates. Its also something the Dart team are working on addressing soon too with sendAndExit functionality, though I'm not sure if that will be able to be used for this.

With CMake, thats exactly what I meant in when I created this issue, at the moment, the package developer needs to ship prebuilt binaries of the the dynamic library the package uses if the package uses it's own library, versus a system installed one, eg. on my linux system, alsa is available at /usr/lib/libasound.so.2 so Dart FFI code could make use of it directly without needing to ship any native code in pure Dart package, but if I want to make use of miniaudio, I'll need to precompile it and ship it within the package, with a separate dyn lib file for every platform I want to support with the package, just as for example Android AARs do.