Skip to content
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.

Sign up for GitHub

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

Jump to bottom

build should not bootstrap compilers for non-build-triple host compilers #5258

Closed
brson opened this issue Mar 6, 2013 · 7 comments
Closed

build should not bootstrap compilers for non-build-triple host compilers #5258

brson opened this issue Mar 6, 2013 · 7 comments

Comments

@brson
Copy link
Contributor

brson commented Mar 6, 2013

When building a cross-compiled Rust compiler, e.g. building a rustc that runs on i686 from x86_64, we first bootstrap the 'A' compiler (x86), from stage0 to stage2, then we use the stage2 'A' compiler to build the stage0 'B' compiler (i686), and go through the entire bootstrap process again, building the 'B' compiler with itself.

This has some problems:

  1. It's inefficient, bootstrapping two compilers
  2. It's not necessary since the first 'B' compiler is built from a compiler that is already up to date
  3. It only works when 'A' is x86_64 and 'B' is i686 (or vice-versa), and both for the same OS, since there's no reason to assume that the 'B' compiler can even run on the 'A' compiler's architecture.

Fixing this is going to require some deep restructuring of the makefiles.
@bstrie
Copy link
Contributor

bstrie commented Jun 24, 2013

Since the build system is eventually moving from Make to Rust, this should not be an immediate priority.

@brson
Copy link
Contributor Author

brson commented Oct 10, 2013

Don't know why this is on a milestone. Removing.

@lucab
Copy link
Contributor

lucab commented Feb 3, 2014

As a sidenote, this could be interesting for Debian in order to make the whole system cross-bootstrappable. Not in the short term, though.

@huonw
Copy link
Member

huonw commented Mar 2, 2014

part of #8058

@steveklabnik
Copy link
Member

Triage:

Fixing this is going to require some deep restructuring of the makefiles

I would guess this is why there's no change so far.

@alexcrichton alexcrichton mentioned this issue Sep 28, 2015
Closed
@alexcrichton alexcrichton mentioned this issue Oct 25, 2015
Closed
@bstrie
Copy link
Contributor

bstrie commented Feb 23, 2016

Triage: still relevant, though rustbuild may be upon us at last to free us from our woes: #31590

alexcrichton added a commit to alexcrichton/rust that referenced this issue Feb 28, 2016
@alexcrichton
rustbuild: Enable bootstrapping new hosts
90d28ec 
This commit fixes a longstanding issue with the makefiles where all host
platforms bootstrap themselves. This commit alters the build logic for the
bootstrap to instead only bootstrap the build triple, and all other compilers
are compiled from that one compiler.

The benefit of this change is that we can cross-compile compilers which cannot
run on the build platform. For example our builders could start creating
`arm-unknown-linux-gnueabihf` compilers.

This reduces the amount of bootstrapping we do, reducing the amount of test
coverage, but overall it should largely just end in faster build times for
multi-host compiles as well as enabling a feature which can't be done today.

cc rust-lang#5258
@alexcrichton
Copy link
Member

This is now done with rustbuild, (the future!), so closing.

bors added a commit to rust-lang-ci/rust that referenced this issue May 2, 2020
@bors
Auto merge of rust-lang#5258 - ThibsG:UselessBindingInStruct638, r=fl…
36b6598 
…ip1995

Add lint for .. use in fully binded struct

This PR adds the lint `match-wild-in-fully-binded-struct` to prevent the use of the `..` pattern when all fields of the struct are already binded.

Fixes: rust-lang#638

changelog: Add [`rest_pat_in_fully_bound_structs`] lint to warn against the use of `..` in fully binded struct
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@steveklabnik @alexcrichton @lucab @brson @bstrie @huonw