add lib crate-type to bdk-ffi to be able to reuse it for other bindings like bdk-dart

[kumulynja]

Description

This PR just adds "lib" as a crate-type besides "cdylib" and "staticlib". In this way bdk-ffi can be more easily wrapped and reused for other bindings like the dart bindings in bdk-dart. Without it, more code from bdk-ffi has to be duplicated to bdk-dart and the process becomes more complex and hacky.

Notes to the reviewers

I tested this PR in the following bdk-dart PR already: bitcoindevkit/bdk-dart#12
It would be good to get this merged here first to be able to remove the patch to my fork of bdk-ffi there.

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing
• I've added a changelog in the next release tracking issue (see example)
• I've linked the relevant upstream docs or specs above

[thunderbiscuit]

I'm not against this change per se, but I'd like to understand better why the plugin for dart needs it when others don't (JVM, Android, Swift, Python, React Native).

I took some time to clean this up a while back and my understanding was that the lib type is required in situations where your Rust code is used as a dependency itself, whereas for us here it's the compiled artifacts that are used by the plugins.

Again I'm not against it because it doesn't impact us negatively other than build times, but I want to make sure I know why each of those crate types are required (cdylib is for Android/JVM/Python, staticlib is for iOS).

[kumulynja]

I'm not against this change per se, but I'd like to understand better why the plugin for dart needs it when others don't (JVM, Android, Swift, Python, React Native).

I took some time to clean this up a while back and my understanding was that the lib type is required in situations where your Rust code is used as a dependency itself, whereas for us here it's the compiled artifacts that are used by the plugins.

Again I'm not against it because it doesn't impact us negatively other than build times, but I want to make sure I know why each of those crate types are required (cdylib is for Android/JVM/Python, staticlib is for iOS).

It's because Dart has a new build system that does the compiling of the artifacts/native code dynamically when a user imports the bdk-dart package. So as maintainers of bdk-dart, there is no need anymore to distribute pre-built native libs upfront. This greatly reduces the maintenance burden for bdk-dart since packaging/distribution/bundling of the native libs are a real pain otherwise.

The only requirement is that the native/foreign code (Rust in the case of bdk) is part of the Dart project itself so it can be published together with the Dart package. Since bdk-ffi and bdk-dart are separate repositories, this requirement is not met, but we added a very small Rust project in bdk-dart that just exports bdk-ffi to solve this. To be able to do that, bdk-ffi needs to be used as a dependency in this small wrapper as you can see here: https://github.com/kumulynja/bdk-dart/tree/2c5cd9ccfd647d2695e52150a7670730b28020b7/native

Here is some more context about Native Assets in Dart and it being the new standard and way to go for bindings:

Build hooks 🚀
Integrating native code (like C++, Rust, or Swift) into a Dart package has often required managing complex, platform-specific build files like CMake or Gradle. With Dart 3.10, this process is now dramatically simpler.

We’re excited to announce that build hooks (formerly known as native assets) are now stable. You can use these hooks to compile native code or download native assets (like dynamic libraries) and bundle them directly with your Dart package. This powerful capability lets you reuse existing native code or libraries from within your package and eliminates the need to write separate build files such as SPM, Gradle, or CMake for different operating systems.

source: https://blog.dart.dev/announcing-dart-3-10-ea8b952b6088

[reez]

ACK ea7be23

Thought a good bit about this, I think because it's such a minimal change and is a big unblock for bdk-dart im in favor. I know it slows down build times, but that as well was minimal in my testing: dev builds ~+0.66s, release builds ~+1.03, release-smaller negligible.

The other alternatives are to do nothing or a much larger refactor, so this PR seemed like a clear winner in my mind of all the options.

Open to anyone else's feedback or if I missed anything

[thunderbiscuit]

Sounds good! Again not a problem on our end (thanks for testing the time diff @reez).

But just for my own curiosity I'd love to know more about how it impacts the builds/users of bdk-dart. Maybe we can add it as an agenda item on the next dev call @kumulynja? Mostly I'm wondering about whether this means that the "build" then becomes user-side and so we offload the difficulties of Rust compilation onto Flutter/Dart users who might not have the Rust toolchain installed or other little quirks instead of having it already precompiled + bundled for them. Like are the artifacts compiled user-side (apps that add bdk-dart as a dependency) or is it somehow done at the bdk-dart layer, and the artifact we publish on pub.dev are all ready to go?

[thunderbiscuit]

@kumulynja would you mind squashing your two commits into one? Then this one is ready to go and I'll merge it today.

[kumulynja]

@kumulynja would you mind squashing your two commits into one? Then this one is ready to go and I'll merge it today.

Done!

[kumulynja]

Sounds good! Again not a problem on our end (thanks for testing the time diff @reez).

But just for my own curiosity I'd love to know more about how it impacts the builds/users of bdk-dart. Maybe we can add it as an agenda item on the next dev call @kumulynja? Mostly I'm wondering about whether this means that the "build" then becomes user-side and so we offload the difficulties of Rust compilation onto Flutter/Dart users who might not have the Rust toolchain installed or other little quirks instead of having it already precompiled + bundled for them. Like are the artifacts compiled user-side (apps that add bdk-dart as a dependency) or is it somehow done at the bdk-dart layer, and the artifact we publish on pub.dev are all ready to go?

I have a conflicting meeting tomorrow, so I won't be able to connect to the call sadly, but you already got it right: we offload the Rust compilation to the users (devs) adding bdk-dart as a dependency to their app. So yes, the user's machine (or CI) will indeed need the Rust toolchain so that when they build their app, the Rust library is compiled by the Dart build hook (implemented in bdk-dart) for the specific target the app is being built for. So in the "Get started" or "Usage" section in the README of bdk-dart we should clearly add the instruction to Install rustup for example.

It greatly simplifies things on the bdk-dart side while adding an extra requirement for users, so it is a trade-off indeed, but I think it is a justified trade-off since shipping prebuilt binaries inside a Dart/Flutter package (for each platform/arch) is not that trivial, and, even when hosting prebuilt binaries, similar problems/trade-offs exist as is mentioned here: dart-lang/sdk#50565

An advantage of the envisioned build hook approach is that it keeps our options open: in the future we could still add support for prebuilt binaries by extending the build hook to download them when available, with source compilation as a fallback (or controlled via build flags). Starting with build-from-source gives us a solution that works out-of-the-box on any platform and architecture without additional complexity on the bdk-dart side for now.

[thunderbiscuit]

ACK a3d8365.