Package metadata only used for first workspace member

rust-osdev / cargo-xbuild

Automatically cross-compiles the sysroot crates core, compiler_builtins, and alloc.

Apache License 2.0

258 stars 25 forks source link

Package metadata only used for first workspace member #54

Closed stevecheckoway closed 4 years ago

stevecheckoway commented 4 years ago

I'm trying to specify the sysroot_path to use because I'd like several crates in a workspace to use the same sysroot. cargo-xbuild reads the metadata for the first crate mentioned in the workspace's members, rather than the actual crate being compiled. This can lead to the wrong sysroot_path being used if the first crate has a different sysroot_path from the crate being compiled.

I'm pretty sure https://github.com/rust-osdev/cargo-xbuild/blob/master/src/config.rs#L19 is the offending line, although I'm not familiar with how the appropriate information is passed to cargo subcommands, if at all.

phil-opp commented 4 years ago

I agree that it is likely the offending line. However, I'm not quite sure how to fix it correctly. For example, which metadata should we use for cargo xbuild --workspace, i.e. a build of all crates in the workspace?

I'm trying to specify the sysroot_path to use because I'd like several crates in a workspace to use the same sysroot.

I don't think that this is possible currently. In my experience, it still recompiles the sysroot when trying to build a different crate. I assume that this is caused by some sort of metadata in the generated sysroot that is dependent on the crate, but I'm not sure.

stevecheckoway commented 4 years ago

Ideally, cargo xbuild --workspace would build each crate in the workspace using that crate's metadata. Essentially running cargo xbuild in each crate in the workspace.

I would have guessed that the sysroot would depend solely on the target .json file. Any ideas what in the crate might impact it?

phil-opp commented 4 years ago

I don't think that deviating from cargo's behavior is a good idea. We currently just run the cargo commands without the x after building the sysroot and I don't want to change this. For example, the steps for cargo xbuild --workspace are:

Determine if sysroot needs to be built
- This is done using various hashes. I think that this might be the reason that the sysroot is always rebuilt for different crates.
Build the sysroot
Run cargo build --workspace with a RUSTFLAGS environment variable that passes a --sysroot argument to each rustc invocation.

stevecheckoway commented 4 years ago

The behavior you describe makes sense for a single crate, but I'm not sure it makes sense for a workspace. Each crate in a workspace can define its own sysroot_path as well as a default target in a .cargo/config.

Maybe it would make sense to define a workspace-wide sysroot_path and prohibit individual crates from setting it. (If multiple crates using the same target are causing the whole sysroot to be rebuilt, then that seems like an independent bug.)

Or maybe just say workspaces aren't supported with cargo-xbuild.

phil-opp commented 4 years ago

Yeah, I think we should at least add a warning when workspaces are used together with sysroot_path. I'm reluctant to a rewrite of this library because it seems like a lot of work and I don't think that it's a good idea to deviate from cargo's behavior.

Further, I hope that the -Zbuild-std flag is soon usable without passing the additional flag each time. At this point, I plan to deprecate this crate anyway.