Build the standard library with custom profile settings

[ehuss]

This is a "use case" issue to try to clarify and discuss a use case, and how it will be addressed.

Currently the standard library is only available with the profile settings chosen when Rust is distributed. Currently that is the "release" profile with opt-level set to 2, and codegen-units set to 1.

It may be desirable for some to use different settings.

"std-aware Cargo" should make this quite simple to accomplish. When Cargo builds the standard library, it will use whatever profile is in effect at the time.

If the user wants to use different settings specifically for the standard library, they will likely need to individually select the crates (like core or std) with profile overrides.

[SimonSapin]

When Cargo builds the standard library, it will use whatever profile is in effect at the time.

A related (and IMO important) point is control over whether the standard library is (re)built in the first place, when a binary of it is available through rustup.

Profile configuration is stable, so an existing app can for example set opt-level to 3 in release mode. Rebuilding std based on this alone might be disruptive to projects that did not anticipate it: after a toolchain upgrade, suddenly a small app takes a lot longer to compile.

So I think Cargo should not change its default behavior for existing projects, at least those that are compatible with the Stable channel.

But of course some other project may want to recompile std with different settings. So there needs to be an opt-in mechanism, presumably with some syntax in the root Cargo.toml.

[ehuss]

So I think Cargo should not change its default behavior for existing projects, at least those that are compatible with the Stable channel.

Yes, that is the intent. Compiling the standard library will be explicitly opt-in (this is different from RFC 2663). Now how exactly that will be spelled out in Cargo.toml, I'm not yet sure.

[Ericson2314]

Yes, that is the intent. Compiling the standard library will be explicitly opt-in (this is different from RFC 2663). Now how exactly that will be spelled out in Cargo.toml, I'm not yet sure.

No this is bad. See what @SimonSapin said in https://github.com/rust-lang/wg-cargo-std-aware/issues/5#issuecomment-514097471, I couldn't put it better myself :).

So I think Cargo should not change its default behavior for existing projects, at least those that are compatible with the Stable channel.

I almost want to say it should change it. It's just a 1-time rebuild if we were to cache globally, and in the meantime rustup could ship more binaries?

Baring that, I would say the Cargo.toml is not "should we rebuild standard library" but "should this profile apply to all transitive dependencies", this at least frames the question as agnostic to a specific caching strategy.

[SimonSapin]

Right, the opt in that I had in mind would not be about rebuilding v.s. not, but about whether the configured profile settings should override defaults for the standard library or not.

If that mode / flag is enabled but the profile settings happen to match a configuration for which rustup has a binary available, that binary can still be used.

[ehuss]

Noting some issues with the current way profile-overrides work:

• You can override specific packages, but Cargo still issues a warning about it being unused.
• Profile overrides expose some internal details about the standard library that we may not want to expose. For example, the existence of compiler_builtins, which I feel like is just an internal thing. Exposing direct access to internal packages via things like profile overrides presents a risk for future compatibility.

[NobodyXu]

Is there any cmdline options that can be used to override the default "release" profile for the std library?

[kjetilkjeka]

It is possible to build stdlib with the same configuration as you build the rest of your code. This requires nightly and the build-std unstable feature.

You are also required to explicitly state target so you need to do something like: $ cargo +nightly run -Z build-std --target x86_64-unknown-linux-gnu

[NobodyXu]

@kjetilkjeka So as long as build-std feature is used, it automatically builds the std library using the same profile set in my Cargo.toml?

[kjetilkjeka]

I've used the feature to successfully enable debug symbols in the stdlib for debug builds. Based on this, without being familiar with the internals, I believe that is how it works.

EDIT: From the documentation linked above "The functionality implemented today is behind a flag called -Z build-std. This flag indicates that Cargo should compile the standard library from source code using the same profile as the main build itself."

[NobodyXu]

@kjetilkjeka Thanks!