[WIP] Using UniFFi bindgen as a cargo subcommand

[skhamis]

Discussion #472

Taking a crack at making a more robust UniFFi CLI that allows for more flexibility as well as potential new tooling for checking environment to ensure success when building using UniFFi.

Suggestions welcome!

To install: In the bindgen dir -> cargo install --path . will install two binaries uniffi-bindgen and cargo-uniffi

To use:

• (used today) uniffi-bindgen <commands>
• (new subcommand) cargo uniffi <commands>

New args: cargo uniffi check -l [language] will ensure that you have things properly installed (in progress) cargo uniffi check ? will check scaffolding and udl files are properly setup

Planned changes:

• [X] Ability to have uniffi-bindgen as a subcommand ex cargo uniffi scaffolding <udl>
• [X] Adding a check command to check if local environment can succeed in building the foreign language bindings
• [X] Adding checks to the build process to ensure the udl is correct
• [ ] Check to see if there are not conflicting uniffi-bindgens installed(?)
• [ ] Attempt to integrate with the work in #997

  The possibility of split back-ends will mean we potentially should look into allowing "plugin-like" format for different bindgen into the core and defer to those bindgens via external subcommands to allow language-specific crates to have their own set of commands

[skhamis]

Trying to write some "production-ready" code and thinking about this just a tad bit more. I wonder if it makes sense instead of having a cargo uniffi check command with all different args underneath it. We actually include a different arg called --dry-run that runs within the generate, scaffolding, etc commands which will then check the environment and that everything compiles fine with helpful statements instead of a side check....thoughts @rfk (and of course anyone else)?

[rfk]

We actually include a different arg called --dry-run that runs within the generate, scaffolding, etc commands which will then check the environment and that everything compiles fine with helpful statements instead of a side check

It sounds worth a try! One thing about a separate check command could be that it's in a position to do more expensive checks than you might want in your build process by default (for example, it could shell out to cargo metadata and look at all the crates in your dependency tree in order to check that things look OK, while you might prefer that your day-to-day build process avoid this overhead by assuming everything is properly configured). But, I guess the --dry-run flag could also enable such checks!

[rfk]

Ability to have uniffi-bindgen as a subcommand ex cargo uniffi scaffolding

So here's an example of something that I think would be a really interesting direction for UniFFI - what if I didn't need to specify the <udl> path explicitly here? That is, what if cargo uniffi scaffolding did the right thing without having to specify any options?

There are a number of ways we could achieve that:

• Configure the path to the .udl file in Cargo.toml and/or uniffi.toml.
• Presume some default filename like ./src/interface.udl if one isn't specified.
• (...eventually get rid of UDL files altogether in favour of macros 😁)

What I'm interested in is the big-picture shift from pointing at an interface file, to pointing at the crate itself.

[jplatte]

Given the progressing work on #1257, it might not sure a whole lot of sense to continue work on improving UDL-related workflows, which are likely going to be replaced entirely by that in a few months.

[badboy]

the uniffi-bindgen binary is since gone, so this would need some rethinking. I think the best for now is to close it.