Aaron Turon

Blog | Sponsor Rust | Academic | Music | About


Project maintained by aturon Hosted on GitHub Pages — Theme by mattgraham

Cargo, Xargo, and Rustup

Another topic of discussion at the Berlin Rust All Hands was the long-term story around Cargo, Xargo, and Rustup. The latter two tools are both involved in managing your Rust toolchain, with Xargo allowing you to build custom stds and Rustup managing pre-built artifacts for mainstream targets. Xargo is most commonly used for cross-compiling to less common platforms, but can also be used to customize the standard library on mainstream platforms.

The tools today are a bit of a muddle: Xargo acts as a CLI wrapper around Cargo, while Rustup is a completely separate tool, despite the fact that they handle some similar responsibilities. Moreover, Rustup cannot manage targets set up by Xargo. And there’s long been a desire for toolchain requirements to be expressed directly within Cargo.toml, so that cargo build is all that is ever required to build a Rust package.

Given all that context, we’ve talked at various junctures about simply integrating all of the above functionality into Cargo. We had another such discussion at the All Hands, which I’ll summarize below. Note: as always, this summary covers preliminary thoughts; all changes will go through the usual RFC process.

Xargo integration

There is widespread agreement that Xargo’s functionality should instead be expressed directly within Cargo, along the rough lines of the std-aware Cargo RFC. In particular, we strongly want the ability to enrich std with feature flags and enable crates to customize those flags.

There are a lot of open design questions here; in particular, there is not consensus on the details in the std-aware RFC. There are a lot of moving parts, since the ability to specify details for the standard library is closely related to specifying details about the compiler version and release channel as well.

The upshot, though, is that once we have this integration the concept of “target” within Rustup can disappear entirely (though, of course, the target must be specified at some point in the build process). Rather than manually installing a list of targets per toolchain, Cargo will automatically set up targets as needed, either building them or downloading cached binaries when available.

Rustup integration

In general, folks didn’t see a lot of value in having toolchain management handled by a separate command from Cargo, especially given the desire for crates to specify toolchain dependency information. Hence, while there will probably always be a need to have a rustup binary, we want to explore exposing its functionality through Cargo instead.

Here, again, the hard work is in the details. We probably want some combination of:

  • Toolchain declarations within Cargo.toml, as with the Xargo integration.
  • Automatic toolchain component installation.
  • New Cargo subcommands for manual toolchain adjustments.
  • Additional settings in .cargo/config.

All told, the hope is that we can replace some of Rustup’s unique aspects (like its override system) with uses of standard Cargo concepts (like Cargo.toml and .cargo/config), and generally speaking to make toolchain management “disappear”, instead driving it on demand as part of the normal project workflows.

One other insight: since rustup the tool will likely stay around in some form, we can retain its CLI for niche cases, meaning that the Cargo integration only needs cover the common case, and can thus likely make some simplifications.

The plan

The most pressing issue to address for the Rust 2018 release is the needs of the Embedded WG, where Xargo is currently commonly used to set up embedded targets. It turns out, though, that by raising a handful of those targets to Tier 1 status (which has other benefits besides), the large majority of these cases will be covered just by using Rustup.

On the whole, the Rust community is entering another “impl period” like state: for the next several months, the focus will be on executing all of the plans already laid for Rust 2018, rather than on brand new design. So the relevant teams plan to pick back up these integration questions in the last quarter of the year, after the 2018 edition has shipped.