On 17/05/2011 4:53 AM, Peter Hull wrote:
Is it now impossible to compile rustc without downloading a snapshot?
Correct.
If the snapshots were no longer available (for whatever reason) would it be clear enough for someone to track back through git's history and find the last working rustboot in order to bootstrap again?
It would not be *easy*, but yes, there's a trail you can follow. The src/snapshots.txt maps current git revisions (and datestamps) to snapshot binary files, and it grows as we add more snapshots. So you'd need to build as many of the snapshots as you were missing (including "starting again from the beginning") to fill in the gaps.
But, in case you're concerned about data loss, every developer's build directory contains a download cache of all the snapshots you've picked up from the snapshot server already. So it's very likely that, were there a loss of the server (unlikely: it's s3 currently) the developers could restore the most-recent-few snapshots just by looking in $builddir/dl. For completeness, I'll also add another python script to the etc/ directory to download *all* snapshots, in case you wish to mirror the snapshot set in full. And I'll make copies in a few other places regularly. It's not that big -- the full set is currently about 40mb -- and space is cheap.
Is there a way to port rustc to a new platform (assuming it has LLVM support) - i.e can it be configured as a cross compiler?
Not yet, but it's on the list. The limitations that exist have to do with x86-isms and platform-specific issues wired into rustc already (i.e. even starting from rustboot, we couldn't yet run on any other platforms). Code-generation-wise, LLVM is perfectly happy to cross compile, and we intend rustc to be a cross compiler.
How do you see the final state when the rust language is perfectly stable, will there still be stage0, stage1 etc? I seem to remember that when gcc builds, it starts with simplified compiler (gcc1 ?) which can be build with the system C compiler, then gcc1 compiles gcc and all the tools. Would there need to be a 'rustc1' written in C?
If it made anyone more comfortable, such a rustc1 could be built. Either manually (we've already written 2 rust compilers, why not a 3rd?!) or else using LLVM's "C backend". But the latter would hardly be any more portable or hackable than a binary image.
For the most part, the "final state" I foresee is continuing to work off a structure more or less like the one we have now. With better automation and whatnot, but structurally the same: start from a snapshot and work forward from there. I don't *really* want to write a 3rd rust compiler; there are other things in life worth doing, y'know? If this is a policy problem with some free software distributor (say) we can cross that bridge when we come to it (provide audit trails, provide our own packages, provide stub "image downloader" packages, whatever).
But I doubt it'll be a profound problem, just a quirk. It's not *that* abnormal. I believe gnat, cmucl and ocamlc, for example, are developed this way.
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
