Proposal: A roadmap to roll it out.

[Binlogo]

Recently, I've been transforming some "old-style" binaries to XCFramework for the Apple platform. During my investigation, I found that most of the solutions are shell scripts with almost the same workflow. Of course, I've done the job similarly, but in the "script" style using Rust, as in the cargo-xtask way.

Afterwards, I'm considering contributing a cargo plugin to the community. Then, I came across this crate, and I have the same idea to build one like it.

The plan is to:

• Create a library crate xcframework to standardize the related workflow: include build-target, merge platform binaries, wrap as a framework, verify and zip, which can be integrated into existing workflows, like the popular cargo-xtask method.
• Based on the xcframework library, build a user-friendly and one-step cargo plugin: cargo-xcframework executable.

Since "This is work in progress and is not ready for use", I'm willing to contribute together and push it to a release version.

Here's a roadmap I'm considering:

• [ ] Extract xcframework as a library crate (done already)
• support user-defined workflows.

  • support "cargo xtask` use case integrate

    • example: add cargo-xtask usage #8
    • Prepare core executions #10 - for user-define xtask
      • Tweak all exist cmds to use core functions.
        • Encapsulate dynamic library into framework to fix Dynamic linking on iOS, watchOS, and tvOS requires the XCFramework to contain .framework bundles. #11
          • ref: Technical Note TN2435: Embedding Frameworks In An App
          • Use tuist to create ios example

  • Evolve configuration:

    • Support standalone xcframework.toml config file together with [package.metadata.xcframework] table
    • Support pre-build hooks. e.g: to generate headers (.h) or module map files.
    • Support custom-build options. e.g: to allow running user-defined build jobs.
• Build the cargo-xcframework cargo plugin executable.
  • Support the cargo run command: cargo xcframework. (just rename xcframework to cargo-xcframework) by @akesson
  • Support flexible configuration sources, like the cargo-release method.
• Add tests and examples. (note: use tuist)
  • Static library build and integration.
  • Dynamic library build and integration.

I'm working on this project, and I'll use this issue as a tracker.

[akesson]

Very nice. Please go ahead and take a look at what has been done. There's several things from your roadmap that has been done already:

• running as a library crate. xcframework is created to be integrated with other tools, for an example see swift-package.
• running as cargo xcframework
• tests and examples

But most of it can be improved and adapted to your needs.

[Binlogo]

Absolutely, this is a great starting point.

Here's what initially confused me at the beginning:

• running as cargo xcframework

As #2 mentioned, I encounter the same issue. After investigating, I learned that the cargo subcommand binary should be named cargo-subcommand.

https://doc.rust-lang.org/book/ch14-05-extending-cargo.html
Cargo is designed so you can extend it with new subcommands without having to modify Cargo. If a binary in your $PATH is named cargo-something, you can run it as if it was a Cargo subcommand by running cargo something. Custom commands like this are also listed when you run cargo --list. Being able to use cargo install to install extensions and then run them just like the built-in Cargo tools is a super convenient benefit of Cargo’s design!

Since we're actually developing a cargo plugin, not a general CLI tool, it would be better to follow the convention, I suggest we could rename xcframework to cargo-xcframework.

[akesson]

Since we're actually developing a cargo plugin, not a general CLI tool, it would be better to follow the convention, I suggest we could rename xcframework to cargo-xcframework.

Sure. I've done the change, but for now the tests don't pass due to a missing osho target-lexicon environment.
There's also a PR open for fixing it: bytecodealliance/target-lexicon#103 it also happens to be you that created it. 👏

I'll hold off creating a PR here until it has been merged.