3370394666
scripts/build-release.sh cross-compiles to x86_64-unknown-linux-gnu on the host. Pinning the toolchain to 1.91.1 gave a fresh toolchain without that target, so the release script failed its preflight on a missing std the first time it ran after the pin. Declaring it in rust-toolchain.toml makes rustup install it for any clone or future bump.
20 lines
1.0 KiB
TOML
20 lines
1.0 KiB
TOML
# Development toolchain for the whole workspace.
|
|
#
|
|
# This is NOT the library's MSRV. `tidaldb` and its siblings publish
|
|
# `rust-version = "1.91"` (see Cargo.toml) and build on 1.91.0. The pin exists
|
|
# because `tidalctl`'s AWS SDK dependency chain requires 1.91.1: on 1.91.0 every
|
|
# workspace-wide command (`cargo test --workspace`, `cargo clippy --workspace`)
|
|
# fails during resolution with "aws-types@1.3.16 requires rustc 1.91.1" and no
|
|
# gate can run at all. Pinning the dev toolchain keeps the published MSRV honest
|
|
# while making the workspace gates executable from a fresh clone.
|
|
#
|
|
# Raise this only alongside the `rust-version` fields it is meant to exceed.
|
|
[toolchain]
|
|
channel = "1.91.1"
|
|
components = ["rustfmt", "clippy"]
|
|
# scripts/build-release.sh cross-compiles the release images on the host
|
|
# (mac-arm64 -> x86_64-unknown-linux-gnu). Declaring the target here means a
|
|
# fresh clone - or a toolchain bump - installs it automatically instead of
|
|
# failing the release script on a missing std.
|
|
targets = ["x86_64-unknown-linux-gnu"]
|