build-std: always

[davidtwco]

Add a new Cargo configuration option, build-std = "always|never", which will unconditionally rebuild standard library dependencies. The set of standard library dependencies can optionally be customised with a new build-std-crates option. It also describes how Cargo (or external tools) should build the standard library crates on stable (i.e., which flags to pass and features to enable).

This proposal limits the ways the built standard library can be customised (such as by settings in the profile) and intends that the build standard library matches the prebuilt one (if available) as closely as possible.

This RFC is is part of the build-std project goal and a series of build-std RFCs:

1. build-std context (build-std: context #3873)
2. build-std="always" (this RFC)
3. Explicit standard library dependencies (build-std: explicit dependencies #3875)
4. build-std="compatible" (RFC not opened yet)
5. build-std="match-profile" (RFC not opened yet)

There is also a Zulip channel where you can ask questions about any of the build-std RFCs. This series of RFCs was drafted over many months with the help of stakeholders from many Rust project teams, we thank them for their help!

Rendered

[clarfonthey]

Not to bikeshed too hard, but I do wonder if the build-std argument should be made into an object similar to how dependencies work, rather than having multiple keys like this.

For example, you could have build-std = "never" by itself, but if you wanted to specify which crates, you could have build-std = { when = "always", crates = "std" }.

[epage]

A related thought I had when seeing this field by itself is it could be interpreted to mean build-std = "always" on its own. Having this example be more complete would help but it could still be confusing when layering different configs.

Unsure if its fine on its own, needs a different structure, a warning or note, or something else.

[weihanglo]

I would generally agree with @clarfonthey of that being a stable

[build.build-std]
when = "always"
crates = "std"

though build.build-std = "always" could be a shorthand if user just wants defaults.

[davidtwco]

I think it makes sense to have this syntax so I've changed it in 472a3c2, but can easily change back if we prefer. Next RFC updated to match in eafc6b2.

[clarfonthey]

Since I commented on #3875 before I read this, it would be worth moving references to this into that crate instead. It makes more sense to comment on no_std with regard to std dependencies, rather than simply whether std is built.

[davidtwco]

Makes sense to me, removed this in 7c6784b and added to the next RFC in 5b41f45

[clarfonthey]

Putting this here since there's not a great place to put it: while it's okay to make a future addition, I think it's good to mention the optimize_for_size feature as one of the other main things that people care about when building std. There are potential flags we could check for whether to enable this feature, but it's probably going to want its own dedicated flag associated with build-std and thus we shouldn't infer it here.

For example, I can imagine -O2 plus optimize_for_size being useful because you're willing to permit, for example, loop unrolling or autovectorization, but not large tables being included in the binary. So, simply checking for -Os or -Oz is not adequate.

[clarfonthey]

Also worth adding that my earlier comment about build-std being an object could help here, because then we can add all sorts of flags inside that object without polluting the build section with build-std-X keys.

[davidtwco]

I intended for this RFC to only mention enabling or disabling standard library features which are necessary to consider for the standard library to build, and for something like optimise_for_size to be purview of #3875 (in that you could enable optimise_for_size on a explicit dependency on std eventually). I don't intend for features like optimise_for_size to be inferred. I've tried to clarify this in 9135b3b.