use FFI/ffigen instead about flutter_libserialport HOT 3 CLOSED

libserialport.dart does use FFI. This package is just an optional wrapper package that makes use of Flutter's build system to build and deploy libserialport.

from flutter_libserialport.

I understand that, but I think it's not a good pattern. For one it masks the license of libserialport, which isn't commercial friendly, and not referenced anywhere, second for Linux I think the build system approach adds a whole lot of non-sense that is not needed; ffgen is the way to go. You might consider re-directing to your ffigen repo, and also adding a note about libserialport licensing.

For the code that is implemented in case of Linux, it's fairly trivial to implement without the not commercial friendly licensing. I'd be interested in implementing (native code) an equivalent for Linux that was MIT or Apache2.0 (commercial friendly).

Just my 2 cents.

from flutter_libserialport.

flutter_libserialport as a pure complementary package exists only and only because Flutter devs with no C/C++ background had trouble building and deploying libserialport.c with libserialport.dart.

The point behind this package separation is that you can simply choose between "dependencies: libserialport" and "dependencies: flutter_libserialport" depending on whether you want to build and deploy libserialport.c or not. There's no other difference whatsoever. Naturally, the flutter_libserialport build system covers all platforms, including Linux, even if it wouldn't make sense to use flutter_libserialport for building a Yocto device. If you have control over the system libraries then libserialport.dart is enough because you can rely on the library being there.

Even though libserialport.dart uses ffigen because it's more convenient and less error-prone than writing bindings by hand, I don't see how ffigen is relevant here. It's just a tool to generate low-level bindings - not a user-facing API.

I do share the concern about the license, though. When I first created libserialport.dart, using the same LGPL license seemed like the right thing to do. Things got more complicated when creating the flutter_libserialport package. I looked around and saw some other libserialport language bindings having a permissive license, so I went ahead with a permissive license for flutter_libserialport that merely builds and deploys libserialport.c as a dynamic library.

Both repositories have links to each other.

from flutter_libserialport.