search

rust-lang / wg-cargo-std-aware

Repo for working on "std aware cargo"
137 stars 8 forks source link

Remove requirement for `--target` #25

Open ehuss opened 5 years ago

ehuss commented 5 years ago

The current implementation requires --target to be specified. Building in "cross compile mode" is required because host dependencies (proc macro especially) must use the sysroot from the compiler.

I don't think this can be changed, but we should infer the --target flag if it is not specified. The problem is that the decision to enable "cross compile mode" is done too early (before it is known that the standard library will be built). We'll need to figure out some way to work around this.

The crux of the issue is that BuildConfig::requested_target needs to be set, but BuildConfig is constructed extremely early. Decisions like this will need to know if the standard library is being built.

I'm not sure how to deal with this.

Ericson2314 commented 5 years ago

Building in "cross compile mode" is required because host dependencies (proc macro especially) must use the sysroot from the compiler.

I don't think this can be changed

We should check with the compiler team what exactly the bootstrapping requirements are. For example, ideally Rust can be bootstrapped from a plain compiler with no prebuilt libraries if one has the source for the bootstrapping compiler.

CC https://github.com/rust-lang/wg-cargo-std-aware/issues/19

alexcrichton commented 5 years ago

I'm less certain that we'll be able to do this in the long term myself. Morally you're right in that we can auto-switch to "as if --target was passed" but that also changes the output structure. It'd be somewhat surprising if cargo build generated target/debug/foo and cargo build -Z build-std generated target/$host/debug/foo. Or at least that's just to say that this may not be quite as simple as just switching to "as if we passed --target" mode early in Cargo if we want to preserve the same output structure.

If we preserve the same output structure (as if --target was passed and if it weren't) then I think this'd work great! (this seems totally fine to worry about after an initial pass of stabilization though)

@Ericson2314 the requirement that proc-macros and build scripts use the host compiler's sysroot isn't going to change any time soon. That should be in a dedicated separate issue if you'd like to see that pursued.

Ericson2314 commented 5 years ago

https://github.com/rust-lang/wg-cargo-std-aware/issues/42 opened

jyn514 commented 1 year ago

The current implementation requires --target to be specified. Building in "cross compile mode" is required because host dependencies (proc macro especially) must use the sysroot from the compiler.

Can you talk more about this? Why must host dependencies use the sysroot?

My understanding of this is something like "in cross-compile mode, RUSTFLAGS is not passed to build scripts, but in host mode it is", but I'm not sure why that's related to the sysroot?

ehuss commented 1 year ago

I don't remember the reasoning.

Perhaps there were issues with dylib loading or ABI compatibility (particularly in the face of any RUSTFLAGS)?

One possibility was to avoid building the standard library twice when cross-compiling.

Another possibility is that this was an issue when cargo used --sysroot instead of --extern?

It may be possible to remove this requirement if we're willing to take the hit of building it twice, and we can convince ourselves that the proc-macro crate doesn't have any weird ABI issues. I think with global caching, that might not be as bad.

harmou01 commented 2 months ago

Has there been any update on this since May 2023? I've been looking into it, and so far haven't found any issues with removing this requirement.

I've tried playing around with proc_macro's, build scripts and some RUSTFLAGS, but things seem to build fine. Any ideas of anything else to look at?

harmou01 commented 2 months ago

Some additional info: I've been looking into this issue. I have removed the requirement for --target in build_config.rs, so by default Cargo will use the Host CompileKind, rather than a CompileTarget.

Having tested a few things to see if this causes issues, such as using proc_macros (both in the crate, and the build script), as well as passing some RUSTFLAGS:

I'm unable to observe any issues when building. If there are any particular edge cases that i may have missed, please let me know. Additionally, I haven't observed std being built twice with this change (running cargo with --verbose).