You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in this week's meeting, let's rewrite our build system in Rust.
We made a good effort but the current Makefile-based system has collapsed into a black hole of endless macros and meta-programming. The first thing the build does is download a copy of rustc, so let's just use that to orchestrate the rest of the build.
This could make bootstrapping new architectures even more interesting, but we like to be on the bleeding edge.
FWIW, I don't think it changes much for building on new architectures. Most of the build is still building rustc itself. To run our tests, we need to build the compiletest framework, which is in Rust. So, essentially, when doing the 64-bit port at least, I spent 75% of the time just getting rustc to build. it'll be the same on other architectures, I imagine.
My main hesitation on this is that we'll wind up snapshotting a lot more: any time we enhance the builder or fix a bug in it. Maybe we should track builder snapshots separately? The whole toolchain is not small.
(for that matter, tracking llvm snapshots separately from rustc might also be reasonable. Hm. Why aren't we just storing stage0 binaries in git?)
@graydon we didn't do it by personal preference. I thought it was nice to bootstrap off the smallest possible set of files. I don't particularly agree with that decision any more.
Activity
nikomatsakis commentedon Apr 19, 2012
FWIW, I don't think it changes much for building on new architectures. Most of the build is still building rustc itself. To run our tests, we need to build the compiletest framework, which is in Rust. So, essentially, when doing the 64-bit port at least, I spent 75% of the time just getting rustc to build. it'll be the same on other architectures, I imagine.
graydon commentedon Apr 19, 2012
My main hesitation on this is that we'll wind up snapshotting a lot more: any time we enhance the builder or fix a bug in it. Maybe we should track builder snapshots separately? The whole toolchain is not small.
(for that matter, tracking llvm snapshots separately from rustc might also be reasonable. Hm. Why aren't we just storing stage0 binaries in git?)
brson commentedon Apr 19, 2012
I don't think we need to snapshot the builder. The build shell script will use the stage0 rustc to build the builder, then the builder takes over.
catamorphism commentedon Apr 19, 2012
I milestoned this as 1.0, but let me know if you think that's too ambitious :-)
graydon commentedon Apr 19, 2012
Ok, so we need to keep enough shell-and-make around to accomplish the download and compile-the-builder steps. Possible, yeah.
(I am still curious about whether it'd be reasonable to just store stage0 binaries in git. I'm not sure why we didn't do that in the first place.)
graydon commentedon Sep 12, 2012
See also #2238. These tasks are, I think, related. Also both mine! so I will merge the bugs at my own leisure :)
graydon commentedon Dec 21, 2012
See also https://github.com/mozilla/rust/wiki/Meeting-weekly-2012-11-13
brson commentedon Dec 21, 2012
@graydon we didn't do it by personal preference. I thought it was nice to bootstrap off the smallest possible set of files. I don't particularly agree with that decision any more.
graydon commentedon Mar 25, 2013
non-critical for 0.6, de-milestoning
graydon commentedon Apr 25, 2013
nominating for backwards-compatible milestone
catamorphism commentedon May 10, 2013
Re-titled to reflect that this is about making rustpkg build Rust, and re-assigning to myself.
We don't have an 0.8 milestone, but I'd like this to happen for 0.8.
darnuria commentedon Feb 13, 2014
(I make a tour of easy/interresting bug) And It seems this bug was resolved by design by dropping rustpkg no?
brson commentedon Feb 13, 2014
I think not since rust will have a package manager and we will want to dogfood it.
reem commentedon Jul 29, 2014
This issue has long since passed its relevance and should be replaced with an issue to build with cargo, if that's feasible.
alexcrichton commentedon Jul 29, 2014
I've opened a more specific issue for cargo: #16091
Auto merge of rust-lang#2237 - RalfJung:ice, r=oli-obk
Merge pull request rust-lang#2237 from Kobzol/ci-fix
Merge rust-lang#2237
Merge pull request rust-lang#2237 from clarfonthey/triagebot-libs