PSA: Xargo is now in maintenance mode
japaric opened this issue · comments
Also see the status updates below. Original announcement by original maintainer follows.
It actually has been in maintenance for a while but now I'm officially announcing it.
What does this mean?
It means that I am not going to add new features to Xargo or fix known papercuts. If you would like to work on that then I can add you as collaborator. I do, however, will fix future issues (hopefully zero of them), caused by nightly, that break my ARM Cortex-M development workflow.
What should I do now?
I have proposed adding Xargo's functionality to Cargo here. Doing that will fix the known papercuts (#189, #123, etc.) and make it easier to add desired features (e.g. #139). I suggest that you comment on that issue to get it green lighted and implemented (by someone other than me).
Why are you doing this?
Xargo was conceived as a temporary solution to the missing "build the sysroot" functionality in Cargo (cf. rust-lang/rfcs#1133). This is just me being firm about the "temporary" part.
FWIW, the Cargo team is actively interested in incorporating Xargo's functionality this year.
@ofek This integration got punted, because we were able to land direct support for the platforms Xargo is typically used for. There's interest in doing this work in Cargo still, but not until 2019.
@aturon Now that 2019 is here, are there any updates on this?
There should be a blog post proposing a roadmap for Cargo coming out in the next couple of weeks (cc @nrc). I believe it touches on plans here as well.
I would like this to be a key focus for Cargo in 2019. We're working on a more precise roadmap, but I discuss it in my recent blog post at https://www.ncameron.org/blog/cargos-next-few-years/
It would be really really great if this could happen.
Linking to related RFC: std Aware Cargo
I would like this to be a key focus for Cargo in 2019. We're working on a more precise roadmap, but I discuss it in my recent blog post at https://www.ncameron.org/blog/cargos-next-few-years/
As well as broad impact, I think we should focus on cross-compilation this year because:
So what's the current state? Does cargo+rustup already do everything we need for cross development?
Current status:
stdAware Cargo RFC: closed July 29, 2020- wg-cargo-std-aware repo: created July 2020
- The issue tracker seems to be the place for current discussion.
build-std exists in nightly Rust
Xargo maintenance status update
The current status of xargo maintenance is as follows: we haven't seen @japaric in a while, so not sure how much they are still keeping their ARM Cortex-M development workflow working.
I am maintaining xargo for the purpose of Miri, which needs to check-build the official Rust standard library (unchanged). As long as Miri needs xargo, as part of maintaining Miri I will make sure this part of xargo keeps working. But I will likely not have time to work on issues that do not affect Miri. Your PRs are welcome as long as they keep CI green and don't break Miri. :)
As for me, my need for Xargo has basically gone away so any time I spend reviewing issues & PRs is solely community service.
we haven't seen @japaric in a while, so not sure how much they are still keeping their ARM Cortex-M development workflow working.
ARM Cortex-M development has not needed Xargo, or nightly, since the 2018 edition. Any other kind of embedded / no-std development for custom targets and built-in targets that lack a pre-compiled rust-std component can be done using Cargo's -Z build-std feature. Personally, I'm not aware of a use case where Xargo is needed because it can not be served by -Z build-std; e.g. cargo-call-stack a tool that I maintain and requires re-compiling libstd with rustc's -Z emit-stack-sizes also uses -Z build-std.
EDIT: and if there's a use case not covered by -Z build-std it would be best to inform the Cargo team before the feature gets stabilized.
Another status update: Miri has stopped using xargo, so I will also not maintain xargo any more.