Closed wmmc88 closed 6 months ago
its not cargo make. if i remember this was mentioned before and it was due to cargo behavior itself.
its not cargo make. if i remember this was mentioned before and it was due to cargo behavior itself.
Do you have a workaround for this?
Also the reason I think this is cargo make is because when running rustup run nightly cargo build
directly, i get the expected behavior of using nightly toolchain, but when cargo-make executes rustup run nightly cargo build
it seems to use nightly toolchain but the env vars are all set to stable toolchain
Ok after lots of debugging, this is what i came up with:
Despite printing the stable toolchain path for CARGO
, it is still using the nightly toolchain. I verified this by using nightly-only features. the reason nightly toolchain is still used is because rustup currently prepends the nightly toolchain to the PATH when running rustup run nightly cargo build
. Since rustup also sets RUSTC
to rustc
, it correctly still uses the nightly toolchain, but i believe this will break on the next rustup release: https://github.com/rust-lang/rustup/pull/3703. After the next release, the stable toolchain will be selected when running cargo make nightly-build
.
So why is CARGO pointing to stable? its because when cargo make nightly-build
is invoked, it uses the default toolchain (for me that's stable).
This is the flow:
cargo make nightly-build
rustup
redirects to stable toolchain pathcargo
sets CARGO
env var to stable path per cargo docscargo
calls cargo-make
cargo-make
calls rustup run nightly cargo build
which redirects to the nightly cargo
cargo
sees CARGO
is set to stable toolchain path so it does not change the value, and just forwards it per cargo docscargo
compiles the code with nightly toolchain since per cargo docs since cargo doesn't actually use the CARGO
variableCARGO
as read by the build script still points to stableI think what needs to happen here is that because of this recursive rustup
invocation, cargo-make
needs to either clear or explicitly set CARGO
. Right now, it only clears RUSTC
, RUSTDOC
, and RUSTFLAGS
, and only explicitly sets CARGO
on scripts (and not commands). This matches previous recommendation found in a related thread in rustup
I'm going to test these changes locally and put up a PR if it works
Describe The Bug
The README describes
Although this says it doesn't define it for commands, I think this should so that the behavior matches with running via
rustup
orcargo +toolchain
.To Reproduce
build.rs
:Makefile.toml
:These commands panic with stable toolchain path:
cargo build
rustup run stable cargo build
cargo make build
cargo make nightly-build
These commands panic with nightly toolchain path:
cargo +nightly build
rustup run nightly cargo build
The issue here is that
cargo make nightly-build
should print the nightly toolchain path. Something in cargo-make is preventing it from doing that.