Enable build-std on a per target basis

[MarnixKuijs]

Some of my custom targets require me to enable build-std, which currently I can enable through .cargo/config.toml

[unstable]
build-std = ["core"]

but this means it is enabled for every target. However I don't necessarily want it for build in targets, it would be nice if in my .cargo/config.toml I could specify something like

[target.custom-target.unstable]
build-std = ["core"] 

If this is already possible but with a different syntax consider this issue closed

[ehuss]

Is there any particular reason you don't want it for built-in targets?

[MarnixKuijs]

I want to support additional targets that aren't supported by default, hence my use of build-std. But I want the build in targets to keep working without any modification. But due to the issues mentioned in #7501 that is currently not possible.

I have to admit I missed #7501 when opening this issue. If that is fixed it might also fix my issue.

[kennystrawnmusic]

What we need at the very least is something like target.’cfg(all(target-os = “none”))’.build-std because that’s really what build-std is meant for: bare metal targets. That would fix #9451 in particular, since it would ensure that helper crates meant for the host can exist inside the workspace of other crates meant for a bare metal target which is exactly what the bootloader crate requires.

[shymega]

Hm, that approach sounds sound. Has there been any more progress on the build-std aspect of things recently? I took a step back with my bootloader months ago, but now there's been a bit more interest in it.

[Freax13]

Are there any reasons to use build-std for a tier 1 or 2 target that ships with official builds? If not couldn't we just skip those and only build core, alloc, etc for targets (including custom targets) that don't already ship with official builds? This would also clear up interactions with bindeps because it eliminates the need to specify which artifacts should be build with build-std (see #10444 (comment)); it would be implied by the target.

[RReverser]

Are there any reasons to use build-std for a tier 1 or 2 target that ships with official builds?

Yes. build-std is also important/useful for WebAssembly, where you want to do compilation with new features that stdlib is not built with as it targets the baseline supported by all browsers/engines.

For example, multithreading requires rebuilding std with atomics support. Same for SIMD or other interesting features.

[kaspar030]

Are there any reasons to use build-std for a tier 1 or 2 target that ships with official builds?

Do the optimization options get used for build-std? e.g., would RUSTFLAGS="-Copt-level=s" cargo build -Tbuild-std ... recompile std with -Os?

[Amareis]

Any updates? WASM multithreading case isn't solvable without it (not easy, at least).

[jsprog]

One of the reasons to enable selection of targets is that, rust-analyzer is failing with the config below when trying to optimize in size even more for wasm32-unknown-unknown. trying both [unstable.target.wasm32-unknown-unknown] and [target.wasm32-unknown-unknown.unstable] didn't help at all.

[unstable]
build-std = ["std", "panic_abort", "core", "alloc"]
build-std-features = ["panic_immediate_abort"]

[connorworley]

This would also be useful for building eBPF programs a la aya.

[xSetech]

Progress on #9451 and #10330 appears to have stalled. It seems like profile-rustflags could be a workaround?

[brychanrobot]

Any update on this?

[adamgemmell]

@ehuss I have someone able to work on this. Are you happy with this approach?

It seems good to me given the variety of reasons one might enable build-std. For example, some provided rustflags break ABI (such as some target-features, which are target-specific) or necessitate being used on libstd as well as user code (such as sanitizers, which can be target-specific). It seems reasonable to me that someone might want to store these flags in the source control of a binary project together with build-std enabled on certain targets.

#10308 was closed, and though rust-lang/wg-cargo-std-aware#43 needs more discussion I think the best option forward is to keep build-std available as a config flag.

per-package target doesn't really seem relevant.