How to build this library from source for F-Droid?

[maelchiotti]

Hi, I am developing an Android Flutter app and plan to include your awesome library into it.

However, as my app is published on F-Droid, the binaries need to be built from source.

From what I've seen, scripts/build_android.sh builds the binaries. And the CMakeLists.txt only downloads the binaries if they are not already present.

So, am I right to guess that executing build_android.sh and then moving the binary to the right place is enough? Pretty much like you do in the github workflow.

[GregoryConrad]

Hey! 👋

Not familiar with F-Droid, but I'm super impressed you were able to figure all of that out on your own. Yea, you got the gist down.

and then moving the binary to the right place is enough

Yes, but one caveat: you will need to have mimir checked out locally; I'd suggest in a monorepo alongside your app. The binaries must be moved to the instance of flutter_mimir in use by your app, which normally would reside in the pub cache (so when CMakeLists.txt downloads the binaries for a regular user, it actually downloads them to the version of flutter_mimir in the pub cache). However, if you use a monorepo (with pubspec_overrides.yaml, like melos does for me here), then the version of flutter_mimir that will be used will be the one present locally in the monorepo (which is how the CI runs work, as we copy the binaries to flutter_mimir within the monorepo).

No clue how your build from source works with F-Droid, but you could also manually put those binaries in the pub cache version of flutter_mimir too, but that would be a fairly intricate process.

Let me know if you have any other questions.

This will hopefully become less of a pain in the 🍑 once dart-lang/sdk#50565 ships. I have been awaiting that feature for a long time now, and I have no easy upgrade path to the Swift Package Manager (which may means iOS/macOS builds will fail when Flutter deprecates CocoaPods).

[maelchiotti]

I have some experience doing this because I just completed this whole process for Isar, which also uses rust. Also an F-Droid maintainer pointed me to your CMakeLists.txt. So I already knew pretty much how it should go.

With Isar, I have their repository as a submodule, which I believe is easier than what you suggested since I can easily check it out and update it when you make updates. So doing the same with mimir should work.

I also do move the built binaries to the pub cache, it's actually quite easy, an mv command to the right path in the cache works.

Anyway, I can't wait for the feature you mentioned to be released, it will make this way easier!

And finally thank you so much for this package, it works so well with so little efforts 🪄

[GregoryConrad]

Ahh, a git submodule would actually be much better than what I suggested. Do that :) (just remember you’ll need to move the binaries to the version of mimir in use, whether that be from pub cache or a git submodule)

And finally thank you so much for this package, it works so well with so little efforts 🪄

of course! There are definitely still some kinks on iOS/macOS still, but those won’t impact what you’re doing with Android.

[maelchiotti]

@GregoryConrad Ok so this is mostly working. Two things an F-Fdroid maintainer asked to be changed:

• Be able to choose for which architecture the binaries should be built. For example, the build_android.sh could take optional arguments, and build only the architectures specified. So no arguments would build all, and build_android.sh x86 armv7 would build only x86 and armeabi-v7a. You can look at how isar does it. I don't exactly know why they need this but I guess it saves time and ressources if they do not need every architecture built.
• Add --locked to cargo install cargo-ndk in build_android.sh, so that it uses the cargo.lock file (if it exists) that I'm generating on my side and placing in the mimir repo to ensure that the exact same dependencies are installed on my side and on F-Droid side

[linsui]

I don't exactly know why they need this but I guess it saves time and ressources if they do not need every architecture built.

Yep, F-Droid build every apk one by one. Currently all abis are built 3 times.

so that it uses the cargo.lock file (if it exists) that I'm generating on my side and placing in the mimir repo to ensure that the exact same dependencies are installed on my side and on F-Droid side

The --locked arg doesn't use the Cargo.lock for mimir but the one of cargo-ndk, i.e. https://github.com/bbqsrc/cargo-ndk/blob/main/Cargo.lock. Without this arg, cargo just uses the latest versions of it's deps. If one of them introduces a breaking change the installation will fail.

[GregoryConrad]

The --locked arg doesn't use the Cargo.lock for mimir but the one of cargo-ndk

That's good to know--saw --locked used in other Rust repos but never understood what it was being added for 🤦

@maelchiotti Those all seem like fair requests, but I'm a bit busy right now between work/holidays. Would you mind submitting a PR for that android build script?

[maelchiotti]

Sure, I'll submit a PR asap. It's not urgent anyway.

And I misunderstood a bit the --locked when I looked for it also, so great to know.