-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
default flexible targets path to /etc/rustc/ #31117
Conversation
In RFC 131, the default RUST_TARGET_PATH if one is not set should be /etc/rustc/ however the existing behavior does not match the RFC. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @arielb1 (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
So I'll admit I'm not actually in love with this behavior but I'm just trying to get Rust to respect the RFC. IMHO, the path needs to respect the sysroot in some fashion but I'm not sure if a change like that needs another RFC or a patch to the RFC first? That would be related to https://internals.rust-lang.org/t/perfecting-rust-packaging-the-plan/2767 |
We shouldn't merge this. It's the only place the compiler cares directly about Edit: But thanks for finding the descrepancy and making the patch! |
cc @cmr This is an interesting patch rooting out problems in the target specs RFC. |
cc @rust-lang/tools |
@cardoe Since you say this is packaging related, does that mean a distro needs to have some default custom target installed? Can you give more details about the scenario? |
I agree this is not a good solution. But the point of this was to highlight that Rust is not respecting RFC 131. There needs to be an improved fix and I'm not sure how to go about that process to fix the RFC and then fix up Rust. |
I feel the same as @brson in both regards:
I'd personally prefer to update the RFC to elide the mention of |
@brson So in the case of Yocto, they install their "native" and "cross" builds into a sysroot relative to your build directory. So for example on x86_64, it will go into |
The RFC specifies that if RUST_TARGET_PATH is unset then the default is /etc/rustc but this won't work on all systems (e.g. Windows) and the Rust compiler never actually implemented this behavior so remove it from the RFC. closes rust-lang/rust#31117 Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
@cardoe thanks for the info. Since you are patching the source to solve your problem, I think we should come up with some solution to this, since it seems like it's quite common for distros to want to customize target specs. Maybe putting a default search path in rustlib just so distros can hide something there is the right way. Relatedly, if distros could override builtin host target spec with a custom one in the sysroot that may be useful to let distros like Debian downgrade which cpu spec is being used on the default i686 target, which is one of the topics under discussion here. |
@brson I think it'd be a good idea to have a root target.json in |
instead of having a separate directory for target specs |
@cmr That's roughly what I've been doing in the Yocto builds.
When you said I'm willing to do the heavy lifting here by making the RFC and supplying the patches, I just want to make sure I do the right thing. |
I have |
Whoops, got it backwards - I envision |
ie, the target name does not occur on the target spec filename, but in the directory structure. |
The path `/etc/rustc/` is not the default last entry in RUST_TARGET_PATH. This was in RFC131 but was never implemented in rustc so it was removed as part of rust-lang#31117 and rust-lang/rfcs#1473. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
…hton librustc_back: fix incorrect comment about RUST_TARGET_PATH The path `/etc/rustc/` is not the default last entry in RUST_TARGET_PATH. This was in RFC131 but was never implemented in rustc so it was removed as part of rust-lang#31117 and rust-lang/rfcs#1473. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Add default search path to `Target::search()` The function `Target::search()` accepts a target triple and returns a `Target` struct defining the requested target. There is a `// FIXME 16351: add a sane default search path?` comment that indicates it is desirable to include some sort of default. This was raised in rust-lang#16351 which was closed without any resolution. rust-lang#31117 was proposed, however that has platform-specific logic that is unsuitable for systems without `/etc/`. This patch implements the suggestion raised in rust-lang#16351 (comment) where a `target.json` file may be placed in `$(rustc --print sysroot)/lib/rustlib/<target-triple>/target.json`. This allows shipping a toolchain distribution as a single file that gets extracted to the sysroot.
Add default search path to `Target::search()` The function `Target::search()` accepts a target triple and returns a `Target` struct defining the requested target. There is a `// FIXME 16351: add a sane default search path?` comment that indicates it is desirable to include some sort of default. This was raised in rust-lang#16351 which was closed without any resolution. rust-lang#31117 was proposed, however that has platform-specific logic that is unsuitable for systems without `/etc/`. This patch implements the suggestion raised in rust-lang#16351 (comment) where a `target.json` file may be placed in `$(rustc --print sysroot)/lib/rustlib/<target-triple>/target.json`. This allows shipping a toolchain distribution as a single file that gets extracted to the sysroot.
Add default search path to `Target::search()` The function `Target::search()` accepts a target triple and returns a `Target` struct defining the requested target. There is a `// FIXME 16351: add a sane default search path?` comment that indicates it is desirable to include some sort of default. This was raised in rust-lang/rust#16351 which was closed without any resolution. rust-lang/rust#31117 was proposed, however that has platform-specific logic that is unsuitable for systems without `/etc/`. This patch implements the suggestion raised in rust-lang/rust#16351 (comment) where a `target.json` file may be placed in `$(rustc --print sysroot)/lib/rustlib/<target-triple>/target.json`. This allows shipping a toolchain distribution as a single file that gets extracted to the sysroot.
In RFC 131, the default RUST_TARGET_PATH if one is not set should be
/etc/rustc/ however the existing behavior does not match the RFC.
Signed-off-by: Doug Goldstein cardoe@cardoe.com