search

jpnurmi / flutter_libserialport

Serial Port for Flutter
https://pub.dev/packages/flutter_libserialport
MIT License
143 stars 80 forks source link

use FFI/ffigen instead #46

Closed jwinarske closed 2 years ago

jwinarske commented 2 years ago

You should be using FFI to access C libs. Example usage of ffigen with libserialport: https://github.com/meta-flutter/ffigen/tree/jw/libserialport/example/libserialport

jpnurmi commented 2 years ago

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.

jwinarske commented 2 years ago

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.

jpnurmi commented 2 years ago

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.