Open benwis opened 11 months ago
Asking some rust toolchain experts what the Correct approach is
Context for what's up here:
cargo dist
is functionally serving as a replacement for cargo build
that handles far more setup details for you. One of those details is trying to smooth over Simple cross compilations by detecting you have rustup
installed and running rustup target add SOME_NON_HOST_TARGET
.
If rustup isn't present we currently refuse to proceed with building a non-host target, absent a way to prove that it's setup (me being overly conservative). We can just remove that restriction and let you blow yourself up with an opaque lower-level error in non-rustup setups, but, it would be nice if there was a way to query what targets are properly setup.
Because cargo dist
is invoked as a subcommand, the only env-var we have access to is $CARGO
(but we're tolerant of even not having that, because people really like invoking cargo subcommands as not subcommands sigh).
So at the end of the day if I'm being 100% "responsible" I only have access to "the ability to opaquely invoke cargo" (not even rustc). This means I need a way to do one of the following, which I can't seem to find:
$SYSROOT/lib/rustlib/
)rustc --print sysroot
)I have considered the following options:
cargo rustc -- --print sysroot
: will first build all dependencies, making it extremely slow at best and useless for "catch missing target early"cargo rust --print sysroot
: unstable, "baking" absent a champion
cargo_path.parent().parent()
is a sysroot
rustc
is in the same dir?
cargo
is usually pointing to the rustup toolchain selector shim...? bleugh.more refined can-do-it-today approach (approved by upstream toolchain criminals):
PathBuf::from(env("CARGO")).parent().join(format!("rustc{ext}"))
cargo
into PATH, so yolo bare rustc
into PATH too. people DO mess this up and have different toolchains on path for those two, but upstream closes all such bugs as WONTFIX because it's too cursed.{computed_rustc} --print sysroot
{sysroot}/lib/rustlib/{target}
existscorrection, instead of fucking with sysroot:
rustc --print=target-libdir --target={target}
So all of the above is still correct and worth doing but just to clarify the issue the OP actually ran into:
cargo dist build
expecting it to build all targets, but that defaults to the host build. thus no cross-compiling occured.cargo dist plan
) we run before every command constructs a build graph for EVERY target to make sure that's ok. this includes computing but not executing cargo build
commands for every target. the warning in question is in the "compute the build commands" step, so we freak out that you're trying to cross when you absolutely aren't.These warnings are overzealous, we should probably do something like supress them if --artifacts=all
is set.
Appreciate you taking the time to dive into this, we've been loving cargo-dist
I and a lot of NixOs users, use rust-overlay(or fenix) to manage the installed rust toolchain, selecting and installing targets and Rust versions in our flake.nix or similiar files.
I wanted to test the musl build for our project via cargo-dist, so I did
cargo dist build
and got this warning:and it only built for the current target. Can we widen that check to not use rustup, perhaps by checking for installed targets as cargo does?