human-solutions / xcframework

Cargo plugin for building XCFrameworks
MIT License
6 stars 4 forks source link

Proposal: A roadmap to roll it out. #7

Open Binlogo opened 4 months ago

Binlogo commented 4 months ago

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:

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:

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

akesson commented 4 months ago

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:

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

Binlogo commented 4 months ago

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 commented 4 months ago

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: https://github.com/bytecodealliance/target-lexicon/pull/103 it also happens to be you that created it. 👏

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