Open Binlogo opened 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:
cargo xcframework
But most of it can be improved and adapted to your needs.
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
.
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.
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:
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.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(done already)xcframework
as a library cratesupport user-defined workflows.
[ ] support "cargo xtask` use case integrate
8
10 - for user-define xtask
cmds
to use core functions.[ ] 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.cargo-xcframework
cargo plugin executable.cargo xcframework
. (just renamexcframework
tocargo-xcframework
) by @akessontuist
)I'm working on this project, and I'll use this issue as a tracker.