Add binary to remove the need for uniffi-bindgen cli tool

[thunderbiscuit]

WIP; I'm not as confident in my Rust as I am in my Kotlin. Feel free to tear apart my implementation or let me know where to improve.

This adds a binary called generate-bindings, which intends to be a drop-in replacement for the uniffi-bindgen tool from the perspective of the language bindings repos bdk-kotlin and bdk-swift.

In short, as part of the new Gradle plugin proposed in bitcoindevkit/bdk-kotlin#32 or simply in the build.sh file, we should be able to replace the line

uniffi-bindgen generate src/bdk.udl --no-format --out-dir ../jvm/src/main/kotlin --language kotlin

by the line

cargo run --bin generate-bindings -- --language kotlin --out-dir ../jvm/src/main/kotlin

This will ensure we're always using the same version of uniffi-rs for building the native libs as the version used to generate the bindings files.

[thunderbiscuit]

We might want to discuss how to merge the Python one into this to have only one generate binary, but for this PR I wanted to keep it as simple as possible, and because Python requires special care with the replacement of some lines in the bindings file, I decided to focus the work on just Kotlin and Swift.

[notmandatory]

I took a stab at rewriting this with the structopt dependency which makes it easy to get cli or env program options. See my fork here. I also simplified the env names @afilini used for the original generate python tool.

Using structopt we also get pretty help messages for free:

% cargo run --bin generate-bindings -- --help
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/generate-bindings --help`
generate-bindings 0.3.1
A tool to generate bdk-ffi language bindings

USAGE:
    generate-bindings [OPTIONS] --language <language> --out-dir <out-dir>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
    -l, --language <language>
            Language to generate bindings for [env: UNIFFI_BINDGEN_LANGUAGE=]  [possible values: kotlin, swift, python]

    -o, --out-dir <out-dir>
            Output directory to put generated language bindings [env: UNIFFI_BINDGEN_OUTPUT_DIR=]

    -p, --python-fixup-path <python-fixup-path>    Python fix up lib path [env: UNIFFI_BINDGEN_PYTHON_FIXUP_PATH=]

[thunderbiscuit]

Will review and test tomorrow. Looks good so far! As long as we're ok with adding the dependency, I think we get a much cleaner tool.

[thunderbiscuit]

Ok this is 10x better than mine. testedACK on @notmandatory's branch.

I tested with all 3 languages, including the Python path fix. Everything worked as expected. I'm not sure of the potential costs of adding the dependency so I'll leave this to others to chime in, but if we are ok with adding structopt then this is the way to go.

I wonder if we could hide the

println!("Python fix up lib path is {:?}", opt.python_fixup_path);

inside the if opt.language == Language::PYTHON statement so as not to show it when kotlin or swift is the chosen language.

[notmandatory]

Thanks for testing, I'll make a new PR from my fork and move the python println! so it won't show for the other langs. I also want to see if I can have the structopt dependency only for the bin, since it's not required at all for the lib.

[thunderbiscuit]

Sounds good. When your PR comes in I'll close this one. I'll also start working on integrating this in the Gradle plugin for bdk-jvm and bdk-android.

[thunderbiscuit]

FYI after asking a question on the uniffi-rs repo about how to make sure the two parts of building the bindings libraries are always in sync version-wise, I got insights into how they're doing it. The answer is that it's a known issue for sure, and in fact their solution is to have a separate crate used exclusively for making sure the two versions are in sync. It's very similar to the idea here of having a binary that calls the uniffi-bindgen tool internally rather than relying on the command-line tool.

Their external crate is here.

[notmandatory]

Closing in favor of #126. But thanks for lighting the fire on this one!