Consider limiting supported targets for initial stabilization

[ehuss]

It seems likely that getting build-std working on all targets is going to be a large effort (small example is #30). If it looks like trying to get every target working is going to be too much effort, we may want to consider somehow only supporting blessed targets (either by specifying which targets are supported, or which ones aren't) for the initial release.

[MabezDev]

This is a great idea!

I've been using build-std since its initial implementation and it works very well for our use cases. The first being strictly -Zbuild-std=core for the out of tree no_std Espressif Xtensa targets, and the second being the standard library port for all Espressif devices based on esp-idf. With these two use cases, we have thousands of users using build-std daily with no issues. Stabilizing parts of build-std would mean our std targets would compile completely on stable too, which would be great.

Finally, whenever the topic of eeking out performance, or cutting down binary size is brought up, build-std always gets a mention as it can have a huge effect on the final compiled artefact - not requiring nightly here would be a great boon for Rust as a whole.

I think something as complex as building the standard library is going to be a hard thing to get right the first time, and to be honest there will always be some target-specific edge cases that most likely cannot be handled. I don't think we should block this feature, or core (heh) bits of this feature that do work well, trying to cater to every edge case both known and unknown.

[royb3]

For my project, I've been using build-std to build the core lib for the riscv32ima target.

See this comment for why I did.: embassy-rs/embassy#1278 (comment)

It works great, but since then all dependencies are now able to build on stable rust. The only reason I cannot switch to stable yet, is the build-std feature.

I asked around if I could add the target to the growing list of tier 2 Risc32 targets, and the maintainer isn't opposed to doing this, but other people asked questions about the need of adding barely used targets to the list.

Stabilizing build-std or supporting targets that are extendible like riscv on stable in some other way, would be really nice. Until then, I will continue to work on nightly.

[royb3]

Would limiting components to be built also help with initial stabilization? Even just Core would be helpful for many bare-metal projects that target riscv32.

[romancardenas]

Stabilizing build-std for bare metal RISC-V targets would be a game changer. There is a wide variety of chips out there, and lots of people use FPGA designs with weird extension sets. Having build-std stable at least for these targets would be great

[Lokathor]

core-only builds working would also be extremely helpful on ARM targets.

I suspect that core-only builds, and possibly alloc too, would unlock the majority of cases. The problem targets mentioned in #30 all have pre-compiled standard library builds available in rustup, so I expect that very few people care about those targets having stable build-std.