Closed MabezDev closed 3 years ago
I'm in favour of this personally.
xargo
has been in maintenance mode since early 2018 due to the fact that its functionality was making its way into the official toolchain. The README in the cargo-xbuild
repository even recommends using build-std
instead.
- All tools require nightly, with
build-std
being the only path to stable (even if it might be far away)
I'm a bit confused here. As per our last meeting, in fact, the only reason why we require nightly (or will require nightly once 1.56 stable is out) is... cargo build-std
. Everything else is/will be - in fact - stable? Or am I missing something?
That's what I meant during the meeting that cargo build-std
is dragging us into nightly. With the other 2 esoteric features we use in cargo now stabilized, and with LibStd upstreamed, we don't need nightly that much anymore.
Link to the relevant topic here where it says "Targeting esp32-c3/h2 (RiscV) + ESP-IDF with Stock Stable Rust & Cargo".
Now, the above is not considering the xtensa patches, but I guess we can apply them on top of the stable compiler anyway?
Or did you mean by "tools" that both cargo-xbuild
and xargo
require nightly (the "tools")? Ooooh, if so, I see your point, and I agree!
Or did you mean by "tools" that both cargo-xbuild and xargo require nightly (the "tools")? Ooooh, if so, I see your point, and I agree!
Yes exactly that! Apologies, I should have worded that better.
The rationale behind this is simple - the less we have to support the better.
build-std
being the only path to stable (even if it might be far away)build-std-features
flag, AFAIKbuild-std
now has feature parity withXargo
andxbuild
Thoughts @jessebraham @icewind1991 @ivmarkov ?