-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wish for a more complete guide to using precompiled libraries in plugin_ffi template #1855
Comments
Hi @vongohren!
We'd like to move away from With the native assets feature, you define a
Not yet. But the goal is that for flutter release builds we'd be able to use the native linker to tree-shake the native code to reduce the app size (#153). Whether after tree-shaking the native code is bundled as a dynamic library, or linked statically is somewhat less important. (But that is tracked here: dart-lang/sdk#49418, dart-lang/sdk#47718.) So at this point we're not prioritizing improving the workflow with prebuilt libs in |
@dcharkes thanks so much for a solid answer! So for a long term perspective, I should focus on the package_ffi direction for native assets? I can also use dylib, it was just not what I had available immediatly. Last question, are there any other docs on the package_ffi? I did not immedatly find its place? |
Yes, but it only works with an experimental flag. So keep that in mind. (If you were to publish a package, it would only work in apps if the person building the app passes the experimental flag. And we might still break you while it is an experiment.)
Also, I'm in the process of addressing how to do prebuilt libraries: |
Cool, thanks for the quick follow up! I will close this for now and I assume my requets are a given and will come when work come towards an end :D What are your guyses timeline? We are not doing anything public but an app will go public at some point |
As soon as possible, but only when we're satisfied with the overall quality of the feature. At this point it's hard to say, we're iterating until we've satisfied all our requirements and we're confident we don't have to break people later.
As long as you're publishing an app to the store (and not publishing packages), using the experiment should be fine. We'll try to break you as little as possible while adding more functionality. |
Great thanks for that update. I seem to be able to turn on the flag, but get this error when running
|
You need to be on the |
Some follow up after some work In short, this is a replacement for plugin_ffi? |
Correct. 👍
The build hooks run during the Flutter build and the produced dylibs are bundled in the app bundle. (We haven't looked yet on how these dynamic libraries interact with deferred loading. Presumably we should be able to defer loading of them with Flutters deferred components. #1092 That could postpone downloading dylibs until the deferred component is needed while the app is already running potentially.) |
Thanks for the swift replies. I have one more question. Which seems undocumented? I have created the package. And out of the box I can do However, I dont see any where how to build the package itself? I dont get any feedback when adding print("BUILD FILE") in the build.dart? I run I have turned on the flutter channel and config, but dont see a way to do this for dart? If this is nessecary? |
You don't build the package itself, all transitive packages with native assets have their native assets build on
Try adding
Dart has a different experiments logic than Flutter. Dart is per invocation. But the flag shoud be in front.
|
@dcharkes thanks! Important questions
I still dont get anything. I get a verbose logfile, but no mention of the print methods I have in this image. Would be very helpful to get some output for lowering the roundtrip times of developing the build.dart file 😅 flutter clean solves the build deletion issues mentioned earlier ffi gen combined with native assetsI see a direct link between the linking of the generated files and source when doing the from source solution. But how is the link when doing f.eks dylib or so? Its still just through the .h file and since its compiled together, it hopefully works :D? Replies
Cool cool. This means that when I publish the package, it is published "unbuilt" and people add it to their setup and when building the app its built? Interesting approach!
Thanks, did the trick! |
ConcernIm sorry if this is sub optimal flow, as the issue is closed and all. What other options do you propose for a better back and forth? I think atleast im a prime candidate for the new flow, as im new to this and can really glide out the quirks of the documentation, as I need assistance to get to a certain level. UpdateRight now I tried to follow a build style from your latest PRs I decided not to download for now as I just want confirmation that it all works properly and Im attached to the process in the right way. I decided to load all files locally like this and run the setup. See the code below. Questions I do have though: QuestionsWhat connection does the name in CodeAsset have to everything working? How can I verify that the files are loading to the right place? Or is this the right direction too look into? Build
OutcomeBut im getting the following error. With trying to only expose small parts of the code. Code
Error
|
A couple more question
|
Yes, it uses |
Info
This is both a feature request, and a requets for help
I have seen issues similar to this, which tells me there is no clear guide on this:
dart-archive/ffi#184
#489
Feature request
I would like to see a better guide where one use the precompiled libraries for mac,ios and android as sources for the plugin.
android to use
.so
filesiOS to use
.a
or.dylib
files. Preferebly both if there are any differences. And of course the.h
files.Im in a situation where I want to build a plugin but only have these files available.
Or even its own template that outputs the precompiled setup rather then a setup where the source is needed.
Request for help
What do I have to do to get this to work for these platforms and what are the pitfalls I have to think about.
Android
From the issues above, one have to add the .so files into the pluging and change the gradle build it seems. Is the 184 issue, on the right direction?
iOS
This is a bit more complicated, this issue talks about
.dylibs
. But can.a
files be used just as easily? Does it exists any reference on the.a
file direction?I like the way that one primarily just add the files to podspec and that takes over the flow. Is this also possible for
.a
files?Questions
Are there any pitfalls to this direction?
Is it recommended to go the
.c
source direction if possible?The text was updated successfully, but these errors were encountered: