Open bricelam opened 7 months ago
This looks like a candidate to try in my new no-xamarin
branch. :-)
Looking at the setup you had over in the SQLite3MultipleCiphers-NuGet
repo...
If I'm dropping support for classic Xamarin, it looks like I don't even really need separate lib packages for android and iOS anymore?
You've got all the binaries in one simple nupkg.
It doesn't seem like you even needed the android workload to do a build.
Yep, I tested it all on iOS and Android and it worked great
I was very proud of how much I was able to simplify things. I'm glad you took the time to look at it.
Update: I am making progress, but I'm taking the slow way, moving toward the simplified approach incrementally, making sure I understand each step.
Hmmm. @bricelam I just noticed that you generated the sqlite3 provider with FEATURE_FUNCPTRS/false
, using old style MonoPInvokeCallback
instead of the more modern C# function pointers with UnmanagedCallersOnly
. That's a bit surprising. In a post-classic-Xamarin world, I'm assuming I can just dump the old way.
(Followup later: Ah, it's because of netstandard2.0)
Given your job transition, if I should stop tagging you on things, let me know. :-)
lol, never stop tagging me! I'll catch up on GitHub as time permits. Yes, it was for netstandard2.0
While creating a new provider, I noticed that a few things could be simplified in the current iOS and Android library packages.
SQLitePCLRaw.lib.e_sqlite3.ios (before)
SQLitePCLRaw.lib.e_sqlite3.ios (after)
The .a files can be more fine-grained and put in a directory where they'll automatically be picked up by net6.0-ios. The .targets file will only be needed for Xamarin.
SQLitePCLRaw.lib.e_sqlite3.android (before)
SQLitePCLRaw.lib.e_sqlite3.android (after)
Similar to iOS, the .so files can be placed directly in the package where they'll be picked up by net6.0-android. A new .targets file could be used for Xamarin to include the .so files as
EmbeddedNativeLibrary
items directly inside the user's project.