On Tue, May 17, 2011 at 8:23 AM, Graydon Hoare <[email protected]> wrote: > 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.
Delurking a moment for a nitpick; last I checked ocamlc distributes a bytecode image of ocamlc and a C source for a bytecode interpreter capable of running it. cmucl and gnat I find pretty inconvenient to build from source precisely because of this behavior, though cmucl a little less so since there are now other good lisp compilers available, so one doesn't get in a chicken-and-egg problem of "well their snapshot mysteriously breaks on my particular architecture" quite as badly. However, since you are targeting LLVM, it seems like you should be able to cross-compile to any host that LLVM supports. This adds some convenient portability, which seems to be one of the main objection to compiler snapshots. I don't know how portable and stable the LLVM intermediate language is, but if it is both of these it might make a decent archival format. >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. It seems like this alone is a decent counter-argument; if you somehow lose snapshots or uncover a deep-seated code generator bug or something you can't compile your way out of, you can always build a new rust compiler in C to re-build rustc to a known-good state. Having such a thing may be useful eventually anyway... but not while the rust language itself is so heavily in flux. -- Simon Heath http://alopex.li/ Science, games, computers, life. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
