esp-rs / espflash

Serial flasher utility for Espressif SoCs and modules based on esptool.py
Apache License 2.0
474 stars 116 forks source link

[Proposal] Remove Xargo/xbuild and only use build-std #28

Closed MabezDev closed 3 years ago

MabezDev commented 3 years ago

The rationale behind this is simple - the less we have to support the better.

Thoughts @jessebraham @icewind1991 @ivmarkov ?

jessebraham commented 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.

ivmarkov commented 3 years ago
  • 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?

ivmarkov commented 3 years ago

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!

MabezDev commented 3 years ago

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.